RabbitMQ 架构肠道检查答案

【问题标题】：RabbitMQ Architecture Gut CheckRabbitMQ 架构肠道检查
【发布时间】：2020-01-30 15:45:19
【问题描述】：

所以我正在考虑使用RabbitMQ 在我们组织中的所有不同应用程序之间发送消息。附图中基本上是我脑海中关于事情如何运作的画面。

所以消息进入交换器，并分成三个队列。

有效负载始终是 JSON 文本。

消费者是长期运行的 Windows 服务，其唯一的工作就是坐下来监听发往其特定应用程序的消息。当消息进入时，他们会查看标头以确定应如何解释此有效负载 JSON，以及哪个它应该被发送到的 REST 端点。例如，“当我看到 'WORK_ORDER_COMPLETE' 标头时，我将把它解析为 WorkOrderCompleteDto 并将其作为 POST 发送到位于 timelabor-api.mycompany.com 的 CompletedWorkOrder WebAPI 方法。如果 API 返回的不是 200，我拒绝消息并让rabbit处理它。如果我从API得到200返回，那么我将消息确认给rabbit。”

那么最终应用程序就是我们用于库存、计费等的内部业务线应用程序。然后这些应用程序负责执行各自的功能（减少库存、创建计费记录、yadda yadda。

这对正确使用 Rabbit 的方法有任何意义吗？

【问题讨论】：

是的。这通常是 RabbitMQ 的典型用法。注意如何配置交换，以便消息最终进入正确的队列。扇出会将垃圾邮件发送到所有队列。

标签： rabbitmq message-queue

【解决方案1】：

从概念上讲，我相信您可能依赖 RabbitMQ 来完成您的应用程序需要做的事情。

架构的假设似乎是每个消息都由您的每个消费应用程序完全在真空中处理。这意味着您不在乎Billing_App 成功处理的消息最终以Inventory_App 失败。也许这是真的，但根据我的经验，它不是。

如果最终目标是在整体数据中实现某种一致的状态，那么您将需要一些监督组件来编排和监控各种操作以确保状态一致。这实际上意味着，您关于拒绝将消息返回给 RabbitMQ 的声明意味着您有更多的想法来考虑发生故障时会发生什么。

我将专注于确定一些描述您的行为以及它如何实现最终状态的 UML 活动图，并将其用作确定您的应用程序编排需要如何设计的指南。

【讨论】：

好的，因此维护应用程序可能会创建一个新的唯一键（例如 GUID），它是有效负载（或标头）的一部分。随着每个消费者的任务成功或失败，他们可以依次向“事务”消息交换发送消息，该消息交换最终将记录（比方说在数据库中）每个组件的成功或失败交易。反过来，这些数据可能会被提醒或报告
这可能行得通。我确实喜欢您正在处理事件的事实-> 我经常看到的一个巨大错误是处理响应命令，然后使系统处于不一致和难以理解的状态。至少处理事件，你总有办法从失败中恢复。