Azure Очереди служебной шины по сравнению с темами (Pub / Sub)

Question

Требуется небольшое архитектурное руководство. У меня есть набор служб без сохранения состояния , которые выполняют различные функции. Моя архитектура позволяет запускать несколько копий каждой службы одновременно (поскольку они не имеют состояния), что позволяет мне:

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

Однако я не хочу дублирования работы.

Если Служба A, экземпляр 1 уже принял задание AB C, я не хочу, чтобы служба A, экземпляр 2 выполняла ту же работу. Итак, я мог бы избежать этой проблемы, используя Azure очередей служебной шины. Только один рабочий получит конкретный элемент из очереди и будет переназначен другому работнику только в том случае, если рабочий не пометит его как завершенный в установленное время.

Итак, каков подходящий вариант использования тем (Pub / Sub)? Похоже, что если у меня когда-либо будет несколько копий одной и той же службы, я должен полагаться на очереди. Правильно?

Другой вопрос: есть ли способ использовать темы в Azure служебной шине или аналогичные продукты / услуги, но избежать дублирования работы? Кроме того, если есть способ заблокировать сообщение (на короткий период времени) при использовании тем, можно ли заблокировать это сообщение только для одного экземпляра службы A (чтобы никакие другие экземпляры службы A не имели к нему доступа), но сообщение будет транслировать в службу B, службу, C, и т.д. c.?

Answer 1

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

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

Кроме того, если есть способ заблокировать сообщение (на короткий период времени) при использовании тем, можно ли заблокировать это сообщение только для одного экземпляра службы A (так никакие другие экземпляры службы A не будут иметь к ней доступа), но сообщение будет транслироваться в службу B, Service, C, et c.?

Конечно, можно заблокировать сообщение. Для этого вам нужно будет получать сообщения в режиме Peek-Lock. Однако, если задействовано несколько подписчиков (служб), то только один подписчик сможет заблокировать сообщение и получить к нему доступ. Для других подписчиков сообщение будет невидимым. У вас не может быть сценария, в котором одна служба получает блокировку, а другие службы все еще получают сообщение.

Answer 2

Azure триггеров функций предоставят все, что вы ищете, из коробки.

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

Если вам нужна служебная шина, вы можете использовать триггеры служебной шины .

Надеюсь, что это поможет.