阿里巴巴中台战略--业务流程异步化和数据库事务异步化

阿里巴巴中台战略

• 阿里共享事业部的产生、演变和发展
• 企业信息中心发展的症结
• 共享服务体系
• 分布式服务框架的选择
• 共享服务中心建设原则
• 数据库瓶颈阻碍业务的持续发展
• 数据库分库分表
• 数据库分库分表之异构索引表
• 业务流程异步化和数据库事务异步化
• 阿里巴巴中台战略–事务与柔性事务

业务流程异步化

  以淘宝的交易订单为例，目前淘宝的订单创建流程需要调用200个服务（下图是交易创建流程的示意），如果按照之前所有的业务逻辑均是在一个JVM中顺序执行的方式，要完成超过200次的远程服务调用，就算所有服务的调用时间都控制在20ms内返回结果，整个订单的创建时间也会超过4s,这个时间长度对于现在的客户来说已经很长了。

  另外从资源占用角度来说，这样的顺序调用的方式也一定会造成系统处理一次前端请求所花的时间较长，给服务的会话处理线程带来长时间的资源占用，对于服务器整体的系统吞吐量带来巨大的影响。

  可以使用异步化的方式将交易创建过程中，对于有严格先后调用关系的服务保持顺序执行，对于能够同步执行的所有服务均采用异步化方式处理。阿里巴巴使用消息中间件的方式实现了业务异步化，如下图。

  如上图示例中，订单创建场景，除了调用一些库存检查，用户校验这样一些从数据库读取数据进行业务判断的服务外，还会出现如预减库存、订单生成、支付生成等对数据库进行数据修改的服务。而订单生成服务属于交易中心的范畴，预减库存属于商品中心的服务，支付则需要调用支付宝的服务接口，那如何保证这些服务在一次订单请求中同时成功或失败？

数据库事务异步化

  关于数据库事务异步化的场景，可以使用一个客户还款场景为例。当一名借款人在改平台上成功借款后，例如借款金额为10万元，共有500人提供了借款，分为6期还款，每个月最后一天为该借款的当月还款日。当一个月的月底到来时，这名借款人会在平台上进行还款操作，即保证自己账号中的金额大于当月所需还款金额+利息+平台管理费的总额之后，点击“还款”按钮进行真正的还款操作，此时按照业务逻辑的设计，该还款操作将包含如下步骤。

  该步骤中仅仅示意了主要的核心功能，没有考虑到其他的业务逻辑。但从这个步骤中可以看出扣款是一个要求事务一致性的典型场景，稍微数据不一致带来的后果都可能是巨大的金额差异。所以在传统的实现方式中，整个扣款的逻辑代码都是在一个大的事务中，通过数据库的事务特性来实现这样一个稍微复杂的业务一致性。

  这样一个大的数据库事务中，每一位借款人进行的还款操作至少会引起500条还款详单（修改详单状态）+500次借款人账户表修改（扣款）+500名收款人账户表修改（收款），共计1500条数据表的修改，而平台的扣款日往往又集中在自然月的最后一天，这样就导致在最后一天的最后几个小时，平台接收到密集的还款请求，使得数据库的压力持续高水平运行，用户在进行一次还款操作最长要等到10分钟才能收到系统返回的结果。

  这个问题的根本原因就是大的数据库事务对数据库的资源占用、表记录长时间被事务锁住带来数据库的请求排队。

  针对这类场景，解决平台性能问题的核心就是数据库事务的异步化。通俗来说，就是将大事务拆分成小事务，降低数据库的资源被长时间事务锁占用而造成的数据库瓶颈，就能大大提升平台的处理吞吐量和事务操作的响应时间。

  在实际的改造方案中，同样基于消息服务提供的异步机制，将整个还款流程进行异步化的处理（如下图），在五个主要处理流程间（还款开始、还款计算、还款计划分配、还款计划处理、详单处理）通过消息服务进行下一步业务的触发，执行的步骤如下：

1. 当用户在平台点击了“还款”按钮后，会生成一条还款启动的消息，发送到消息服务上。
2. “还款开始”程序接收到此消息后，首先执行“找到未还款的计划”，并同时进行“写入还款请求”和发送“还款计划计算消息”到消息服务上
3. “还款计算”接收到还款计划计算消息后，进行还款总额的计算，并同时进行占款和发起支付流程的消息到消息服务上。
4. “还款计划分派”接收到支付流程的消息后，在给平台的账号转账的同时，发送分期支付消息，这里的消息会针对每一位还款详单中对应的还款人生成还款计划处理消息，这个处理是此次改造方案的核心，将之前一个事务中处理500次还款处理的操作拆分为500个不同的事务。
5. “还款计划处理”程序在接收每一个还款详单支付请求的消息后，进行详单查找，计算还款详单，最后同时进行从借款人账户中进行扣占款以及发送还款详单处理的请求消息。
6. 最后则是“还款详单”接收到“详单处理”请求的消息后，依次进行给还款人账户加钱，更新详单表信息等操作。

在此过程中，一定要考虑到程序异常时对业务的回滚或重试机制，保障整个还款过程结果的最终一致。