Архитектура разделов служебной шины Azure - PullRequest
Новая
       26

Архитектура разделов служебной шины Azure

0 голосов
/ 10 мая 2018

Я работал над проектом eShopOnContainers , предоставленным Microsoft, в целом оттачивая свои навыки работы с микросервисами.Одной из важных концепций является внедрение Event Bus.Я решил попробовать его с помощью Azure Service Bus, но мой опыт работы с платформой ограничен.

Мне удалось запустить проект после ручного создания Тем, Подписок и т. Д., Но это вызывает некоторыевопросы:

Разве приложение-подписчик не несет ответственности за создание собственной подписки в Azure?например, при запуске?

Концептуально темы представляют разные стеки событий, верно?Например, клиенты, заказ и т. Д.?Или они предназначены для границ событий домена?Например, в этом приложении «eShop» будет темой.

Развертывания Azure - это совсем другая тема, но в связи с настройкой служебной шины, есть ли какие-либо рекомендуемые методы для управления ими в системе контроля версий?

Любое понимание очень ценится.

Ответы [ 2 ]

0 голосов
/ 11 мая 2018

Основываясь на отзывах, я смог собрать общее решение на основе 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();
    }
0 голосов
/ 10 мая 2018

Разве приложение-подписчик не несет ответственности за создание собственной подписки в Azure?например, при запуске?

Это правильно.Детали зависят от используемой вами службы обмена сообщениями.В случае Azure Service Bus каждая служба при запуске будет подписываться на интересующие ее события. Например, Ordering будет подписываться во время запуска на события, которые она обрабатывает .Проект имеет IEventBusSubscriptionsManager контракт , который должен быть реализован специально для каждой службы обмена сообщениями.Для реализации Azure Service Bus каждая служба имеет физическую подписку, и каждое интересующее ее событие представлено правилом, фильтрующим сообщения по значению сообщения служебной шины Label (Label содержит имя события).

Концептуально темы представляют разные стеки событий, верно?Например, клиенты, заказ и т. Д.?Или они предназначены для границ событий домена?Например, в этом приложении «eShop» будет темой

Темы - это точки раздувания сообщений.Вы можете использовать тему для каждой услуги, но это будет означать, что подписчики должны будут знать, какая служба публикует эти события.В качестве альтернативы и, возможно, лучшим вариантом будет тема , известная всем вашим службам, и публикация событий по этой теме.Назовите это "Events" сейчас.Каждый сервис, заинтересованный в различных событиях, создает подписку.Подписка сможет получать любое сообщение (событие), опубликованное в теме Events, но на самом деле должно только "ловить" и доставлять события, в которых оно нуждается (читай "подписано на").Вот где начинается фильтрация. Создавая фильтры (RuleDescription s), данная подписка для каждой службы сообщает брокеру, какие сообщения она будет получать.

Развертывания Azure - это совсем другая тема, ноВ связи с конфигурацией служебной шины, есть ли рекомендуемые методы для управления этим в системе контроля версий?

Несколько вариантов.

  1. Создание сущностей на основе кода во время выполнения (темы, подписки с правилами, очереди).
  2. Захват топологии с помощью шаблонов ARM и версий, аналогично коду в системе контроля версий,
  3. Использование Azure CLI и управление версиями ваших сценариев.
...