面向微服务类型用户的Azure服务总线主题与订阅设计
该系统的目的是让service-a将类型为service-a.test-event的消息发布到总线，并让侦听该事件类型的任何服务获得消息的传递。这将是一个相当低的音量
对于使用以下哪一种设计，我有点撕心裂肺：
- 服务总线命名空间有一个主题
events，来自所有服务的所有消息都是在这个主题中传递的。订阅来自任何其他服务的事件的任何服务在本主题中使用筛选器创建一个订阅，以获取所需的消息类型-每个消息类型一个订阅（例如service-b-service-a-test-event)。 - 服务总线命名空间每个发布服务器有一个主题（例如
events-service-a)。任何订阅此服务中事件的服务都使用筛选器在主题中创建一个订阅，以获取所需的消息类型--每个消息类型一个订阅（例如service-b-test-event)。
服务巴士似乎有一个2000订阅的限制每个主题，据我所知，这将是足够的我们。如果我对此有所怀疑，那么选项2可能是最好的选择（因为每个名称空间可以有10,000个主题）。据我所知，服务巴士的其他限制并没有真正影响我应该选择哪一个方案。
一个附加的要求是，我希望有一个服务订阅来自任何服务的任何事件，因为记录的原因。如果我选择第一个选项，实现起来会非常简单。但是对于选项2,该服务需要确保在名称空间中的任何事件主题中都有订阅--并且在添加新主题和删除旧主题时重新配置自己。这不在这个问题的范围之内，但它仍然是设计的一个要求。
共有1个答案
当决定一个拓扑时，要考虑对你最重要的事情。pub/sub的原则之一是在发布者和订阅者之间进行解耦。对于拓扑#2（每个发布者的主题），这一原则是违反的，因为每个订阅者都必须知道发布者的名称。如果事件的发布者发生了变化，那么所有的订阅者都必须获得这些信息才能重新订阅。Topology#1通过使用单个主题将发布者抽象化来解决这个问题。
此外，您的第二个要求（审计所有事件）将更容易用这个拓扑实现，因为您只需要维护一个关于该主题的窃听订阅。
您对每个主题2000个订阅的限制是正确的。也就是说，2000个订阅量是相当多的。一旦您的系统达到了该数量的订户，您可能还是希望查看您的体系结构/拓扑结构。
-
我想将一个小的JSON消息放入中。消息将具有附加到它的“ProviderID”属性，并且根据筛选规则，该消息将被筛选到特定于提供程序的上 但是，我似乎无法在上指定共享访问策略，以限制第三方提供商仅连接到他们自己的 我假设应该在订阅上设置以便将这些消息发送到另一个并在那里应用特定于提供程序的安全性，这样做是否正确。 或者有其他/更好的/推荐的方法来做这件事。
-
null 输出 谁能解释一下为什么会这样吗？这对我来说有点迷惑？
-
来自第三次订阅的消息会发生什么情况，是否会在TTL之后发送到死信队列 有没有办法找出消息未被使用的订阅
-
我有一个名为“状态更改”的Azure服务总线主题，它有一个名为“混响”的订阅。我正在尝试使用设置订阅主题的方法，但出现错误： 我一直在使用这篇博客文章来尝试让一切正常运行：http://ramblingstechnical.blogspot.co.uk/p/using-azure-service-bus-with-spring-jms.html 我可以使用向主题添加消息，并使用Azure文档中概述
-
这似乎是最简单的解决办法。让我们看看流程： 第三方向RESTful API发送请求，以获取Windows Azure服务总线连接字符串-凭据-。 一旦拥有连接字符串，第三方就会连接到Windows服务总线，并开始从某个主题订阅接收消息。注意：连接字符串是在服务器端加密的，只能由接受的客户端解密。 优点 null null 第三方请求一个类似于RESTful的TCP API，以便订阅一些Window
-
我们使用服务总线主题作为pub/sub系统的引擎。我们的逻辑涉及我们的NodeJS服务用多个订阅连接到一个主题。对于每个订阅，我们删除$default(TrueFilter)，并在消息头的Label属性上创建一个CorrelationFilter，并且不在订阅中应用AutoDeleteOnIdle设置，因为我们希望确保订阅服务器功能在服务启动之前一直运行。 这个问题可以归结为这样：某件事能导致规则