MassTransit请求/响应模式：为何及何时在微服务中使用？

你觉得请求/响应和同步API类似很正常，但两者的核心差异和适用场景其实差得挺远，下面给你掰扯清楚：

为什么不直接用同步API？ #

• 容错性拉满：如果目标服务临时挂了或者过载，同步API直接炸报错，但MassTransit的请求会存在队列里，等服务恢复后自动重试，绝不会丢请求。
• 天然削峰：突然涌来一批请求？同步API可能直接把服务压垮，队列能把请求缓冲起来，消费者按自身能力慢慢处理，完美避免服务雪崩。
• 彻底解耦：同步API得硬编码目标服务地址，地址一变调用方就得跟着改；用请求/响应的话，只需要约定好消息契约，服务部署在哪、怎么扩缩容，调用方完全不用管。
• 异步不阻塞：有些请求本身处理耗时就长，比如生成报表、处理大文件，同步API会让调用方线程一直卡着等超时，而请求/响应模式下，调用方可以先去干别的，等消息回来再处理响应，还能自己设超时时间，灵活得很。

什么时候该用请求/响应模式？ #

• 关键操作不能丢：比如支付请求、订单创建这类核心业务，哪怕服务暂时挂了，也得保证请求最终能被处理。
• 处理耗时较长的场景：像生成PDF、批量数据导出这种操作，同步调用大概率超时，用请求/响应异步等结果，不占用调用方资源。
• 服务需要弹性扩缩容：如果目标服务会根据流量动态加机器减机器，同步API的负载均衡还得额外配置，而MassTransit的队列天然支持多消费者抢消息，扩缩容完全不用改调用方代码。
• 跨技术栈调用：调用方和服务方用不同语言/框架？同步API得折腾各种兼容性问题，基于消息的请求/响应只需要约定好JSON这类通用格式，就能轻松互通。

什么时候没必要用？ #

如果你的请求是毫秒级就能返回的简单查询，比如查用户昵称、查商品库存，那确实同步API更直接，没必要绕队列，反而增加复杂度。

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