c# - Azure 服务总线主题架构

Question

我一直在努力解决eShopOnContainers Microsoft 提供的项目，磨练了我的微服务技能。其中一个重要概念是事件总线的引入。我选择使用 Azure 服务总线进行尝试，但我对该平台的经验有限。

在手动创建主题、订阅等后，我成功地让项目运行，但这引发了一些问题:

订阅应用程序没有责任在 Azure 中创建自己的订阅吗？例如启动时？

从概念上讲，主题代表不同的事件堆栈，对吗？例如。客户、订单等？或者它们旨在成为领域事件边界？例如。在此应用程序中，“eShop”将是主题。

Azure 部署是一个完全不同的主题，但与服务总线配置相关，是否有任何推荐的技术可以在源代码控制中管理它？

非常感谢任何见解。

Answer 1

Is it not the responsibility of the subscribing application to create it's own Subscription in Azure? e.g. on startup?

这是正确的。详细信息取决于您正在使用的基础消息传递服务。对于 Azure 服务总线，每个服务在启动时都会订阅它感兴趣的事件。例如，Ordering 将 subscribe during startup to the events it handles 。该项目有 IEventBusSubscriptionsManager contract专门针对每个消息服务实现。对于 Azure Service Bus implementation每个服务都有一个物理订阅，它感兴趣的每个事件都由一条规则表示，通过服务总线消息Label 的值过滤消息(Label 包含事件名称)。

Conceptually, Topics represent different event stacks, correct? E.g. Customers, Ordering, etc? Or are they intended to be domain event boundaries? E.g. in this application, 'eShop' would be the topic

主题是消息散开的点。您可以为每个服务使用一个主题，但这意味着订阅者需要知道哪个服务正在发布这些事件。或者，可能更好的选择是拥有所有服务都知道的主题，并将事件发布到该主题。现在将其称为“Events”。每个对各种事件感兴趣的服务都会创建一个订阅。订阅将能够获取发布到 Events 主题的任何消息(事件)，但实际上应该只“捕获”并传递它需要的事件(阅读“订阅”) 。这就是过滤的作用。通过创建过滤器(RuleDescription)，每个服务的给定订阅在代理上声明它将接收哪些消息。

Azure deployments is a whole other topic, but related to the Service Bus configuration, are there any recommended techniques for managing that within source control?

几个选项。

1. 在运行时基于代码创建实体(主题、规则订阅、队列)。
2. 使用 ARM 模板和版本捕获拓扑，就像版本控制系统中的代码一样。
3. 使用Azure CLI并对您的脚本进行版本控制。