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

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

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

Альтернативное решение - использовать меньше тем (отправлять несколько событий в одну тему), а затем настроить фильтры, чтобы определить, должно ли каждое сообщение отправляться в подписку. С точки зрения обслуживания это кажется излишне более сложным и гораздо менее удобным. Зачем мне нужны фильтры, если я могу создавать тысячи тем?

Может ли кто-нибудь дать отзыв о лучшем подходе?


azureservicebus azure-servicebus-topics azure-servicebus-subscriptions
person Extranomical    schedule 13.09.2019    source источник

Ответы (1)


arrow_upward
3
arrow_downward

Топология - интересная тема (без слов).

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

  1. Команды
  2. События

Команды имеют одно предназначение и ожидание работы. Они несут достаточно информации для выполнения работы, и часто отправитель ожидает получить ответ.

События предназначены для уведомления N подписчиков о произошедших фактах, не неся слишком много информации и не ожидая каких-либо ожиданий от получателей. N может быть одним или несколькими (или даже ни одним) подписчиками. Нет никаких ожиданий относительно того, что подписчики должны делать с событиями, и поэтому издатели и подписчики разделены.

Для команд я предпочитаю очередь. Очередь может использоваться только одним логическим получателем. Нет возможности доставить одну и ту же команду нескольким логическим получателям. Это также помогает с горизонтальным масштабированием приемника в зависимости от нагрузки / работы, с которыми он должен справиться. Это не означает, что это должно быть реализовано таким образом. Вы можете создать тему с одной подпиской и добиться того же. Но это будет означать, что сообщение должно «перемещаться» внутри от темы к подписке, которая также является очередями. Преимущество этого подхода могло заключаться в подключении дополнительных подписчиков, но тогда я бы спросил, не является ли это YAGNI.

Для событий одна или несколько тем с несколькими подписками. Одиночная тема уменьшает количество связей - подписчикам нужно знать только эту тему, а не несколько.

Надеюсь, эта информация поможет.

Может ли кто-нибудь дать отзыв о лучшем подходе?

Подведем итог, как если бы выслушали все рекомендации, но подтвердили их соответствие вашим потребностям. Не существует лучшего способа, есть варианты, которые помогут вам выработать подход, отвечающий потребностям вашей системы.

Отказ от ответственности: то, что я описал, во многом согласуется с топологиями реализовано NServiceBus с несколькими добавленными мною вариациями.

person Sean Feldman    schedule 13.09.2019