大家好，我是mikechen。

微服务架构是大型网站的必经之路，下面我就全面来详解5大微服务架构设计模式@mikechen

本篇已收于mikechen原创超30万字《阿里架构师进阶专题合集》里面。

微服务架构

之前谈过微服务是一种架构模式，它提倡将单一应用程序划分成一组小的服务，服务之间采用轻量级的通信机制互相沟通，每个服务都围绕着具体业务进行构建，并且能够被独立地部署到生产环境。

如下图所示：

为什么需要微服务架构

从生产力和系统的复杂性这两个方面来看，公司一开始的时候，业务复杂性不高，这时候是验证商业模式的时候，业务简单，用单体服务反而生产力很高。

如下图所示：

这种将所有功能，都部署在一个web容器中运行的系统，就叫做单体架构，也叫巨石型应用。

单体应用的优点在于：单一架构模式在项目初期很小的时候开发方便，测试方便，部署方便，运行良好。

随着公司的发展，业务复杂性慢慢提高，以及访问量越来越大，会出现如下情况：

• 编译时间过长、回归测试周期过长;
• 开发效率降低，因为，所有业务都混在一起；
• 团队扩展了，需要分工明确了，按照业务来发展，大家都高效；

这时候就可以采用微服务来提升生产力了，这里就会涉及到微服务架构，以及5大微服务架构设计模式。

聚合设计模式

为了尽量减少服务之间的通信，我们可以使用服务聚合模式。

基本上服务聚合设计模式，是接收来自客户端、或 API 网关的请求。

然后分配给内部多个后端微服务，再将结果合并，并在一个响应结构中发给请求发起人。

如下图左侧所示：

典型使用，比如：API网关作为聚合服务，客户端只需与API网关通信，而不需要直接与各个微服务通信。

这种模式，可以帮助简化客户端与微服务之间的通信，并提供更好的性能和用户体验。

代理设计模式

代理服务，充当了客户端、和后端微服务之间的中间层，可以帮助解耦、和增强系统的各种功能。

如下图左侧所示：

比如：

Service Mesh是一种轻量级的微服务代理框架，用于管理微服务之间的通信。

它通过为每个微服务注入一个Sidecar代理来实现请求的转发、监控、故障恢复等功能。

异步消息传递设计模式

如果通信只是在少数几个微服务之间进行，那么同步通信就很好。

但当涉及到多个微服务相互调用，并且要等待一些长时间的操作完成时，我们应该使用异步通信。

虽然REST设计模式非常流行，但它是同步的会造成阻塞，因此部分基于微服务的架构，可能会选择使用消息队列代替REST请求/响应。

如下图所示：

如果你有多个微服务需要彼此交互，而且，你希望这种交互没有任何依赖性或是松耦合的，那么我们就应该在微服务架构中使用基于异步消息的通信。

链式设计模式

单个服务或者微服务将会有多级依赖，举个例子：Sale 的微服务依赖 Product 微服务、和 Order 微服务。

在这种情况下，服务A接收到请求后会与服务B进行通信，类似地，服务B会同服务C进行通信。

所有服务都使用同步消息传递，在整个链式调用完成之前，客户端会一直阻塞。

因此，服务调用链不宜过长，以免客户端长时间等待。

如下图所示：

数据共享设计模式

我们已经说过，在微服务里，为每个服务分配一套单独的数据库是理想方案。

采用共享数据库在微服务里属于反模式，但是，如果应用程序是一个单体应用而且试图拆分成微服务，那么反正规化就不那么容易了。

在后面的阶段里，我们可以转到每个服务一套数据库的模式，直到我们完全做到了这一点。

但在重构现有的单体应用时，SQL数据库反规范化可能会导致数据重复和不一致。

因此，在单体应用到微服务架构的过渡阶段，可以使用这种设计模式。

如下图所示：

在这种情况下，部分微服务可能会共享缓存、和数据库存储。

本篇已收于mikechen原创超30万字《阿里架构师进阶专题合集》里面。