.NET async/await 与 RabbitMQ 等消息代理相比，在概念上有何不同？
问题在于我们需要在两种方法之间做出选择。此外，我们不应该更改与客户端的现有同步协议（例如 REST API），同时提高应用程序处理多个并行请求的能力并将复杂性保持在最低限度。现在一切都已同步。
.NET 的异步/等待机制和像 RabbitMQ 这样的消息代理在应用程序设计和通信的上下文中服务于不同的目的。
.NET 中的异步/等待：
应用程序内的并发：.NET 中的异步/等待模式主要用于应用程序内的异步编程。它允许您编写可以执行非阻塞操作的代码，从而在等待异步操作完成的同时释放调用线程以执行其他工作。 并行性：它对于 I/O 密集型操作特别有用，其中应用程序可以有效地同时处理多个请求，而无需等待每个请求完成。 相同进程：异步/等待通常用于同一进程内或单体应用程序中组件之间的通信。 消息代理（例如 RabbitMQ）：
进程间或服务间通信：像 RabbitMQ 这样的消息代理是为进程间或服务间通信而设计的。它们支持可能在不同机器甚至不同网络上运行的系统的不同部分之间的通信。 解耦：消息代理为组件之间的通信提供了一种解耦的方式。发送者生成消息，接收者使用它。这使得架构具有更大的灵活性和可扩展性。 可扩展性和可靠性：消息代理通常用于分布式系统中，以提高可扩展性和可靠性。它们可以处理大量消息，确保传递，并提供消息队列和发布/订阅模式等功能。 您做出决定时的考虑因素： 现有同步协议：
如果您现有的客户端同步协议（例如 REST API）是一项关键要求，那么引入消息代理可能不是一个简单的替代方案。消息代理通常涉及异步、解耦的通信模型，这可能会影响您现有的同步 API。 处理多个并行请求：
如果您主要关心的是在应用程序中有效处理多个并行请求，同时保持现有同步协议完好无损，则 async/await 可能是一个更直接且兼容的选择。 复杂性：
如果您的目标是将复杂性降至最低，那么引入消息代理会增加额外的基础设施组件和注意事项。选择可能取决于您的团队愿意处理的复杂程度以及应用程序的具体要求。 综上所述，如果您的主要目标是提高应用程序处理多个并行请求的能力，同时保留现有的同步协议，并且您处理的不是分布式系统或服务之间解耦的需求，那么重点关注增强使用应用程序中的 async/await 可能是更合适的方法。但是，如果您预见到未来需要分布式通信和可扩展性，消息代理可能是一个有价值的补充，尽管它可能需要调整您现有的架构和通信协议。