调用接口 500 servererror_架构实战(9)——基于消息的异步调用

本章内容，主要探讨消息队列在服务调用方面的应用。

RPC调用VS消息队列

在分布式应用中，服务之间的调用主要有两种模式：基于RPC的同步调用模式，基于消息的异步调用模式。在实际的应用实践中，RPC调用更为常用，和普通的函数调用方式一样，学习成本低，调试也更加简单。RPC调用，理论上都可以用消息的方式替代，但几乎没有人这么做，那么什么样的情况，需要用基于消息调用呢？

解答这个问题，先来看下这两种调用的实现方式。RPC调用非常简单，调用请求直接到服务的提供方，提供方把执行结果，反馈给调用方。消息队列调用，调用方首先发送消息到队列，提供方从队列消费消息，处理消息，这是单向的，调用方不能同步拿到执行结果。提供方反馈执行结果，一般有两种实现方式，一是通多队列发送执行结果给调用方，二是调用方提供回调接口，提供方调用回调接口发送执行结果。

RPC同步调用和基于消息的异步调用

异步化——优化性能

先来看一下同步调用，接口A调用接口B和接口C，每个接口的执行时间为50ms，不考虑调用过程的时间损耗。

串行调用。这是典型的同步调用方式，接口A调用B，然后调用C，整个过程的执行时间是150ms。

串行调用

并行调用。接口A用B和C同步执行，执行时间取决于B和C的最大执行时间，去最大值50毫秒，整个过程的执行时间是100ms。并行执行，提升了整体的执行效率，但增加了程序的复杂性。在研发实践中，简单的业务可以用并行策略，例如并行下载、上传等，含有复杂业务、有事务性要求的场景，并行策略实现起来特别复杂，慎用。

并行调用

针对并行执行的效率优化，还可以采用异步化的策略。在实践中，异步化主要有两种方式，一种是借助于多线程技术，创建多个线程异步执行；另一种是借助于第三方工具，以生产者-消费者的模式实现异步调用，而消息队列就是那个最长用的工具。

基于线程的异步调用：接口A调用其他接口时，把调用接口的逻辑丢个线程池去执行，调用线程池的时间可以忽略不计。在外界看来，接口A执行时间是50ms，提升了效率。

• 优点：模型简单，不借助第三方工具，程序内解决。
• 缺点：执行失败调用方无感知，不能回退；线程调用是一次性的，无法回退。

基于线程的异步调用

基于消息的异步调用：接口A调用其他接口，发送消息到队列，接口B和接口C监听队列，收到消息后执行。发送消息到队列的时间可以忽略不计，接口A的执行时间是50ms。

• 优点：消费方可提供丰富的解决方案，解决数据一致性、事务性的问题。例如：重试机制减少失败可能性，私信队列处理失败的情况，幂等性避免接口的重复执行等。
• 缺点：增加了编程的复杂度。

基于消息的异步调用

消除波峰。

看下电商的应用场景，在手机端操作下单，后台可能包括多个动作，例如下单、扣减库存、扣款等环节。下单过程很简单，耗时100ms；扣减库存耗时300ms；扣款耗时500ms。

采用同步的模式，这个过程的执行时间是900ms，假设单台tomcat实例支持500个线程，这种情况下，单台服务支持的最大QPS是500/0.9 = 555。

同步调用

采用异步的模式，下单过程是100ms，同样的服务配置下，单台服务支持的最大QPS是500 / 0.1 = 5000、提升了9倍，异步化的优化对web应用服务能力的提升至关重要。

基于消息的异步调用

应用集群对外的服务能力增强，是不是意味着内部服务也需要同步提升处理能力呢？针对电商的特点，促销时大并发，平时流量一般，整个服务集群处理能力都提升到和高峰匹配，显然是不经济的。按照上面的介绍，只需要把下单过程的处理能力增强就可以了。

高并发、大批量的下单，订单信息推送到队列，其他服务根据处理能力逐个处理，虽然有延迟，但都能够得到正确的处理。这就体现了消息队列消除波峰的能力。

解耦。

还是接着讲述下单的过程。下单过程可能还包括询价、记录日志等服务。下单在订单系统，扣减库存是在仓储系统，询价在定价系统，记录日志则在日志系统。按照同步的模式，在的订单系统 逐个调用扣减库存接口、询价接口、记录日志接口等。这样订单系统和其他三个系统，就有了强耦合，某一个系统出故障 ，导致客户无法下订单。

同步调用

采用消息队列的方式，下单后把订单信息发送到队列，其他系统监听队列，收到订单信息后进行处理。订单系统不再依赖其他几个系统，甚至不知道其他系统的存在，这样就实现了解耦的目的。

总结：上面介绍了队列的三个使用场景，异步化、消峰、解耦，很多时候，消息队列的作用是三位一体的，从不同的角度看，完成了不同的功能。