问题描述
我们正在 dotnet core mvc 平台上制作云原生企业业务应用程序。前端应用和后端微服务之间的dotnet核心默认api网关是Async模式下使用的Ocelot。
我们被建议使用 RabbitMQ 消息代理而不是 Ocelot。这种转变的原因是前端和微服务之间的异步请求 - 响应交换。在这里，我们想声明我们的应用程序将有几百个 cshtml 页面跨越多个前端模块。我们预计将有超过 1000 名用户同时使用该应用程序。
我们关心的是，这是否是正确的建议。我们的开发团队认为我们应该继续使用 Ocelot api 网关进行前端和微服务之间的一般请求 - 响应交换，并且仅将 RabbitMQ 用于将触发后台处理并在作业完成后延迟响应的事件。
如果你们认为是的，我们可以替换 Ocelot，那么我们进一步关注基于会话的可靠请求和响应。我们不应该以编程方式关联对会话请求的响应。在这里请注意，使用 RabbitMQ，我们正在使用 dotnet 核心 Masstransit 库进行测试。 Ocelot API 网关旨在处理基于会话的请求-响应通信。
在 RabbitMQ 中，我们应该为每个请求创建回复队列，还是客户端应该为所有请求维护一个回复队列。回复队列应该是独占的还是持久的。
每个客户端的单个回复队列是否能够为所有请求提供服务，或者基于应用程序模块/cshtml 页面创建多个接收端点以高效地为所有并发用户提供服务是否正确。
谢谢大家，我们热切等待您的回复。
解决方法
暂无找到可以解决该程序问题的有效方法，小编努力寻找整理中！
如果你已经找到好的解决方法，欢迎将解决方案带上本链接一起发送给小编。
小编邮箱:dio#foxmail.com (将#修改为@）