原标题：SaaS技术篇之数据库事务与微服务架构

先说说什么是数据库事务，举个栗子：一般淘宝下单，至少会发生两个过程：扣费和生成订单。扣费后，如果生成订单失败，就需要退款。假设没有数据库事务，开发者就要对“下单失败后还钱用户账户”进行编程，万一扣钱后服务器直接断电了，这又该怎么办？难道退款就这样被系统黑掉啦？非也！此时就需要事务来帮忙，以保证交易的平稳性和可预测性。

同时，数据库事务必须具有四种特性，否则在事务过程无法保证数据的正确性，交易过程极可能达不到交易方的要求。

?原子性（A）：要么全部执行成功，要么全部不执行；

?一致性（C）：一组写指令在提交前后，数据库表的关联记录是一致的；

?隔离性（I）：并发的两组提交是相互隔离的，一组提交不被另一组干扰；

?持久性（D）：一组指令一旦提交，它对数据库中对应数据的状态变更，就应该是永久性的。

什么是传统分布式事务？

如果一个后台服务同时直接连接多个数据库，它一组指令对不同数据库进行了操作，这组指令需要满足事务特性，这就是传统分布式事务了，与普通事务的区别在于“一组写指令同时包含了多个数据库”。而这种事务也有成熟的事务框架去解决，如JAVA的JTA，以及其他XA事务框架（二阶段提交、三阶段提交），基本不提升业务代码的复杂度。

微服务架构能用传统式事务解决方案吗？

如上图，微服务架构中每个服务都只能连接自己的数据库，如果订单服务想要改写客户服务的数据，则只能通过调用客户服务的接口来实现，显然传统分布式事务解决方案（XA、JTA）不再适用了，要解决这个问题，还需要了解一下相关理论。

一个分布式系统不可能同时满足一致性Consistency、可用性Availability、分区容错性Partition tolerance这三个基本需求，最多只能同时满足其中的两项。

?放弃P：放弃分布式、微服务；

?放弃A：遇到网络故障时，受影响的服务将不可用；

?放弃C：放弃一致性的话（这里指强一致），则系统无法让数据保持实时的一致性。

Basically Available（基本可用）、Soft state（软状态）、Eventually consistent（最终一致性），基于CAP定理演化而来，核心思想是即时无法做到强一致性，但每个应用都可以根据自身业务特点，采用适当的方式来使系统达到最终一致性：

要求更新过的数据能被后续的访问都能看到，这是强一致性；如果能容忍后续的部分或者全部访问不到，则是弱一致性；如果经过一段时间后要求能访问到更新后的数据，则是最终一致性。

从服务端角度，如何尽快将更新后的数据分布到整个系统，降低达到最终一致性的时间窗口，对于提高系统的可用度和用户体验来说非常重要。

一种适合微服务的最终一致性解决方案

从上图可以看出，二三阶段提交吞吐量要求低的时候，还是可以选择的，但是这仅限于传统分布式架构，对于微服务架构基本是不可用了，剩下几种都会遇到同一个问题：复杂度和吞吐量整体情况不乐观。

不过结合现在的开源环境来说，可靠事件模式的复杂度就不是太高了，所以个人认为此方案是不二选择，它的实现原理是利用消息队列来避免分布式事务：

比如在北京很有名的“姚记炒肝”点了炒肝并付了钱后，他们会让你拿着小票到出货区排队取。为什么他们要将付钱和取货两个动作分开呢？原因很多，其中一个很重要的原因是为了使他们接待能力增强（并发量更高）。回到我们的问题，只要这张小票在，你最终是能拿到炒肝的，即我们能依靠这个凭证（消息）完成最终一致性。

不难发现上述流程中小票十分重要，即使店家服务出现问题（网络超时，或者服务器断电）也必须保证：1、交钱必然有小票；2、用了小票必然有炒肝吃。类似，目前很多开源MQ（包括RabbitMQ，ActiveMQ，但不包括KAFKA，它不是可靠消息）方案都能很好的保障消息（小票）被可靠处理。

剩下的问题就是：如何把我们的多段提交的业务设计为类似“花钱买炒肝”这件事了，相信这个难不倒开发者们。

至于阿里GTS，我只能说：不觉明，但觉厉，毕竟不开源，不能免费用，没有实际测试报告的东西，我能说什么。