【京东架构师分享：微服务分布式一致性模式】微服务拆分后遇到的一个麻烦是分布后的一致性问题 。单体架构的业务处理和数据都在一个进程里面，一致性保障很成熟，开发人员基本上不用关心 。当把业务系统拆分到不同进程时，就遇到了技术性一致性问题 。这带来了纠结，我们希望有一颗银弹，一把解决问题 。但由于分布式一致性在(CAP)理论上没有完美的解决方案，我们所能选择的方案是在特定业务场景下的选择 。
我们这里讨论的分布是指业务逻辑上做了拆分导致的分布，而不是数据量特别大导致的分布 。
如果业务上不拆分，数据量特别大需要做分布，可以选择支持大数据的分布式数据库 。可以选择Cassandra, MongoDB等NoSQL，或者TiDB这类支持SQL的分布式方案 。
文章插图
如果业务上进行了拆分，不论选什么数据库都不能解决分布式一致性问题 。把数据库或者分布式数据库看成是一个系统，能处理一个外部请求在数据库内部的分布式问题，但不能处理多个外部请求的一致性问题 。
分布式强一致的数据库不能解决业务逻辑拆分带来的分布式一致性问题，我们还得继续纠结如何解决业务分布式一致性的问题 。
首先我把微服务分布式一致性问题分为数据共享一致性和业务交易一致性问题 。
数据共享一致性
在单体架构的时候用同一个数据库，不存在数据共享问题 。微服务强调要独立数据库，引起数据如何共享的问题 。
数据共享分为拉和推两种模式，拉指消费者去供应商那边拉数据，推指供应商主动把数据推到消费者面前 。
拉-视图共享
对于一般的企业信息系统，数据量不大，并发需求也不大，我建议所有的微服务用同一个数据库实例，但是拆分在不同的Schema 。这样的好处是在业务逻辑上数据库是独立的，也可以独立演进 。然后数据库又可以集中管理 。这个方案对于大型遗留系统拆分尤其适用，因为原本就是在一个库里面，为了业务更好的独立演进进行数据库Schema拆分，又能延续原有的数据库实例管理技术 。由于不同的微服务实际运行在同一个数据库实例上，可以简单的建视图进行数据共享 。需要注意的是，不要拉整个表出去，根据需要选择几个字段 。这种模式技术上简单，坏处有两个：一是由于视图同步的数据是实时的，应用可能基于实时同步数据的假设进行设计，会导致以后做分布式扩展的时候特别困难；二是视图很容易暴露出表结构，这需要特别加强对视图的设计和结构管理，让暴露出去的视图不要直接绑定在现有的表结构上 。视图所需的字段是外部需要，而不是表上面有什么 。这样视图就是接口，只不过是强耦合在特定的数据库实例上 。
拉-API获取
微服务最推荐的方式是服务方提供数据API，消费者需要的时候去拉取 。好处是消费者和供应方技术上完全解耦，坏处是提高了开发成本 。如果消费者使用API方式获取所需数据，建议使用异步Stream方式进行编程 。如果一次业务请求需要拉取多个数据源，不建议用同步的方式调用，因为会延长处理时间 。建议使用
推荐阅读
- 百度技术架构师总结：微服务架构之访问安全
- 最好的苏州风水师盘点
- 想给幼儿园老师送点礼 幼儿园教师节送什么
- 咽炎和喉炎区别
- 京东E卡电子卡如何使用
- 到医院看病挂普通医生号，还是挂副主任医师号？有什么区别？
- 考研|考研复试，这样跟导师见面能让他对你“感兴趣”！行动起来吧！
- 世界级魔术师 著名的魔术师
- 互联网架构演化
- 算法工程师应该具备哪些工程能力？