订阅应用程序是否有责任在Azure中创建自己的订阅？例如，在启动时？
正确。详细信息取决于你正在使用的底层消息传递服务。对于Azure Service Bus，每个服务在启动时都会订阅它感兴趣的事件。例如，Ordering将在启动期间订阅它处理的事件。该项目有一个IEventBusSubscriptionsManager contract专门为每个消息服务实现。对于Azure Service Bus implementation，每个服务都有一个物理订阅，并且它感兴趣的每个事件都由一个规则表示，通过服务总线消息Label（Label包含事件名称）的值过滤消息。
从概念上讲，主题表示不同的事件堆栈，对吗？例如，客户、订购等？或者它们是域事件边界？例如，在此应用程序中，“eShop”将是主题
主题是分散消息的要点。您可以为每个服务使用一个主题，但这意味着订阅者需要知道哪些服务正在发布这些事件。或者，可能更好的选择是拥有所有服务都知道的 * 主题 *，并将事件发布到该主题。现在称之为“Events”。对各种事件感兴趣的每个服务都将创建一个订阅。订阅将能够获得 * 任何 *消息（事件）发布到Events主题，但实际上应该只“捕获”并交付它需要的事件（阅读“订阅”）。这就是过滤的用武之地。通过创建过滤器（RuleDescription s），每个服务的给定订阅在代理上声明它将接收什么消息。
Azure部署是另一个主题，但与服务总线配置相关，是否有任何推荐的技术在源代码控制中管理？
有几个选择。
1.在运行时基于代码创建实体（主题、具有规则的订阅、队列）。
1.使用ARM模板和版本捕获拓扑，就像版本控制系统中的代码一样。
1.使用Azure CLI并对脚本进行版本控制。

根据反馈，我能够基于eShop Event Bus构建一个粗略的解决方案，以便在启动时创建Azure订阅：

public EventBusServiceBus(IServiceBusPersisterConnection serviceBusPersisterConnection,
        ILogger<EventBusServiceBus> logger, IEventBusSubscriptionsManager subsManager, string subscriptionClientName,
        ILifetimeScope autofac, AzureUserCredentials userCredentials, string subscriptionId, string resourceGroupName, string serviceBusName, string topicName)
    {
        _serviceBusPersisterConnection = serviceBusPersisterConnection;
        _logger = logger;
        _subsManager = subsManager ?? new InMemoryEventBusSubscriptionsManager();

        _subscriptionClient = new Microsoft.Azure.ServiceBus.SubscriptionClient(serviceBusPersisterConnection.ServiceBusConnectionStringBuilder,
            subscriptionClientName);
        _autofac = autofac;

        var credentials = SdkContext.AzureCredentialsFactory.FromServicePrincipal(
          userCredentials.ClientId, userCredentials.ClientSecret, userCredentials.TenantId, AzureEnvironment.FromName(userCredentials.EnvironmentName));

        var azure = Azure
                .Configure()
                .WithLogLevel(HttpLoggingDelegatingHandler.Level.Basic)
                .Authenticate(credentials)
                .WithSubscription(subscriptionId);

        var nm = azure.ServiceBusNamespaces.GetByResourceGroup(resourceGroupName, serviceBusName);

        var topic = nm.Topics.GetByName(topicName);

        if (topic == null)
            throw new ArgumentException($"Topic {topic} does not exist.", nameof(topic));

        Microsoft.Azure.Management.ServiceBus.Fluent.ISubscription subscription = null;
        try
        { subscription = topic.Subscriptions.GetByName(subscriptionClientName); }
        catch { }

        if (subscription == null)
        {
            logger.LogInformation($"Creating Azure Subscription '{subscriptionClientName}'");
            topic.Subscriptions.Define(subscriptionClientName).WithDeleteOnIdleDurationInMinutes(5).Create();
        }
        else
        {
            logger.LogInformation($"Azure Subscription '{subscriptionClientName}' already exists. Reusing.");
        }

        RemoveDefaultRule();
        RegisterSubscriptionClientMessageHandler();
    }

正如@Sean Feldman也提到的那样，将单个主题作为发布消息的中心渠道，如果你也在关注单个主题与多个主题的性能，请参阅azure docs提供的性能指南。我引用了最有趣的部分，可以帮助你。
从可伸缩性的Angular 来看，您不会注意到有太大的差异，因为Service Bus已经在内部将负载分散到多个日志中，因此，如果您使用六个队列或主题，或者两个队列或主题，则不会产生实质性的差异。
https://learn.microsoft.com/en-us/azure/service-bus-messaging/service-bus-performance-improvements?tabs=net-standard-sdk-2#multiple-queues-or-topics