分布式架构中异步的使用场景

昨天的文章里提到了微服务间通信的方式，今天会进一步讨论一下，在分布式架构中，我们如何选择异步和同步来进行服务间的调用。

总结下来，异步的使用场景可以总结如下：

1、不影响主线程逻辑，不涉及共享资源，或对共享资源只读，即非互斥操作

关于这一条，继续用订单服务与供应链服务的例子，订单下单成功后，主流程直接返回成功，将该订单的详情通过MQ，异步推送给供应链系统，供应链系统后续执行的结果并不影响订单的生成流程。

如果服务A同步调用服务B，那么A和B就是紧密耦合的，而紧耦合的系统其可伸缩性特征是各服务必须要保持一个节奏，要伸缩服务A必须同时伸缩服务B，同步调用的服务在可用性方面也面临着同样的问题。反过来说，如果服务A和B的通信是异步的，不管是通过MQ或者批处理还是其他什么手段，可以各自根据系统的情况，执行必要的伸缩操作。而且，此时服务A和B的是相互独立的，即使服务B不能正常使用，服务A仍然能够继续工作。

2、服务间交互的数据，在时序上的没有严格关系

订单服务传送给供应链服务的订单数据，比如说订单A和订单B，他们传给供应链系统的时序，并不影响供应链服务处理流程，对最终的业务结果没有任何影响。再举一个例子，就是我们的站内推送和各种消息，所有这些消息发放给客户端，并不在乎消息发送给某个客户的先后顺序，只要保证消息最终能顺利发送完毕即可，所以推送给消息服务会采用异步的形式。

【醒目】反过来说，如果需要结果的处理始终和前文保持在一个上下文内，必须要使用同步。

3、IO操作或者需要大量计算等耗时操作

这个情况主要用于前端AJAX的情况，先将成功状态返回，几秒后，将详情返回，局部刷新页面。对于网站或者交易系统，消耗数据或执行的延迟时间来换取用户的延迟时间是值得的，因为用户的体验会因此得到提升。活动跟踪、单据开付和报表等处理过程显然都应该属于后台活动，很多步骤可以进一部分解成异步运行，任何可以晚点再做的事情都应该晚点再做。

多说一句，异步性可以从一定程度上降低系统投入的成本。常规的同步操作需要系统必须按照负载的峰值来配备基础设施，即使在大促做年度活动的时间周期里任务最重的时刻，系统也必须有能力立即完成处理。将处理过程转变为异步的流，系统就不需要按照峰值来配备，只需要满足平均负载。异步队列可以将处理任务分摊到较长的时间里，起到削峰的作用。系统的负载变化越大，曲线越多尖峰，就越能从异步处理中得益。

希望以上关于异步的总结能对你有用，通过异步的方式优化系统的伸缩性。如果大家有更好的建议，欢迎指正。

扫描二维码或手动搜索微信公众号： ForestNotes

欢迎转载，带上以下二维码即可