微服务概述-蒲公英云

微服务越来越火，我也不自觉得加入到微服务的队伍里来了，可是对于微服务的具体概念好像还没有一个统一的定义，这里基于自己的理解，说说到底什么是微服务。

什么是微服务

首先微服务是相对于传统的单体系统而言，所谓的微，即为细小，粒度细小，需要参与的人员细小；服务，即为独立的功能单元，是用户感知的最小的功能集。
所谓的微服务架构也就是说把以前的独立、单一、巨大的系统拆分成粒度更小的多个或者多组服务，每个服务运行在自己的进程中，并使用轻量级机制通信（通常是HTTP API），这些服务基于业务能力构建，并能够通过自动化部署机制来独立部署，这些服务使用不同的编程语言实现，以及不同数据存储技术，并保持最低限度的集中式管理，并可以协调管理这些服务。

为什么需要微服务？

既然微服务是相对于传统类型的系统，那么为什么需要微服务，当然也是源于单体系统架构带来的问题。

单体架构在规模比较小的情况下工作情况良好，但是随着系统规模的扩大，它暴露出来的问题也越来越多，主要有以下几点：

复杂性逐渐变高
比如有的项目有几十万行代码，各个模块之间区别比较模糊，逻辑比较混乱，代码越多复杂性越高，越难解决遇到的问题。
技术债务逐渐上升
人员流动导致代码留下来很多坑，由于单体项目代码量庞大的惊人，留下的坑很难被发觉，由于系统耦合在一起导致后期坑很难填平，也就是所谓的技术债务越来越多。
部署速度逐渐变慢
代码多了，自然部署要慢
高度集中式管理
由于高度集中式管理，导致技术栈固定，老项目的改造成本会非常之大，比如某个项目使用struts2写的，由于各个模块之间有着千丝万缕的联系，代码量大，逻辑不够清楚，如果现在想用spring mvc来重构这个项目将是非常困难的。
无法按需伸缩
比如说电影模块是CPU密集型的模块，而订单模块是IO密集型的模块，假如我们要提升订单模块的性能，比如加大内存、增加硬盘，但是由于所有的模块都在一个架构下，因此我们在扩展订单模块的性能时不得不考虑其它模块的因素，因为我们不能因为扩展某个模块的性能而损害其它模块的性能，从而无法按需进行伸缩。

微服务与单体架构区别

单体架构所有的模块全都耦合在一块，代码量大，维护困难，微服务每个模块就相当于一个单独的项目，代码量明显减少，遇到问题也相对来说比较好解决。
单体架构所有的模块都共用一个数据库，存储方式比较单一，微服务每个模块都可以使用不同的存储方式（比如有的用redis，有的用mysql等），数据库也是单个模块对应自己的数据库。
单体架构所有的模块开发所使用的技术一样，微服务每个模块都可以使用不同的开发技术，开发模式更灵活。

简单的讲，就是降低了集中式管理和减少模块间的代码耦合。