微服务架构的分布式事务问题如何处理？

分布式系统架构中，分布式事务问题是一个绕不过去的挑战。而微服务架构的流行，让分布式事问题日益突出！

下面我们以电商购物支付流程中，在各大参与者系统中可能会遇到分布式事务问题的场景进行详细的分析！

如上图所示，假设三大参与平台（电商平台、支付平台、银行）的系统都做了分布式系统架构拆分，按上数中的流程步骤进行分析：

1、电商平台中创建订单：预留库存、预扣减积分、锁定优惠券，此时电商平台内各服务间会有分布式事务问题，因为此时已经要跨多个内部服务修改数据；

2、支付平台中创建支付订单（选银行卡支付）：查询账户、查询限制规则，符合条件的就创建支付订单并跳转银行，此时不会有分布式事务问题，因为还不会跨服务改数据；

3、银行平台中创建交易订单：查找账户、创建交易记录、判断账户余额并扣款、增加积分、通知支付平台，此时也会有分布式事务问题（如果是服务化架构的话）；

4、支付平台收到银行扣款结果：更改订单状态、给账户加款、给积分帐户增加积分、生成会计分录、通知电商平台等，此时也会有分布式事务问题；

5、电商平台收到支付平台的支付结果：更改订单状态、扣减库存、扣减积分、使用优惠券、增加消费积分等，系统内部各服务间调用也会遇到分布式事问题；

如上图，支付平台收到银行扣款结果后的内部处理流程：

1、支付平台的支付网关对银行通知结果进行校验，然后调用支付订单服务执行支付订单处理；

2、支付订单服务根据银行扣款结果更改支付订单状态；

3、调用资金账户服务给电商平台的商户账户加款（实际过程中可能还会有各种的成本计费；如果是余额支付，还可能是同时从用户账户扣款，给商户账户加款）；

4、调用积分服务给用户积分账户增加积分；

5、调用会计服务向会计（财务）系统写进交易原始凭证生成会计分录；

6、调用通知服务将支付处理结果通知电商平台；

如上图，把支付系统中的银行扣款成功回调处理流程提取出来，对应的分布式事务问题的代码场景：

/ 支付订单处理 /

@Transactional(rollbackFor = Exceptionclass)

public void completeOrder() {

  orderDaoupdate();  // 订单服务本地更新订单状态

  accountServiceupdate();  // 调用资金账户服务给资金帐户加款

  pointServiceupdate();  // 调用积分服务给积分帐户增加积分

  accountingServiceinsert();  // 调用会计服务向会计系统写入会计原始凭证

  merchantNotifyServicenotify();  // 调用商户通知服务向商户发送支付结果通知

}

本地事务控制还可行吗？

以上分布式事务问题，需要多种分布式事务解决方案来进行处理。

订单处理：本地事务

资金账户加款、积分账户增加积分：TCC型事务（或两阶段提交型事务），实时性要求比较高，数据必须可靠。

会计记账：异步确保型事务（基于可靠消息的最终一致性，可以异步，但数据绝对不能丢，而且一定要记账成功）

商户通知：最大努力通知型事务（按规律进行通知，不保证数据一定能通知成功，但会提供可查询操作接口进行核对）

　　既然是分布式系统，系统间通信的技术就不可避免的要掌握。

　　首先，我们必须掌握一些基本知识，例如网络通信协议（例如TCP / UDP等），网络IO（Blocking-IO，NonBlocking-IO，Asyn-IO），网卡（多队列等）。   了解有关连接重用，序列化/反序列化，RPC，负载平衡等的信息。

　　在学习了这些基本知识之后，您基本上可以在分布式系统中编写一个简单的通信模块，但这实际上还远远不够。 现在，您已经进入了分布式字段，您已经对规模有很多要求。 这意味着需要一种通信程序，该程序可以支持大量连接，高并发性和低资源消耗。

　　大量的连接通常会有两种方式：

　　大量client连一个server

　　当前在NonBlocking-IO非常成熟的情况下，支持大量客户端的服务器并不难编写，但是在大规模且通常是长连接的情况下，有一点需要特别注意 ，即服务器挂起时不可能所有客户端都在某个时间点启动重新连接。 那基本上是一场灾难。 我见过一些没有经验的类似案例。 客户端规模扩大后，服务器基本上会在重新启动后立即刷新。 大量传入连接中断（当然，服务器的积压队列首先应设置为稍大一些）。 可以使用的通常方法是在客户端重新连接之前睡眠一段随机的时间。 另外，重连间隔采用避让算法。

　　一个client连大量的server

　　有些场景也会出现需要连大量server的现象，在这种情况下，同样要注意的也是不要并发同时去建所有的连接，而是在能力范围内分批去建。

　　除了建连接外，另外还要注意的地方是并发发送请求也同样，一定要做好限流，否则很容易会因为一些点慢导致内存爆掉。

