微服务拆分后遇到的一个麻烦是分布后的一致性问题。单体架构的业务处理和数据都在一个进程里面，一致性保障很成熟，开发人员基本上不用关心。当把业务系统拆分到不同进程时，就遇到了技术性一致性问题。这带来了纠结，我们希望有一颗银弹，一把解决问题。但由于分布式一致性在(CAP)理论上没有完美的解决方案，我们所能选择的方案是在特定业务场景下的选择。
我们这里讨论的分布是指业务逻辑上做了拆分导致的分布，而不是数据量特别大导致的分布。
如果业务上不拆分，数据量特别大需要做分布，可以选择支持大数据的分布式数据库。可以选择Cassandra, MongoDB等NoSQL，或者TiDB这类支持SQL的分布式方案。
如果业务上进行了拆分，不论选什么数据库都不能解决分布式一致性问题。把数据库或者分布式数据库看成是一个系统，能处理一个外部请求在数据库内部的分布式问题，但不能处理多个外部请求的一致性问题。
分布式强一致的数据库不能解决业务逻辑拆分带来的分布式一致性问题，我们还得继续纠结如何解决业务分布式一致性的问题。
首先我把微服务分布式一致性问题分为数据共享一致性和业务交易一致性问题。
一、数据共享一致性
在单体架构的时候用同一个数据库，不存在数据共享问题。微服务强调要独立数据库，引起数据如何共享的问题。
数据共享分为拉和推两种模式，拉指消费者去供应商那边拉数据，推指供应商主动把数据推到消费者面前。
1. 拉-视图共享
对于一般的企业信息系统，数据量不大，并发需求也不大，我建议所有的微服务用同一个数据库实例，但是拆分在不同的Schema。这样的好处是在业务逻辑上数据库是独立的，也可以独立演进。然后数据库又可以集中管理。这个方案对于大型遗留系统拆分尤其适用，因为原本就是在一个库里面，为了业务更好的独立演进进行数据库Schema拆分，又能延续原有的数据库实例管理技术。由于不同的微服务实际运行在同一个数据库实例上，可以简单地建视图进行数据共享。
需要注意的是，不要拉整个表出去，根据需要选择几个字段。这种模式技术上简单，坏处有两个：一是由于视图同步的数据是实时的，应用可能基于实时同步数据的假设进行设计，会导致以后做分布式扩展的时候特别困难;二是视图很容易暴露出表结构，这需要特别加强对视图的设计和结构管理，让暴露出去的视图不要直接绑定在现有的表结构上。视图所需的字段是外部需要，而不是表上面有什么。这样视图就是接口，只不过是强耦合在特定的数据库实例上。
2. 拉-API获取
微服务最推荐的方式是服务方提供数据API，消费者需要的时候去拉取。好处是消费者和供应方技术上完全解耦，坏处是提高了开发成本。如果消费者使用API方式获取所需数据，建议使用异步Stream方式进行编程。 如果一次业务请求需要拉取多个数据源，不建议用同步的方式调用，因为会延长处理时间。建议使用reactiveX模式进行异步拉取和组装 。
3. 推-事件消息
发生事件时发送消息是DDD CQRS模式，即解决了消费者要拥有数据用的爽快的问题(根据需要建立本地数据结构、获取性能和方式), 也解决了数据库技术异构的问题。带来的问题是需要一个消息平台，并且消费者或者供应方都要耦合在一个消息平台技术上。对于大型遗留系统改造不是很友好，一方面遗留系统的消息平台往往不符合高并发大数据量的性能要求，另一方面对于新的微服务也不想依赖老的消息平台，而想要用Kafka这样的互联网高并发轻量的消息平台。
4. 数据共享一致性选择总结：
对于遗留系统改造和数据量不大(日交易量不超过百万)的应用，建议使用不同微服务创建不同Schema，但用同一个数据库实例，然后通过视图的方式进行数据共享。
如果有些业务数据量非常大又需要共享，使用API共享，利用异步Stream编程进行数据共享。
如果微服务平台技术设施成熟，可以使用推送事件消息模式， 既解决共享数据消费便利性问题，又解决数据结构解耦，并且使用轻量消息平台(Kafka)只是有轻度的技术耦合。
二、业务交易分布式一致性
业务交易分布式一致性指一次请求，但分布在不同的微服务系统处理，引发一致性协调的问题。
交易分布式一致性分为补偿模式，二次提交模式和Saga模式。
1. 补偿模式
补偿模式主要是通过重试达到最后的成功，仅适用于交易请求在业务上必须没有失败的场景。
补偿模式用的最普遍的是消息投递，假设给A发消息，如果没有收到A确认消息已收到，就继续发送，直到A确认收到消息为止。
有很多业务可以变成必须成功的交易。比如下订单付款，如果先确认订单再去扣款，就有可能因为账户没钱扣款不成功，导致业务上的失败。如果业务改成先扣款再去确认订单，那可以认为订单必须要确认成功。通过业务顺序的调整来实现一个交易必须成功的情境。在技术实现上比较简单，利用一个任务队列跟踪任务的完成状态，来决定重试。补偿模式对API的要求是必须要幂等，因为有可能任务已经成功了，但消费者不知道，再次发出任务请求。
2. 二次提交模式
由于补偿模式需要对业务进行调整，适用范围也比较小，我们还是希望有个通用的分布式一致性方案。
最有名的应该是二次提交模式，更具体点是TCC(Try,Confirm,Cancel)。先发起try请求让业务任务参与方做好处理准备，等所有的参与方都做好准备后，再发出confirm进行确认。因为所有的业务参与方都事前做好了准备，在confirm阶段可以确保一次性成功。
如果有某个参与方识别，则发cancel进行回滚。这种模式和数据的事务管理基本一样，像Java的JTA实现Automikos就是从支持数据库事务，也支持REST API。二次提交虽然能解决事务一致性问题，但成本比较高。一个业务处理必须要拆分为准备和确认执行两个阶段，对业务设计要求和开发成本都比较高。
3. Sagas模式
Sagas模式在补偿模式和二次提交模式，既简单又能广泛支持分布式事务场景。二次提交模式基于悲观锁，所以先要求任务参与方都做好准备，然后再做执行。
Saga和补偿模式是基于乐观锁，先让任务参与方执行，如果执行没响应则要求再次执行。Saga给参与方发出任务后会记录一个event(Saga的中文翻译可以是事迹)，所有event都会持久化。如果某个参与方执行失败，再发出cancel请求要求所有参与方回退。因为大部分交易请求是成功，这种基于乐观锁的协调机制能达成一致性目的，并降低了开发成本，业务设计上也比较容易理解。
目前支持Saga的Java框架有华为开源的servicecomb saga，京东已经有些线上系统用了。还有做CQRS的框架axoniq也实现了saga。
【本文为51CTO专栏作者“张逸”原创稿件，转载请联系原作者】
