本章内容，主要探讨讯息伫列在服务呼叫方面的应用。
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应用服务能力的提升至关重要。
基于讯息的异步呼叫
应用丛集对外的服务能力增强，是不是意味着内部服务也需要同步提升处理能力呢？针对电商的特点，促销时大并发，平时流量一般，整个服务丛集处理能力都提升到和高峰匹配，显然是不经济的。按照上面的介绍，只需要把下单过程的处理能力增强就可以了。
高并发、大批量的下单，订单资讯推送到伫列，其他服务根据处理能力逐个处理，虽然有延迟，但都能够得到正确的处理。这就体现了讯息伫列消除波峰的能力。
解耦。
还是接着讲述下单的过程。下单过程可能还包括询价、记录日志等服务。下单在订单系统，扣减库存是在仓储系统，询价在定价系统，记录日志则在日志系统。按照同步的模式，在的订单系统 逐个呼叫扣减库存界面、询价界面、记录日志界面等。这样订单系统和其他三个系统，就有了强耦合，某一个系统出故障 ，导致客户无法下订单。
同步呼叫
采用讯息伫列的方式，下单后把订单资讯传送到伫列，其他系统监听伫列，收到订单资讯后进行处理。订单系统不再依赖其他几个系统，甚至不知道其他系统的存在，这样就实现了解耦的目的。
总结：上面介绍了伫列的三个使用场景，异步化、消峰、解耦，很多时候，讯息伫列的作用是三位一体的，从不同的角度看，完成了不同的功能。
