内容来源：2017年12月21日，华为微服务架构师殷湘在“华为ServiceComb在线直播”进行《和平统一-微服务场景下的数据一致性解决方案》演讲分享。IT 大咖说（WeChat_ID：itdakashuo）作为独家视频合作方，经主办方和讲者审阅授权发布。

阅读字数：1971 | 4分钟阅读

观看嘉宾完整演讲视频及PPT，请点击：http://t.cn/EAs3e3f

摘要

华为微服务架构师殷湘从“离合断”三个方面归纳总结了微服务场景下的数据一致性解决方案。

离——数据一致性的起因

单体应用

在单体应用所有模块(A/B/C)使用同一个数据库，如果要同时修这三个模块的数据，它的一致性是通过数据库来保证的。

如果三个模块的数据都写入成功，那么这个事务就成功了。假如有一个失败，数据库则会帮我们做一个rollback。

微服务场景

微服务要做到四个“独立”，独立进程、独立部署、独立技术和独立团队。

独立进程是指微服务可能在不同的进程中运行，也就是说微服务之间可能是处于不同的网段。

独立技术就是说每个微服务使用的数据库可能是不同的技术，比如第一个微服务使用的是MySQL，第二个是MongoDB，第三个可能是Cassandra。

因为网络的隔离和独立技术，所以我们没有办法通过数据库来保证数据一致性。

合——数据一致性的解决方案

Soga

我们用的Saga是基于1987年Hector 和 Kenneth发表的一篇论文。Saga代表的是一个Long Live Transaction。Hector 和 Kenneth认为一个长活事务可以将它分成N个子事务，每一个子事务对应的都是一个本地事务。每个本地事务Tx我们会提供对应的补偿Cx，这样的话从T1到Tn，都有对应的补偿C1到Cn。如果长活事务执行正常的话，那么T1到Tn都是正常执行；假如其中有一个执行异常，就需要对前面已经完成的事务予以补偿。

目前已知使用Saga的厂商有Microsoft、Twitter和Uber。

Saga是一个最终一致的一段式方案。在收到请求的时候，会直接对A/B/C三个服务发起事务的请求，A/B/C三个服务会分别执行请求并返回。

2 2 2

我们的Saga实现可以归纳为三个数字：2 2 2。即两种恢复策略，两个特点，以及两种运行模式。

两种恢复策略是指向前恢复和向后恢复。两个特点是和平、统一。以及两种运行模式，图遍历和Akka Actor异步模型。

恢复策略

向前恢复：重试N次直到成功或采取回退措施。

向后恢复：补偿策略。如果这种情况下B失败了，就对已经完成的两个服务进行补偿。

和平统一

和平：低侵入。减少业务代码集成，降低运维难度，剥离业务与数据一致性复杂度。

统一：集中式。让运维监控更加简单。利用集中式的方法，可以对长事务所有的子事务进行监控，可视化事务的拓补关系和调用链。通过调用链可以知道在哪个部分性能最差。

高可用：Saga本身无状态，可集群，可分片。Saga基于Event Sourcing架构，每一个事务都会通过事件的方式记录下来。

运行模式

要求

现在的Saga实现对业务系统有两个要求。第一个是事务接口幂等，如果服务多次收到同样的请求，则认为是同一个操作，不会有任何额外的影响。因为我们是一个分布式的环境，Saga可能先发起一个子事务的请求T，由于通过网络发送，T可能会超时，超时后Saga进行重试请求T’。如果T’成功了，而T因为网络阻塞，在很久以后才会被业务服务A收到。假如这时业务服务A不满足幂等的要求，就会导致处理出现问题。

另一个要求是可交换。当遇到事务请求T超时的情况时，第二次发送请求T’的时候，可能由于其它服务的事务失败了触发补偿。这时Saga会对服务A发起补偿操作。不幸的是可能在补偿结束后，那个超时的事务请求T才会被服务A收到。

这两个要求的应对方法就是给事务的记录加一个状态，标记为已删除的状态，而不是真正从数据库中把那些记录删掉。

断——一致性方案的选择建议

一致性方案的选择建议

内刚：在微服务内，聚合要通过数据库事务保证强一致。

外柔：而在微服务间，要保证最终一致性。

微服务架构与领域驱动设计

《微服务设计》这本书提出，领域驱动设计是微服务系统架构的最佳指南。微服务和领域驱动设计中限界上下文的概念是一一对应的。

聚合与数据一致性

《实现领域驱动设计》这本书提出的两个原则，聚合内要实现强一致，跨聚合只需要最终一致。由此可得，聚合的边界其实就是强一致的边界。

一致性方案选择建议

微服务和限界上下文有一一对应的关系，聚合的边界和强一致边界也有一一对应的关系。

而一个限界上下文对应一个或多个聚合。由此可得，微服务内部的聚合应通过数据库事务保证强一致，微服务间只需要最终一致。如果需要分布式强一致，首先考虑设计是否合理而非追求最新技术，合理的设计能大大减少技术复杂度和商业成本。

总结

数据一致性的起因是“离”，也就是因为进程通过网络分离，以及数据库的技术不一致。我们的方案是Saga，总结为 2 2 2，一致性方案选择建议是“内刚外柔”。

未来的开发计划

SAGA开发当前主要聚焦在易用性上，具体的设计可以在邮件列表上查询到相关的Proposal（https://lists.apache.org/thread.html/dcd7cd6d238d211d09f6f90e447656bec38c2179e5f8f3ba0d76cbf0@%3Cdev.servicecomb.apache.org%3E），欢迎热心的伙伴们参与Proposal的讨论，有兴趣参与社区贡献的人也可以自行认领JIRA上的相关任务，

SCB-24:做可视化事务拓扑，定位异常最多的服务。

SCB-163:使用bytecode instrumentation实现异步事务支持。

SCB-164:事务一致性方案alpha集群的异常恢复。

如何参与到ServiceComb社区

官网：http://servicecomb.incubator.apache.org/cn/

通过订阅邮件列表参与讨论：

1、发送任意内容至邮箱：dev-subscribe@servicecomb.incubator.apache.org

2、收到来自dev-help的邮件后，再回复任意内容来确认订阅邮件列表

在Apache JIRA(https://issues.apache.org/jira/browse/SCB)上提issue或查看最新的开发任务及进展

通过Github(https://github.com/apache?q=servicecomb)发起PR

今天的分享就到这里，谢谢大家！