Тема служебной шины Azure и дизайн подписки для потребителей типа микросервисов

Я изучаю использование служебной шины Azure для публикации / доставки сообщений между различными службами в нашем приложении и пытаюсь найти достойный дизайн для темы и подписок в пространстве имен служебной шины.

Система предназначена для того, чтобы service-a опубликовала сообщение с типом service-a.test-event на шине, и чтобы любая служба, прослушивающая этот тип события, доставила сообщение. Это будет довольно низкая громкость

Я немного не понимаю, какой из следующих дизайнов использовать:

  1. В пространстве имен служебной шины есть одна тема events, куда доставляются все сообщения от всех служб. Любая служба, подписывающаяся на события от любой другой службы, создает подписку в этом разделе, используя фильтры для получения нужных им типов сообщений - по одной подписке на тип сообщения (например, service-b-service-a-test-event).
  2. Пространство имен служебной шины имеет одну тему для каждого издателя (например, events-service-a). Любая служба подписки на события из этой службы создает подписку в теме, используя фильтры для получения нужных им типов сообщений - по одной подписке на тип сообщения (например, service-b-test-event).

Похоже, что служебная шина имеет ограничение в 2000 подписок на тему, чего, насколько я могу судить, для нас будет достаточно. Если бы у меня были подозрения в противном случае, вариант № 2, вероятно, был бы лучшим выбором (поскольку у меня может быть 10 000 тем на пространство имен). Насколько я могу судить, ни одно из других ограничений служебной шины не влияет на то, какой из этих вариантов мне следует выбрать.

Еще одно дополнительное требование: я хочу, чтобы служба подписывалась на любое событие из любой службы по причинам записи. Если бы я выбрал вариант №1, это было бы очень просто реализовать. Однако для варианта № 2 эта служба должна каким-то образом убедиться, что у нее есть подписка в любой теме события в пространстве имен - и перенастроить себя после добавления новых тем и удаления старых. Это выходит за рамки этого вопроса, но тем не менее является требованием к дизайну.


azure azureservicebus
person Trond Nordheim    schedule 19.11.2016    source источник
comment
вариант 2 хорош. при условии, что вы можете написать свой фильтрующий запрос прямо в каждой подписке, чтобы однозначно получить сообщение, которое вы хороши. для дополнительного компонента иметь одну подписку без фильтра, чтобы он получал все сообщения.   -  person Aravind    schedule 19.11.2016

Ответы (1)


arrow_upward
3
arrow_downward

При выборе топологии учитывайте то, что для вас наиболее важно. Один из принципов публикации / подписки - разделение между издателями и подписчиками. В топологии № 2 (тема для каждого издателя) этот принцип нарушается, поскольку каждый подписчик должен знать имя издателя. И если издатель мероприятия изменится, все ваши подписчики должны будут получить эти знания, чтобы повторно подписаться. Топология №1 решает эту проблему, абстрагируясь от издателей за счет использования одной темы.

Кроме того, второе требование, которое у вас было (аудит всех событий), было бы намного проще реализовать с этой топологией, так как вам нужно поддерживать только одну подписку на прослушивание телефонных разговоров по этой теме.

Вы правы насчет ограничения 2000 подписок на тему. При этом 2000 подписок - это довольно много. Как только ваша система наберет такое количество подписчиков, вы, вероятно, все равно захотите пересмотреть свою архитектуру / топологию.

Эти две топологии очень похожи на NServiceBus в служебной шине Azure в качестве транспортного топологии. Вы можете ознакомиться с некоторыми другими идеями, которые вы могли бы использовать для своей топологии, включая преимущества одного над другим.

Отказ от ответственности: я работаю над транспортом служебной шины Azure NServiceBus. Вам не обязательно использовать NServiceBus, хотя многие вопросы, подобные тому, который вы публикуете здесь, перестают быть проблемой, когда вы это делаете.

person Sean Feldman    schedule 20.11.2016
comment
Это не обязательно происходит в .NET, иначе я искал NServiceBus :) Что касается подписчиков, знающих об издателе, на самом деле это не так тесно связано. Лучше думать об этом в пространствах имен сообщений, поэтому, если у меня есть служба, обрабатывающая пользователей, она публикует такие события, как users.registered. С вариантом № 2 это будет в теме, называемой пользователями, и подписчик может подписаться на зарегистрированные события в этой теме. Хотя одна тема кажется более удобной в обслуживании, в ее нынешнем виде это более вероятное решение. Спасибо за вклад! - person Trond Nordheim; 22.11.2016