我刚刚开始使用 MassTransit 在微服务中实现事件消息。消息发布对我来说很有意义，有利于微服务的响应能力。然而，请求和响应似乎与响应必须返回以完成整个过程逻辑的 API 同步调用相当。我只是不明白为什么以及何时应该实现这种模式？ API 调用不是比将请求放入队列并等待处理完毕然后获取响应要简单得多吗？
这里有大量问题！
API 调用不是比将请求放入队列并等待处理完毕然后获取响应简单得多吗
简单来说，不。如果客户正在完成订单，并且出现网络超时、数据库锁定或其他常见事件，该怎么办？订单丢失了。
如何设置 DNS、负载均衡器、API 的多个实例、Swagger 文档、验证、良好错误响应以及监控。 Datadog、APM 和日志记录。几个月后见:)
创建消费者，启动它，确保在几个小时而不是几个月内 100% 交付和处理。
内置负载平衡、服务发现、重试和错误日志记录。更不用说 APM 跟踪的惊人可操作性了。
请求和响应确实与 API 相当
这不是……更好，而是一种完全不同的看待问题的方式。你必须从事件的角度来思考。发生了什么，数据发生了什么变化以及我需要关心什么。
研究事件驱动架构和编排、编排和 Sagas。
这无法在 Stack Overflow 帖子中解释……你必须稍微改变一下你的心态。
但简单来说，传统的 API 完成了一个过程，比如说购买 PS5。当 API 调用完成时，订单就完成了。这可能需要 5 - 30 秒。在此期间，服务器被锁定，进程被锁定，客户正在等待，并且出现问题的变化很高。
如果您引发事件，该过程会立即完成。客户返回保留页面，服务器可以自由处理其他订单。
当消费者处理订单时，会引发一个事件，客户可以看到订单已成功。
也可以从事件返回数据。然而，我发现，保持数据最少是最好的。允许 API 引发事件、消费者处理事件以及 Sockets/SignalR/Blazor 等与客户/ui 进行通信。
我有一个关于 Saga 的视频，您可能会觉得有用。我认为这将帮助您了解数据如何在事件之间移动。
对我来说明显区别的是，当发送者尝试访问其他微服务时，请求/响应以某种方式忽略了身份验证/授权的需要