我们正在dotnet core mvc平台上制作一个云原生企业业务应用程序。dotnet core默认的前端应用程序和后端微服务之间的api网关是异步模式下使用的Ocelot。
有人建议我们使用RabbitMQ消息代理而不是Ocelot。这种转变的原因是前端和微服务之间的异步请求-响应交换。在这里，我们要声明我们的应用程序将有几百个cshtml页面跨越几个前端模块。我们预计会有上千个用户同时使用该应用程序。
我们关心的是，这是不是一个正确的建议。我们的开发团队认为，我们应该继续使用Ocelot api网关进行前端和微服务之间的一般请求-响应交换，而只对将要触发后台组处理的事件使用RabbitMQ，并在任务完成时在延迟后进行响应。
如果你们认为我们可以替换Ocelot，那么我们将进一步关注基于会话的请求和响应的可靠性。我们不需要通过编程将响应与会话请求相关联。这里请注意，我们正在使用RabbitMQ和dotnet核心MassTransit库进行测试。Ocelot API网关旨在处理基于会话的请求-响应通信。
在RabbitMQ中，我们应该为每个请求建立一个回复队列，还是客户端应该为所有请求维护一个回复队列？回复队列应该是独占的还是持久的？
每个客户端的单个回复队列是否能够为所有请求提供服务，或者是否可以基于应用程序模块/cshtml页面创建多个接收端点，以便以高效的方式为所有并发用户提供服务。
谢谢大家，我们热切地等待你们的答复。