架构误区系列 6：万物异步化

异步化，是在分布式架构中为了解决容量问题、重试逻辑比较常用的一个技术手段。包括通过消息和通过定时任务。但是最近在做架构 Review 的过程中，发现了有过度使用异步化的趋势。

首先，我们要承认异步化对于架构设计带来的好处。在如下场景，会比较适用异步化处理：

• 缓冲：对于大量的请求，我们如果需要保护内部系统，有两种方式可以考虑：限流和异步化。如果是持续大流量同时超过长周期（比如一天）系统的处理能力，采用限流。如果是脉冲式的大流量，但是在长周期上统计上小于系统的处理能力，比如秒杀，比如 B 类业务特性带来的脉冲交易量，更适合用异步化。同时如果考虑异步化，需要在产品上衡量异步化带来的延迟对用户体验的影响。如果影响过大，可能也需要重新检讨异步化的设计。

• 对外部调用重试：外部系统的调用，往往我们需要视之为不可靠和长耗时的。对于此类的架构处理，比较正常的做法一在事务外、二采用异步任务，进行重试。

• 周期性工作：比如每日的公允价值计算、每月的计息和催收，这些都不是实时的交易请求，是周期性发生的任务，和银行的交易系统设计一样，采用异步批处理任务比较合理。

对于如下场景，就没必要或者不适用异步化的设计：

• 无渠道交互的普通交易，比如余额支付。在这种场景下，用户是需要实时看到结果的，而且如果系统出现异常，一般需要用户发起重试。这时候，架构设计直接通过实时的调用链路完成全链路同时返回用户结果就可以。这里如果采用落单，然后再异步推进，首先处理的复杂度提高了，其次用户的交互体验不是太好。

• 有渠道交互的下单交易，这里要区分渠道的特性进行处理：

• 如果渠道是低耗时的，比如通过支付宝的支付、国内银行的实时转账。可以考虑对于渠道采用异步化（避免长链接，或者渠道接口特性决定），对用户采用异步转同步的交互，提升用户体验。

• 如果渠道是高耗时或者是异步响应的，比如国外支付渠道的请求/回执机制。这里可能需要考虑重新设计产品的交互体验，也通过异步通知的方式给到用户交易结果。

• 查询逻辑，用实时处理的模式比较合适。如果需要避免大量的并发查询，可以考虑几种架构设计：

• 合并查询：对于同一个时间段内同一个用户发出的查询，采用合并后发一笔请求到后台的查询，避免由于网络抖动引起的大量查询。

• 缓存机制。

• 前端的倒计时控制。

总之，我们在做架构设计的时候，需要根据不同的业务场景，合理的原则同步调用和异步化处理。考虑的维度包括用户体验、请求并发度、系统耗时、外部依赖等，不应该将不同的场景用同样一个架构模式去硬套。