　　这些问题在技术风险上得考虑进去，并在设计和代码实现上体现，否则一旦随着规模上去了，问题一时半会还真不太好解。

　　高并发这个点需要掌握CAS、常见的lock-free算法、读写锁、线程相关知识（例如线程交互、线程池）等，通信层面的高并发在NonBlocking-IO的情况下，最重要的是要注意在整体设计和代码实现上尽量减少对io线程池的时间占用。

　　低资源消耗这点的话NonBlocking-IO本身基本已经做到。

　　伸缩性

　　分布式系统基本上意味着规模不小。 对于此类系统，在设计时必须考虑可伸缩性。 在体系结构图上绘制的任何点，如果请求量或数据量继续增加，该怎么办？ 通过添加机器来解决。 当然，此过程不需要考虑无限的情况。 如果您有经验的建筑师，从相对较小的规模到非常大型的范围，那么优势显然并不小，而且它们也将越来越稀缺。  。

　　横向可扩展性（Scale Out）是指通过增加服务器数量来提高群集的整体性能。 垂直可伸缩性（Scale Up）是指提高每台服务器的性能以提高集群的整体性能。 纵向可扩展性的上限非常明显，而分布式系统则强调水平可伸缩性。

　　分布式系统应用服务最好做成无状态的

　　应用服务的状态是指运行时程序因为处理服务请求而存在内存的数据。分布式应用服务最好是设计成无状态。因为如果应用程序是有状态的，那么一旦服务器宕机就会使得应用服务程序受影响而挂掉，那存在内存的数据也就丢失了，这显然不是高可靠的服务。把应用服务设计成无状态的，让程序把需要保存的数据都保存在专门的存储上(eg 数据库)，这样应用服务程序可以任意重启而不丢失数据，方便分布式系统在服务器宕机后恢复应用服务。

　　伸缩性的问题围绕着以下两种场景在解决：

　　无状态场景

　　对于无状态场景，要实现随量增长而加机器支撑会比较简单，这种情况下只用解决节点发现的问题，通常只要基于负载均衡就可以搞定，硬件或软件方式都有；

　　无状态场景通常会把很多状态放在db，当量到一定阶段后会需要引入服务化，去缓解对db连接数太多的情况。

　　有状态场景

　　所谓状态其实就是数据，通常采用Sharding来实现伸缩性，Sharding有多种的实现方式，常见的有这么一些：

　　21 规则Sharding

　　基于一定规则把状态数据进行Sharding，例如分库分表很多时候采用的就是这样的，这种方式支持了伸缩性，但通常也带来了很复杂的管理、状态数据搬迁，甚至业务功能很难实现的问题，例如全局join，跨表事务等。

　　22 一致性Hash

　　一致性Hash方案会使得加机器代价更低一些，另外就是压力可以更为均衡，例如分布式cache经常采用，和规则Sharding带来的问题基本一样。

　　23 Auto Sharding

　　Auto Sharding的好处是基本上不用管数据搬迁，而且随着量上涨加机器就OK，但通常Auto Sharding的情况下对如何使用会有比较高的要求，而这个通常也就会造成一些限制，这种方案例如HBase。

　　24 Copy

　　Copy这种常见于读远多于写的情况，实现起来又会有最终一致的方案和全局一致的方案，最终一致的多数可通过消息机制等，全局一致的例如zookeeper/etcd之类的，既要全局一致又要做到很高的写支撑能力就很难实现了。

　　即使发展到今天，Sharding方式下的伸缩性问题仍然是很大的挑战，非常不好做。

　　上面所写的基本都还只是解决的方向，到细节点基本就很容易判断是一个解决过多大规模场景问题的架构师，:)

　　稳定性

　　作为分布式系统，必须要考虑清楚整个系统中任何一个点挂掉应该怎么处理（到了一定机器规模，每天挂掉一些机器很正常），同样主要还是分成了无状态和有状态：

　　无状态场景

　　对于无状态场景，通常好办，只用节点发现的机制上具备心跳等检测机制就OK，经验上来说无非就是纯粹靠4层的检测对业务不太够，通常得做成7层的，当然，做成7层的就得处理好规模大了后的问题。

　　有状态场景

　　对于有状态场景，就比较麻烦了，对数据一致性要求不高的还OK，主备类型的方案基本也可以用，当然，主备方案要做的很好也非常不容易，有各种各样的方案，对于主备方案又觉得不太爽的情况下，例如HBase这样的，就意味着挂掉一台，另外一台接管的话是需要一定时间的，这个对可用性还是有一定影响的；

　　全局一致类型的场景中，如果一台挂了，就通常意味着得有选举机制来决定其他机器哪台成为主，常见的例如基于paxos的实现。

　　可维护性

　　维护性是很容易被遗漏的部分，但对分布式系统来说其实是很重要的部分，例如整个系统环境应该怎么搭建，部署，配套的维护工具、监控点、报警点、问题定位、问题处理策略等等。