微服务架构下的若干常用设计模式

Posted 2021-04-14 IT实战联盟

原文链接：https://www.toutiao.com/a6601430174107959811

在我们选择了用微服务架构来设计、交付数字化应用后，因微服务架构本身所带来的一些共性问题，比如各微服务团队之间的分工合作，数据存储，分布式事务，服务注册与发现等，必须得到很好的解决。幸运的是，我们已经有一些比较成熟的设计模式来解决上述问题。这些模式在我的一些项目中也有所应用。

一. 独立数据库设计模式

问题：

我们按照领域模型拆分了微服务，每个微服务由一个独立的团队负责开发

1. 我们希望这些微服务是松耦合的，能够独立部署，独立扩展

2. 某些情况下，不同的微服务有不同的数据存储要求，有的希望用SQL数据库，有的希望用No-SQL数据库

设计模式：

每一个微服务都拥有自己的数据库，一个微服务希望访问另外一个微服务的数据时，必须通过API访问，而不是通过数据库表的关联查询。

独立数据库设计模式

优点：

1. 微服务之间是松耦合的，某个微服务修改数据库表结构，不会影响其它微服务

2. 每个微服务都可以使用最符合自己需求的数据库

负面影响：

1. 跨数据库的数据查询需在应用程序本身完成，不能通过数据库表的关联查询完成

2. 处理跨多个微服务的事务是一个挑战

二. Saga设计模式

问题：

前面提到，当我们采用微服务模式，并且每个微服务都拥有自己独立的数据库，如何处理跨多个微服务的事务是一个挑战，即如何保证数据在多个微服务之间的一致性？

设计模式：

把一个跨多个微服务的长事务拆分成一个有多个本地事务的序列，即saga。每一个微服务更新本地数据库后发送一个事件到下一个微服务。如果其中一个微服务的事务失败，则触发一系列补偿事务，以取消前序微服务已完成的变更。

该设计模式有两种类型

无中心协调者saga模式：每一个微服务触发事件到下一个微服务，即每一个微服务知道自己要把事件送给哪些微服务

无中心协调者saga模式

有中心协调者saga模式：每一个微服务触发事件到中心协调者，由中心协调者确定发送什么指令到哪一个微服务。

有中心协调者saga模式

优点：

无需使用复杂的分布式事务协议（如2PC，3PC）

负面影响：

编程比较复杂，每个微服务需要实现补偿事务，参与事务的方法还需要实现冥等

为保证本地业务数据更新后可靠的发送事件，需要额外的解决方案

三. 事件溯源Event sourcing设计模式

问题：

前面提到，在采用saga设计模式处理跨多个微服务的长事务时，如何保证本地业务数据更新后可靠的发送事务？目前还没有一个成熟的机制来保证数据库（如mysql）和消息队列服务（如RabbitMQ）之间的事务一致性。

设计模式：

在业务数据发生变化的时候，把触发改变化的事件记录到Event store事件表中，同时发送事件到事件总线（如RabbitMQ）。微服务定期扫描Event store事件表，对发送失败的事件重发。同时，因为Event store中保存了业务数据变化的所有事件，我们可以通过回放事件获取业务数据在任何时刻的状态。若希望在保存事件的同时，同步更新本地业务数据的最终状态，可以通过数据库的事务来确保两个数据操作的事务一致性。

事件溯源Event sourcing设计模式

优点：

解决了在事件驱动架构中可靠发送事件的问题

100%记录业务数据变化事件，可以通过事件回放追溯业务数据在任一时刻点的状态

负面影响：

编程更复杂

查询业务最终状态时，需要回溯业务数据的所有事件，导致查询效率低下，需要通过其他方法解决。

四. CQRS设计模式

问题：

当我们采用微服务架构，每个微服务都有自己独立的数据库，我们无法通过数据库表的关联查询实现跨微服务数据库的多表查询，甚至我们采用事件溯源设计模式，我们只保存了改变业务数据的事件，如何实现数据的高效查询？

设计模式：

把应用分成两部分，命令部分和查询部分。命令部分负责数据的增，删，修改，同时负责在业务数据变化的时候发送事件；查询部分负责数据的查询，同时负责监听业务数据变化事件，更新业务数据最新状态。

CQRS设计模式

优点：

在采用微服务架构后，提升查询效率

改进业务数据变化的命令模型和业务数据检索时的查询模型

负面影响：

增加了编程的复杂性

可能会有冗余数据和重复代码

复制延迟，最终一致的数据视图

五. API网关设计模式

问题：

当采用微服务架构后，客户端如何访问后台服务，客户端开发人员如何知道后台提供了哪些服务？

设计模式：

客户端通过API 网关访问后台服务

API网关设计模式

优点：

常见的API 网关除了把客户端请求路由到对应的微服务外，还提供安全，限流，监控等功能，同时也支持微服务开发者描述API的能力

负面影响：

增加了额外的网络时延-虽然对于大多数应用来说，这点网络时延对用户体验来说根本感觉不出来。

除了上面描述的5个常用设计模式，在微服务架构下还有以下设计模式也是经常用到的：

日志聚集设计模式: 把所有微服务产生的日志集中到一起，便于查询，比如开源的ELK，商业的Splunk都提供日志聚集解决方案。

分布式追踪设计模式：当客户端调用微服务的时候，生成一个唯一的trace id，用于跟踪客户端每一次后台API调用经历的所有微服务极其日志。每个微服务的日志都记录这个trace id及这次调用的开始结束时间和其它日志。

---------------END----------------

后续的内容同样精彩

长按关注“IT实战联盟”哦