1

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

现在可以使用 Amazon 的 SNS 和 SQS 作为消息总线基础设施，我们的组织将有一个 SNS 实例，该实例将发布到第 3 方 SQS 实例。同样，对于第 3 方希望发送给我们的消息，他们会发布到他们的 SNS 实例，然后再发布到我们的 SQS 实例。请参阅：与 Amazon SNS 的跨账户集成

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

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

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

4

2 回答 2

2

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

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

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

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

于 2018-03-31T16:49:01.233 回答
1

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

有时需要可靠且连续地将消息从一个代理中的源（例如队列）移动到另一个代理中的目的地（例如交换）。Shovel 插件允许您配置许多 shovel，它们会在代理启动时自动启动。

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

看：

  1. 什么是逻辑应用

  2. 服务总线连接器

  3. 视频：使用 Azure 企业集成服务大规模运行云应用

于 2018-04-14T13:43:57.150 回答