2.1 微服务架构演进

在单体应用时代，所有的功能（代码）耦合在一起，并且部署到同一个进程中。如图2-1所示，一个单体的在线商场应用由用户模块（UserService）、账号模块（AccountService）、商品模块（GoodsService）、订单模块（OrderService）等多个模块组成。

图2-1

随着业务的增加，单体应用面临的问题也会越来越多，例如：

·当部分模块出现问题的时候，会影响整个应用。比如，图2-1所示的应用在某次发布前，其订单模块修改了代码，导致CPU的使用率飙升到100%，这时整个应用会不可用，也会影响其他模块的功能。

·应用功能越多，部署成本越高。比如，某次发布只有订单模块新增了新的功能，但发布时必须发布整个应用，如果发布过程没有无损下线，就会导致部分请求报错，从而引起业务受损。

·技术栈受限，要求所有的开发者必须使用相同的开发语言。

这种情况就像搭积木一样，积木搭得越高，整体结构就会变得越不稳定，往上面加新的积木（添加功能）或拿掉一些积木（删除功能）都非常危险，随时可能导致整个积木结构崩溃。这时出现了微服务架构，即把一个单体应用拆分成为各个子应用，各个子应用在单独的进程中。如图2-2所示，这是Martin Fowler（ThoughtWorks首席科学家，当今世界软件开发领域最具影响力的大师之一）在其博客上介绍的单体应用与微服务应用之间的区别（单体应用会把所有的功能放到一个进程里，扩容时相当于复制单体应用到多个服务器上。微服务架构会把每个功能单独放到一个进程里，扩容时根据需要对不同的微服务进行不同的操作）。

微服务架构的优点如下：

·每个微服务可以独立开发、独立运行、独立部署，可以使用任意一种开发语言。

·每个微服务之间是独立的，如果某个服务宕机，只会影响当前服务，不会对整个业务系统产生影响。

·不同团队维护不同的微服务，职责单一。

·可以针对不同的微服务做不同的扩/缩容策略，不会造成资源浪费。

图2-2

使用微服务架构虽然有以上优点，但也会有一些缺点。其中一个缺点就是微服务节点信息的维护，图2-2中的5个微服务分别拥有5、3、1、3和4个节点，这些服务的节点信息会随着时间随时变化，我们怎么感知这些节点信息的变化呢？如图2-3所示，UserService服务依赖OrderService服务，而OrderService有6个实例节点，这6个节点的IP需要通过注册中心维护。

图2-3

Spring Cloud 和 Apache Dubbo 内部服务节点信息的维护使用服务注册/服务发现机制实现。Spring Cloud服务调用的过程如图2-4所示，多个Provider（服务提供者）首先会在注册中心注册自身的实例信息，Consumer（服务消费者）去注册中心发现服务，得到服务实例列表，最终选择其中某个实例发起一次服务调用。Apache Dubbo的架构如图2-5所示，它也使用依赖注册中心的服务注册/服务发现机制。Provider 向注册中心注册自身的实例信息，Consumer 发起服务调用的时候首先会去注册中心订阅Provider服务对应的实例列表，然后选择某个实例发起一次服务调用，调用过程会被Monitor监听模块监听并统计。

图2-4

图2-5