作者：向日葵Kevin
原文链接：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实战联盟”哦
注意：本文归作者所有，未经作者允许，不得转载
