架构的演变

整体演变

单体架构——>垂直架构：
随着业务的扩展，单体架构满足不了业务功能的复杂性，开始将多个大功能或其它划分方式，将一个单体架构拆分为多个单体架构，相互之间独立，就形成了垂直架构

垂直架构——>RPC分布式服务：
随着垂直架构的发展，业务功能又逐渐复杂，代码冗余越来越多，开始将共同的代码抽取出来，作为一个个服务，然后通过调用服务来提高代码复用性，形成了RPC架构，分布式服务，已经算是步入微服务阶段

RPC分布式服务——>SOA
RPC架构抽取的服务也越来越多，错综复杂，调用时候通过nginx去实现，进行优化以后，将所有服务都放入治理中心，各个应用调用的时候，直接去治理中心统一调用，这就形成了SOA

SOA——>微服务
SOA各个服务之间如果存在依赖关系，很容易造成线程卡死、雪崩，解决这个相互之间复杂的依赖关系，产生了微服务，将所有应用和服务都进行更细粒度的拆分，每个功能、业务都拆分为微服务的一部分，独立部署、运维，各个应用之间相互独立，统一注册到注册中心，调用的时候通过注册中心调用

单体架构

所有功能所有业务代码都放在一个项目中

• 优点
  • 架构简单，小项目开发成本低
  • 项目部署在一个服务器上，维护方便
• 缺点
  • 所有代码集成在一个项目中，大项目不易维护和开发
  • 项目之间耦合度高，容错率低

垂直架构

在单体架构的基础上，将几个大的模块或者功能，拆分为多个应用，每个项目代码中都有单独的一套自己的代码，每个应用都有登录、注册等等。

• 优点
  • 分担了流量，解决了并发，可以针对不同模块优化和扩展
  • 一个应用出了问题不会影响其它应用，容错率提高
• 缺点：
  • 系统之间项目相互独立，无法进行相互调用
  • 系统之间项目相互独立，有重复的开发任务

RPC架构

RPC已经算是开始步入微服务阶段

垂直应用越来越多，重复代码也越来越多，在垂直架构的基础上，将公共的模块代码抽取出来，例如登录、注册等，作为一个服务，各个应用都可以调用。如果这种服务太多，就开始错综复杂了。

• 优点
  • 抽取公共的功能作为服务，提高代码的复用性
• 缺点
  • 系统间耦合度变高，调用关系错综复杂，难以维护

SOA架构

将所有服务都注册在治理中心，应用需要的时候就去治理中心调用

• 优点
  • 使用治理中心（ESB\dubbo）解决了服务间调用关系的自动调节
• 缺点
  • 服务间会有依赖关系，一旦某个环节出错，影响较大（服务雪崩）
  • 服务关系复杂，运维、测试部署困难

微服务架构

将所有应用更细粒度更彻底的拆分，作为一个个单独的服务，注册在注册中心，调用的时候，也去注册中心调用，因为很细粒度的划分，可以快速迭代，各个服务独立发布、运维，不影响其它服务正常使用，

• 优点
  • 服务拆分，可以独立打包、部署、升级，每个服务职责清晰，利于扩展
  • 微服务之间采用Restful等轻量级http协议相互调用
• 缺点
  • 分布式系统开发的技术成本高（容错分布式事务等）
  • 复杂性更高，各个微服务分布式独立部署、运维，每个微服务不同服务器不同配置文件，运维人员更麻烦