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

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

总结下来，异步的使用场景能够总结以下：

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

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

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

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

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

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

三、IO操做或者须要大量计算等耗时操做

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

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

但愿以上关于异步的总结能对你有用，经过异步的方式优化系统的伸缩性。若是你们有更好的建议，欢迎指正。

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

欢迎转载，带上如下二维码便可