NServiceBus pub-sub на очередях служебной шины azure

Question

Я ищу для реализации простой демо-версии pub-sub, используя NServiceBus при поддержке Azure Service Bus.

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

Когда абонент выключается, я отписываюсь от событий и останавливаю EndpointInstance.

Однако, если я проверяю свою служебную шину, то очереди подписки на очереди и темы, которые создаются в процессе, не очищаются. Это означает, что через некоторое время у меня потенциально будет сотни очередей и подписей на темы, которые никогда не будут использоваться снова из-за того, как я создаю свои имена EndpointInstance.

Как их очистить?

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

UPDATE:

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

В моем сценарии каждый клиент будет определять свой собственный уникальный экземпляр Endpoint и Endpoint. Как логические конечные точки вступают в игру в этот момент?

Answer 1

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

В сценариях производства вы можете привести свою конечную точку вниз по разным причинам. Один из них - развертывание новой версии или обслуживание в вашем хранилище данных. Другой может быть таким же простым, как сбой вашего сервера/службы и т. Д. И т. Д. Пока он не работает, в производственных сценариях вы хотите, чтобы сообщение все еще приходило в очередь. Таким образом, вы можете надежно обрабатывать их, когда конечная точка снова возвращается обратно.

В связи с этим мы не поддерживаем очереди очистки. Если вы хотите очистить все после того, как опустили конечную точку, вам придется вручную удалить очереди, а что нет.

О создании демонстрации вы указываете уникальные конечные точки и экземпляры. Просто ради ясности позвольте мне попытаться объяснить, что мы имеем в виду с конечными точками и примерами. Вы можете построить логическую конечную точку, которая выполняет некоторые задачи. Это может содержать различные обработчики, саги и т. Д. Оно имеет уникальное имя и уникальную функцию. В системе могут быть разные логические конечные точки.

При развертывании обычно у вас есть один экземпляр для каждой конечной точки. Если вы хотите уменьшить масштаб, вы можете развернуть другой экземпляр одной и той же логической конечной точки.При использовании Azure Service Bus у вас есть что-то под названием competing consumers. Это в основном означает, что оба экземпляра конечных точек пытаются получить сообщения из одной очереди. Всегда побеждает и начинает обрабатывать сообщение.

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

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

---

Теперь, что меня озадачивает ваше следующее утверждение:

Я работаю с неопределенным количеством абонентов более того порождал или существующие погибают в зависимости от различных условий

Похоже, вы создаете новые логические конечные точки «на лету» и развертываете их. Это - это, чтобы дать им уникальные имена на основе конфигурации, установленной при развертывании. Но я до сих пор не понимаю, почему вы хотели бы продемонстрировать это.

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

Answer 2

Сценарий, который вы описали, имеет смысл. Вам интересны временные конечные точки, которые создаются, служат их назначению, а затем удаляются из системы. Эти конечные точки уникальны и не имеют множественных экземпляров. И даже если они это делают, все экземпляры разукрашены.

Это означает, что через некоторое время у меня потенциально будут сотни очередей и подписки на темы, которые никогда не будут использоваться снова из-за того, как я генерирую имена EndpointInstance.

Проблема, с которой вы сталкиваетесь с подписками, является ошибкой. Я поднял вопрос here: link. Пожалуйста, звоните, чтобы получить больше отзывов. Поведение, которое вы ожидаете увидеть, - это то, что должно быть происходить после устранения ошибки. То есть после того, как вы отменили подписку на данное событие, это событие больше не должно быть перенаправлено на конечную точку (в случае ForwardingTopology) или сохранено по подписке на конечную точку (в случае EndpointOrientedTopology).

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

Answer 3

У вас есть подписчики? Должны ли все клиенты получать однотипные события или вы собираетесь их фильтровать? Если это последнее, это больше похоже на уведомления.

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

Рамка, подобная SignalR, подходит для такого случая использования, когда вы хотите отправлять уведомления конкретному клиенту.

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