我们希望在两个独立的组织之间解耦系统（例如：一个可以是一组内部应用程序，另一个可以是一组第三方应用程序）。虽然我们可以使用基于REST的API来实现这一点，但我们希望实现时间解耦，可伸缩性，可靠和持久的通信，工作负载解耦（通过扇出）等等。并且出于这些原因，我们希望使用消息总线。
现在可以使用亚马逊的SNS和SQS作为消息总线基础设施，我们的组织将拥有一个SNS实例，该实例将发布到第三方SQS实例。同样，对于第三方希望发送给我们的消息，他们会发布到他们的SNS实例，然后发布到我们的SQS实例。请参阅：Cross Account Integration with Amazon SNS
我在考虑如何使用Azure Service Bus（ASB）实现这种跨组织集成，因为我们在Azure中投入了大量资金。但是，ASB无法从一个实例发布到属于另一个组织的另一个实例（甚至是同一组织中的另一个实例，至少还没有）。鉴于此限制，计划是我们将为第三方供应商提供单独的连接字符串集，以允许它们监听和处理我们发布的消息，以及一组单独的连接字符串，这些字符串可以让消息发布到主题然后我们可以订阅并处理。
我的问题是：这是个好主意吗？或者这会被视为反模式？我最关心的事实是，虽然使用消息总线的目的是实现解耦，但ASB的基础设施部分正在使我们紧密耦合到我们需要在两个组织之间进行通信的点，而不仅仅是端点，此外，如何设置队列/主题（会话，或没有会话，重复检测等），并且消费者与发送者如何发送消息（用作会话ID，消息ID等）紧密耦合。
这是一个有效的问题吗？ 你做过这个吗？ 我可能会遇到哪些其他问题？
答案 0 :(得分：2)
对发件人和收件人（Send和Listen）使用具有不同共享访问策略的Azure Service Bus连接字符串旨在由具有限制权限的发件人和收件人使用。就像你打算使用它一样。
我最关心的事实是，虽然使用消息总线的目的是实现解耦，但ASB的基础设施部分正在使我们紧密耦合到我们需要在两个组织之间进行通信而不仅仅是端点，以及如何设置队列/主题（会话，或没有会话，重复检测等），并且消费者与发送者如何发送消息（用作会话ID，消息ID等）紧密耦合。
耦合始终存在。你加入了你正在使用的语言。用于保存数据的数据存储技术。您正在使用的云供应商。这不是我担心的耦合类型，除非你打算每月更换一次。
不是特定于通信模式。会议将是一个商业需求，而不是耦合。如果您需要订购信息，那么您还会做什么？在亚马逊上，您也将“耦合”到FIFO队列以实现订单。消息ID绝不是耦合。它是消息的属性。如果接收者选择忽略它，他们可以。是的，您正在使用BrokeredMessage/Message信封和序列化，但您还会如何发送和接收消息？这是一个非常强烈的合同，可以达成共识。
答案 1 :(得分：0)
组织之间连接服务总线的模式的一个名称是＆＃34; Shovel＆＃34; （这是他们在RabbitMq中所称的内容）
有时需要可靠且持续地移动消息 从一个代理中的源（例如队列）到另一个代理中的目的地 经纪人（例如交易所）。 Shovel插件允许您配置 铲子的数量，这样做，并自动启动时 经纪人开始。
在Azure的情况下，一种实现＆＃34;铲子的方法＆＃34;是通过使用逻辑应用程序，因为它们提供连接到不同命名空间中的ASB实体的能力。
请参阅：