说实话，分布式系统的复杂度远大于它的好处

最近，有一位酷酷的程序员小哥（由网站头像可得）在Hacker Noon网上发表了一篇名为《全面解析分布式系统》的文章。和以往烂大街的分布式教程不太一样，这位小哥在文末写道：

文章链接：

https://hackernoon.com/a-thorough-introduction-to-distributed-systems-3b91562c9b3c

图片不方面粘贴文字去谷歌翻译里看中文吧？

让二把刀的我来给大家伙儿整个翻译：

友情提示，

珍爱生命，远离分布式系统。如果你能找到别的简单、好学、易上手的方法代替分布式系统，就别考虑它了。要知道，它的复杂度远远大于它的好处。

（本翻译仅代表个人观点，有异议留言区见~）

为什么这么说呢？

分布式系统的优势有目共睹，稳定性强，能够解决高并发情况下的很多问题，保障业务顺利安全地进行。

但是这其中的辛劳，只有分布式系统的工程师才能体会。

复杂性，是分布式系统与生俱来的气质；高吞吐、负载均衡、低延迟等问题，都是必须要解决的。一招不慎，可能不用业务的大流量来考验，系统自己的问题就把自己整崩溃了。所以市面上对分布式系统研发工程师招聘时通常需要其具备发散思维、考虑全面、经验丰富等条件。

吐槽归吐槽，知识还是要学习的，毕竟还要找工作。

微服务和分布式在复杂性这一点上，有很多共通之处，不幸地是，这次，他们二者还撞在一起了。下文，我们就以阿里巴巴提出的分布式事务解决方案——GTS为例，为大家深入解读微服务架构下分布式事务解决方案。

基于 XA 协议的两阶段提交方案

交易中间件与数据库通过 XA 接口规范，使用两阶段提交来完成一个全局事务， XA 规范的基础是两阶段提交协议。

第一阶段是表决阶段，所有参与者都将本事务能否成功的信息反馈发给协调者；第二阶段是执行阶段，协调者根据所有参与者的反馈，通知所有参与者，步调一致地在所有分支上提交或者回滚。

两阶段提交方案应用非常广泛，几乎所有商业 OLTP 数据库都支持 XA 协议。但是两阶段提交方案锁定资源时间长，对性能影响很大，基本不适合解决微服务事务问题。

TCC 方案

TCC 方案在电商、金融领域落地较多。TCC 方案其实是两阶段提交的一种改进。其将整个业务逻辑的每个分支显式的分成了 Try、Confirm、Cancel 三个操作。Try 部分完成业务的准备工作，confirm 部分完成业务的提交，cancel 部分完成事务的回滚。基本原理如下图所示。

事务开始时，业务应用会向事务协调器注册启动事务。之后业务应用会调用所有服务的 try 接口，完成一阶段准备。之后事务协调器会根据try接口返回情况，决定调用 confirm 接口或者 cancel 接口。如果接口调用失败，会进行重试。

TCC 方案让应用自己定义数据库操作的粒度，使得降低锁冲突、提高吞吐量成为可能。 当然 TCC 方案也有不足之处，集中表现在以下两个方面：

• 对应用的侵入性强。业务逻辑的每个分支都需要实现 try、confirm、cancel 三个操作，应用侵入性较强，改造成本高。
• 实现难度较大。需要按照网络状态、系统故障等不同的失败原因实现不同的回滚策略。为了满足一致性的要求，confirm 和 cancel 接口必须实现幂等。

上述原因导致 TCC 方案大多被研发实力较强、有迫切需求的大公司所采用。微服务倡导服务的轻量化、易部署，而 TCC 方案中很多事务的处理逻辑需要应用自己编码实现，复杂且开发量大。

基于消息的最终一致性方案

消息一致性方案是通过消息中间件保证上、下游应用数据操作的一致性。基本思路是将本地操作和发送消息放在一个事务中，保证本地操作和消息发送要么两者都成功或者都失败。下游应用向消息系统订阅该消息，收到消息后执行相应操作。

消息方案从本质上讲是将分布式事务转换为两个本地事务，然后依靠下游业务的重试机制达到最终一致性。基于消息的最终一致性方案对应用侵入性也很高，应用需要进行大量业务改造，成本较高。