微服务架构演变

架构演变

1. 单体架构

   • 单体架构：所有功能模块都放在一起。

   • 优点：架构简单，适用于小型项目。

   • 缺点：难以维护。系统故障时所有团队都要关注；无法做到故障隔离；不好扩容，因为扩容意味着所有模块都要部署一遍。

2. 垂直架构，模块化，负载均衡

   • 垂直架构：以项目/业务为单位，将单体架构中的大项目拆成多个小项目/业务。

   • 优点：与单体架构相比，可以解决扩容等维护问题。

   • 缺点：不同项目/业务中通用的功能无法复用。

3. SOA架构，服务管理，RPC技术

   • SOA（带ESB总线的SOA实现）：将重复公用的功能抽取为组件，以服务的方式给各各系统提供服务。ESB 全称为 Enterprise Service Bus，即企业服务总线。所有的企业服务都挂接到该总线上对外公布。企业服务总线负责管理服务目录，解析服务请求者的请求方法、消息格式，并对服务提供者进行寻址，转发服务请求。

   • 优点：功能可以复用。

   • 缺点：粒度较粗，服务与ESB的耦合较紧密。

4. 微服务架构，自治

   • 微服务是去 ESB 的 SOA。与带 ESB 总线的 SOA 实现相比，微服务粒度更细、去中心化更彻底。

   • 微服务和SOA的区别：https://zhuanlan.zhihu.com/p/26713286

SOA和微服务的区别

1. SOA本来就是为了解耦，去中心化，但是按照SOA的思路，这些系统总会在某个环节上走向集中，去中心化做的不彻底。

2. 一开始大家都用ESB，这是通过一个总线来实现服务编排。但是这样的话系统在开发阶段就走向集中了，服务模块中没有业务，所有的业务逻辑都在ESB中通过BPEL来组装。组装好的流程再交给Struts等Server端MVC框架调用。

3. 使用SOA ESB的时候，存在一个流程编排的Team来掌握所有业务行为，这群人需要具备架构设计、流程分析、系统分析的能力，所以他们很贵，人数也很少，但是所有业务变化都跟他们有关系，所以他们很容易变成最大的组织瓶颈。

4. 后来不用ESB了，大家各自搞自己的，开发SCA服务就行了，业务行为往前推，放到Struts Controller里去。但是这样的系统还是会在打包环境走向集中，打出一个巨大的EAR包。

5. 打成一个包部署也不方便，后来大家就想拆成多个WAR或者EAR，各搞各的，需要集成的时候我们就走SOAP吧。但是DB还是集中的。

6. 把DB也拆开，就彻底去中心化了。但是要支撑这种做法，你需要做很多技术准备，这套东西做完了，也就搞出一套微服务了。