我们正在 dotnet core mvc 平台上制作云原生企业业务应用程序。前端应用程序和后端微服务之间的 dotnet core 默认 api 网关是异步模式下使用的 Ocelot。
建议我们使用 RabbitMQ 消息代理而不是 Ocelot。这种转变的原因是前端和微服务之间的异步请求-响应交换。在这里，我们想声明我们的应用程序将有数百个 cshtml 页面跨越多个前端模块。我们预计有超过千名用户同时使用该应用程序。
我们关心的是，这个建议是否正确。我们的开发团队认为，我们应该继续使用 Ocelot api 网关进行前端和微服务之间的一般请求-响应交换，并仅将 RabbitMQ 用于将触发后台组处理并在作业完成后延迟后响应的事件。
如果你们觉得我们可以取代 Ocelot，那么我们进一步担心基于可靠会话的请求和响应。我们不必以编程方式关联对会话请求的响应。在这里请注意，我们正在使用 RabbitMQ 使用 dotnet 核心 MassTransit 库进行测试。 Ocelot API 网关旨在处理基于会话的请求-响应通信。
在 RabbitMQ 中，我们应该为每个请求创建回复队列，还是客户端应该为所有请求维护一个回复队列。回复队列应该是独占的还是持久的。
每个客户端的单个回复队列是否能够服务于所有请求，或者基于应用程序模块/cshtml 页面创建多个接收端点以有效地服务所有并发用户是否正确。
谢谢大家，我们热切等待您的回复。
我建议实施 RabbitMQ。您可能需要将 ocelot 更改为rabbit mq。
两者都是微服务架构中的重要工具，它们有不同的用途。 Ocelot 用于处理传入的 HTTP 请求并将其路由到适当的服务，而 RabbitMQ 用于以异步方式处理服务之间的内部通信。
Ocelot 是一个基于 .NET 的 API 网关。它用于在微服务架构中处理和路由 HTTP 请求
另一方面，RabbitMQ是一个消息代理。它用于使用消息队列处理分布式系统架构中服务之间的异步通信