【发布时间】：2020-10-08 10:37:21
【问题描述】：
我们正计划重写更大应用程序的后端。
其中一部分是使用某种消息总线或消息队列系统。
我们正在寻找可以使用以下代码的框架。
var topic = "products";
var mq = MessageQueueFactory.CreateMessageQueue(topic);
ProductInformation result = await mq.Publish(new ProductInformationSearchRequest(1337));
// work with the result
类似的东西。 我知道在发出请求的同一函数中等待系统响应的想法有点违背。
有一些框架可以响应会话。但是你会有一个单独的响应队列。
我们的目标是将一些信息发送到队列中。框架找到将消息发送到的目的地，在目的地响应后，我得到了我的结果。可能存在多个目的地（同类）。并非所有请求都需要得到答复。只有那些被标记为这样做的人。消息代理或类似的也可以。
是否存在某些东西，或者我必须围绕某些东西构建一个包装器？使用这种架构，我们可以消除一些微服务现在所具有的依赖关系。 或者我们甚至必须改变我们的架构才能让这样的系统正常工作？这有意义吗？
顺便说一句：旧的方式是/是使用 REST 和 API 网关在服务之间进行通信。
【问题讨论】：
-
等待结果对我来说听起来不对。因为消息系统的想法是将事物解耦并进行异步工作。因此，当您发送消息并等待结果时，您将再次将事物同步在一起。所以等待我认为你必须发出一条消息。有人收听此消息并做一些工作。当他完成后，他可以发送一条新消息，让其他人收听并做一些工作等等。我们在不同的应用程序/服务之间使用 AzureServiceBus。但我不是消息队列/架构专家。
-
我都不是。但要完全按照你的描述做是我的后备计划。
-
我首先要问的是，您为什么要考虑放弃 REST 和 API 网关？你上面的模型看起来很像 [gRPC][1] - 你考虑过吗？ [1]：grpc.io
标签： .net microservices message-queue messaging