单体架构、SOA和微服务

1、单体架构

比如要做一个简单的商城系统，基本的功能模块有用户模块、商品模块、商家模块、后台管理。单体架构就是把这些功能实现逻辑全部放在一个项目里，打包发布的时候以一个jar包或 war 包发布。其部署很简单，不过随着业务量激增或网站流量的增加。必然桑露其致命缺陷。

2、SOA

SOA (Service Oriented Architecture，面向服务的体系结构）旨在提升代码复用性及可扩展性，降低耦合等。比如点外卖的流程，点了外卖之后要分配送餐员，分配送餐员可以是一个服务；还有可能要发短信通知，短信通知也可以形成一个服务。这些服务可独立部署运行，服务之间可以通过网络调用（HTTP 等方式）。这样服务组合起来便形成一个完整的系统。

3、微服务

“微服务” 是世界级软件开发大师马丁 •福勒( Martin Fowler)和James Lewis 共同提出的。其定义微服务是由多个功能单一的小服务组成的，服务可以依据业务功能设计拆分；这些服务独立部署；不同服务可以使用不同的技术实现（指不同的编程语言与数据库等）；服务与服务之间采用 HTTP 等轻量协议传输数据，服务之间独立性强，微服务还能提升代码复用性及可扩展性，降低耦合等。

为什么要使用微服务

1、单体架构VS微服务

单体架构在业务初期，功能足够简单，在网站流量不大的情况下的确是一个低成本而又效率高的方案。不过随着时间的推移，业务量的激增，网站流量增大，单体架构程序必然会暴露出很多问题。

  1. 代码复杂度高：因为所有的代码都糅合在一起，依赖紧密，可能修改一处会带来“牵一发而动全身”的风险。
  2. 体积大，部署缓慢：目前遇到的最大的项目打包后大小是 500MB 左右，如果更新频繁，重复的打包、发布，将极其复杂。
  3. 程序出错影响服务的稳定性：如果程序某个功能出现bug，将会导致大量地占用系统资源，严重可能导致服务整体宕机。
  4. 阻碍技术的更新：单体应用的兼容能力极差，只能基于当前项目进行维护。
  5. 集群扩容不合理：只能整体扩容，无法结合实际业务的流量进行合理的伸缩扩容。

2、SOA VS 微服务

微服务是SOA体系结构的不断演进的结果，SOA和微服务本质上都是在拆分服务，为了降低耦合，提高代码的附庸行。微服务比SOA更加突出服务的独立性，是更加细粒度的划分服务。

3、微服务优点

  1. 代码复杂度低：根据业务细粒度的拆分成多个小服务，业务功能清晰，代码体积小，便于理解和维护。
  2. 技术选型更加自由：单个服务可以根据自身业务选择合适的编程语言和技术实现。
  3. 独立部署：服务独立部署，如果需要修改某个服务不会影响其他服务。
  4. 服务的可伸缩性：不同的服务可以根据自身情况去实际扩容，压力小的服务可以减少服务器资源，压力大的服务可以更加快速的进行扩容。
  5. 错误隔离：在多个服务中，一旦某个服务出错，只要修复当前服务即可，对其他的服务影响降低。
  6. 分库更加容易：每个应用可以去连接不同的数据库服务。

4、微服务缺点

  1. 构建微服务系统复杂：服务拆分会带来一系列问题，如何去更好的协调这些服务是很大的问题。
  2. 服务依赖：假设有A、B、C 三个服务。A调用B，B调用C。C是最底层的服务，如果此时迫不得已要改动C的接口，可能B 也要改动，有可能连带A也要改动。
  3. 数据一致性：在微服务中，各个服务都是独立的进程，假设A服务调用B服务，在远程调用过程中，刚好遇到网路延迟，A系统收到超时异常数据回滚，可是在B系统中已经将数据保存了。
  4. 接口排除故障困难：随着微服务调用链路的拉长，要定位线上问题，不得不同时查看多个服务情况。
  5. 运维和部署：要检查和监控多个服务的健康状态，快速地部署多个服务，并且根据网站负载情况实现服务的动态伸缩等，都是不小的挑战。