6.1　业务流程异步化

平台进行服务化后，在平台页面上发起的业务请求势必需要将后端不同的服务进行组合调用来实现业务请求的处理。以淘宝的交易订单为例，目前淘宝的订单创建流程需要调用超过200个服务（图6-1是交易创建流程的示意），如果按照之前所有业务逻辑均是在一个JVM中顺序执行的方式，要完成超过200次的远程服务调用，就算所有服务的调用时间都控制在20ms内返回结果，整个订单创建的时间也会超过4s，这个时间长度对于今天互联网时代的客户来说已经超过了忍耐极限。

图6-1　淘宝交易流程按服务线性处理的示意图

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

其实稍微有点设计经验的技术人员都会想到以异步化方式将交易创建过程中，对于有严格先后调用关系的服务保持顺序执行，对于能够同步执行的所有服务均采用异步化方式处理。阿里巴巴内部使用消息中间件的方式实现了业务异步化，异步化后的业务处理流程如图6-2所示，提高了服务的并发处理，从而大大减少整个业务请求处理所花的时间。目前淘宝平台从用户点击订单创建到返回订单创建成功的页面平均时间控制在300ms左右，让用户有非常好的用户体验，同时整个平台的吞吐量也会得到几何倍数的提升。

应该说这里提到的业务异步化是非常容易理解的一个概念，在非互联网应用场景中也会大量使用，比如在企业公文审批应用场景中，当整个审批流程最后完成时，会自动给当前审批流程中所有的经办人发送系统消息。实现的方式大多数是将发送的消息投递到消息队列中，再由消息队列的消费端程序将消息发送到各办理人，而在执行审批流程完成时无需等到所有消息成功发送后，再给执行审批完结这一步骤的人员返回操作成功的结果。但这样类似的大多数场景，通过异步化被分割的两部分逻辑处理并没有太多事务性的关系，即一般是前面部分的逻辑处理（公文审批示例中完成审批流程的操作）成功后，后面那部分（消息的发送）是否成功执行不会对前一部分的处理结果产生影响，也就是消息发送和审批完结这两个事件没有事务关系。

图6-2　淘宝交易流程异步化后的处理示意图

回到示例中的淘宝订单创建场景，除了调用一些库存检查、用户校验这样一些从数据库读取数据进行业务判断的服务外，还会出现如预减库存、订单生成、支付生成等这些对数据库进行数据修改操作的服务。而订单生成的服务属于交易服务中心的范畴，预减库存则属于商品服务中心提供的服务，支付记录还要调用支付宝所提供的服务接口，那如何保证这些服务在一次订单请求中同时成功或失败？接下来介绍如何解决这类问题。