微服务能否完全规避同步调用？同步与异步选型疑问

1. 异步调用是否无需熔断/重试/限流？ #

不是。异步调用同样需要这些容错机制，原因如下：

• 重试：消息投递失败（比如MQ集群故障、网络波动）时，重试能避免消息丢失，保证业务最终一致性；比如订单服务给支付服务发的支付请求消息，如果投递失败，必须重试才能让支付流程正常推进。
• 限流：如果上游服务疯狂发消息，超出MQ的存储上限或下游消费能力，会导致消息堆积甚至MQ崩溃，限流能控制消息发送速率，避免雪崩。
• 熔断：当下游服务长期消费失败（比如支付服务彻底宕机），继续发消息只会加剧堆积，熔断可以暂时停止发送，等待下游恢复后再恢复，减少无效资源消耗。

2. 为什么要采用同步调用搭配熔断/重试/限流？同步调用只适用于缓存场景？ #

同步调用的存在是因为业务场景的实时性需求，绝非仅适用于缓存场景：

• 很多业务必须立刻拿到结果才能继续，比如用户下单时查询库存是否充足、用户支付时实时验证余额，这类场景下异步调用无法满足，必须同步。
• 同步调用的可扩展性问题确实存在，但熔断/重试/限流是用来缓解而非解决这个问题的：熔断能防止下游故障扩散到上游，重试能提升请求成功率，限流能避免下游被压垮，让同步调用在可控范围内稳定运行。
• 同步调用的优势是架构简单，不需要引入MQ等中间件，开发和维护成本更低，对于简单的、低并发的实时交互场景，同步调用反而更高效。

3. 如何选择同步或异步调用？是否要完全规避同步？ #

完全规避同步调用的说法太绝对，选择核心看业务需求：

• 优先选同步的场景：
  • 需要实时获取结果才能继续后续流程的业务（比如用户登录验证、下单时的库存校验）
  • 交互逻辑简单、低并发的场景，同步调用架构更简洁
• 优先选异步的场景：
  • 非实时性需求的业务（比如订单完成后发送短信通知、生成月度报表）
  • 需要解耦上下游的场景，比如订单服务不需要等待物流服务处理完成再返回给用户
  • 高并发场景，异步能削峰填谷，避免同步调用的阻塞问题

同步调用的可扩展性问题可以通过容错机制（熔断/重试/限流）、集群扩容等方式优化，异步调用虽然解耦，但也引入了消息队列的复杂度（比如消息重复、丢失、一致性问题），不存在绝对的优劣，要结合业务场景权衡。

内容的提问来源于stack exchange，提问作者john