Azure服务总线主题体系结构

7ivaypg9  于 2023-03-31  发布在  其他
关注(0)|答案(3)|浏览(175)

我一直在研究微软提供的eShopOnContainers项目,总体上磨练了我的微服务技能。其中一个重要概念是引入了事件总线。我选择尝试使用Azure服务总线,但我对该平台的经验有限。
在手动创建主题、订阅等之后,我设法让项目运行起来,但这引发了一些问题:
订阅应用程序是否有责任在Azure中创建自己的订阅?例如,在启动时?
从概念上讲,主题代表不同的事件堆栈,对吗?例如,客户、订购等?或者,它们旨在作为域事件边界?例如,在此应用程序中,“eShop”将是主题。
Azure部署是另一个主题,但与服务总线配置相关,是否有任何推荐的技术在源代码控制中管理?
任何洞察力都非常赞赏。

ha5z0ras

ha5z0ras1#

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

a64a0gku

a64a0gku2#

根据反馈,我能够基于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();
    }
lqfhib0f

lqfhib0f3#

正如@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

相关问题