使用 Azure 服务总线在 2 个组织之间进行通信

Question

我们希望将 2 个独立组织之间的系统解耦（例如：一个可以是一组内部应用程序，另一个可以是一组 3rd 方应用程序）。虽然我们可以使用基于 REST 的 API 来做到这一点，但我们希望实现时间解耦、可伸缩性、可靠和持久的通信、工作负载解耦（通过扇出）等。正是出于这些原因，我们希望使用消息巴士。

现在可以使用 Amazon 的 SNS 和 SQS 作为消息总线基础设施，我们的组织将有一个 SNS 实例，该实例将发布到第 3 方 SQS 实例。同样，对于第 3 方希望发送给我们的消息，他们会发布到他们的 SNS 实例，然后再发布到我们的 SQS 实例。见：Cross Account Integration with Amazon SNS

我在考虑如何使用 Azure 服务总线 (ASB) 实现这种跨组织集成，因为我们在 Azure 上投入了大量资金。但是，ASB 没有能力从一个实例发布到属于不同组织的另一个实例（或者甚至到同一组织中的另一个实例，至少目前还没有）。鉴于此限制，我们计划为第 3 方供应商提供单独的连接字符串集，允许他们收听和处理我们发布的消息，以及一组单独的连接字符串，允许他们将消息发布到主题然后我们可以订阅和处理。

我的问题是：这是个好主意吗？或者这会被认为是一种反模式吗？我最担心的事实是，虽然使用消息总线的目的是实现解耦，但 ASB 的基础设施部分使我们紧密耦合到我们需要在两个组织之间进行通信的点上，不仅是端点，而是此外，如何设置队列/主题（会话，或无会话，重复检测等）以及消费者与发送者如何发送消息（用作会话 ID、消息 ID 等的内容）紧密耦合。

这是一个有效的担忧吗？ 你做过吗？ 我可能会遇到什么其他问题？

Answer 1

为发送者和接收者（Send 和 Listen）使用具有不同共享访问策略的 Azure 服务总线连接字符串旨在供具有有限权限的发送者和接收者使用。就像你打算使用它一样。

我最担心的事实是，虽然使用消息总线的目的是实现解耦，但 ASB 的基础架构部分使我们紧密耦合到我们需要在两个组织之间进行通信的点上，而不仅仅是端点，还有队列/主题是如何设置的（会话，或无会话，重复检测等），消费者与发送者发送消息的方式紧密耦合（用作会话 ID、消息 ID 等的内容）。

耦合总是存在的。您与您使用的语言相关联。用于持久化数据的数据存储技术。您正在使用的云供应商。这不是我担心的耦合类型，除非您打算每月更改它们。

没有更具体的通信模式。会话将是业务要求，而不是耦合。如果您需要按顺序发送消息，那么您还会做什么？在亚马逊上，您还将“耦合”到 FIFO 队列以实现订单。消息 ID 也绝不是耦合的。它是消息的属性。如果接收者选择忽略它，他们可以。是的，您正在耦合使用BrokeredMessage/Message 信封和序列化，但是您将如何发送和接收消息？这更像是一份合同，供各方商定。

Answer 2

组织之间连接服务总线的模式的一个名称是“铲子”（这就是它们在RabbitMq 中的名称）

有时需要可靠且持续地移动消息 从一个代理中的源（例如队列）到另一个代理中的目的地 经纪人（例如交易所）。 Shovel 插件允许您配置一个 铲子的数量，它们就是这样做的，并在 代理启动。

在 Azure 的情况下，实现“铲子”的一种方法是使用逻辑应用，因为它们提供了连接到不同命名空间中的 ASB 实体的能力。

见：

1. What are Logic Apps

2. Service Bus Connectors

3. 视频：Use Azure Enterprise Integration Services to run cloud apps at scale