Очереди и топики: выбор правильного шаблона обмена сообщениями в Azure Service Bus

By Mirko Peters · 2026-08-27

С возвращением на страницу-спутник подкаста! В нашем последнем эпизоде мы подробно разобрали базовые элементы облачного обмена сообщениями. Если у вас не было возможности…

Automatically translated with AI from the original post. Read the English original

Добро пожаловать обратно в блог-приложение к подкасту! В нашем последнем выпуске мы подробно разобрали базовые элементы облачной системы обмена сообщениями. Если вы ещё не успели послушать выпуск, обязательно посмотрите эпизод Azure Service Bus - Simply Explained. Сегодня мы подробнее остановимся на одном из самых важных архитектурных решений, которое вам придётся принимать при создании распределённых приложений: выборе между очередями и топиками Azure Service Bus. Понимание тонкостей этих двух шаблонов обмена сообщениями поможет вам проектировать более отказоустойчивые, масштабируемые и простые в сопровождении системы.

Введение в Azure Service Bus и шаблоны обмена сообщениями

По мере того как современные приложения переходят от монолитной архитектуры к распределённым решениям на основе микросервисов, надёжное взаимодействие между компонентами становится первостепенным. Сервисы не могут полагаться только на синхронные HTTP-вызовы во всём: это создаёт жёсткую связанность, каскадные сбои и узкие места в производительности. Именно здесь на помощь приходят облачные брокеры сообщений.

Azure Service Bus выступает как полностью управляемый корпоративный брокер сообщений, который развязывает приложения и сервисы. Позволяя отправителям передавать сообщения, не зная, кто их получатель и даже находится ли получатель сейчас в сети, Azure Service Bus обеспечивает высокую доступность и сглаживание пиковых нагрузок. Однако, как только вы решаете использовать Azure Service Bus, перед вами сразу встаёт ключевой вопрос проектирования: нужна ли мне очередь или топик?

Что такое Azure Service Bus?

Прежде чем разбираться в различиях между очередями и топиками, полезно понять, что именно делает Azure Service Bus. По сути, Azure Service Bus — это брокер сообщений, который надёжно хранит сообщения в пространстве имён до тех пор, пока принимающее приложение не будет готово их обработать. Он предоставляет развитые возможности, такие как гарантия доставки «не менее одного раза», управление сеансами, перемещение в недоставленные сообщения и отложенная доставка сообщений.

В облачной экосистеме Azure Service Bus связывает различные компоненты вашего приложения. Будете ли вы обрабатывать заказы интернет-магазина, принимать телеметрию Интернета вещей (IoT) или координировать интеграцию с системами планирования ресурсов предприятия (ERP), Service Bus обеспечивает надёжность и мощность асинхронной обработки, необходимые для того, чтобы данные плавно продолжали поступать.

Очереди и топики: ключевой архитектурный выбор

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

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

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

Подробно об очередях Service Bus

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

Когда вы отправляете сообщение в очередь, оно находится в ней до тех пор, пока получатель его не заберёт. По умолчанию очереди обеспечивают строгий порядок доставки «первым пришёл — первым ушёл» (FIFO). Это делает очереди идеальными для архитектур, управляемых командами, где важен порядок, например при обработке платёжных транзакций или выполнении последовательных шагов рабочего процесса.

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

Освоение топиков и подписок

Если очереди обеспечивают простую доставку «точка-точка», то топики открывают возможности архитектур «публикация/подписка» (pub/sub). Топик выступает конечной точкой для отправки сообщений, но сам по себе не может хранить сообщения без подписок.

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

Например, рассмотрим событие размещения заказа на платформе электронной коммерции. Когда клиент оформляет заказ, система публикует сообщение OrderPlaced в топик. Сервис учёта запасов имеет подписку для обновления уровней остатков, сервис выставления счетов — подписку для обработки платежа, а сервис уведомлений — подписку для отправки электронного чека по почте. Все три системы получают событие одновременно, не мешая друг другу.

Фильтрация сообщений и гибкость

Одна из самых мощных возможностей топиков Azure Service Bus — фильтрация сообщений. Во многих сценариях pub/sub подписчику нужна не каждое сообщение, опубликованное в топик, а лишь определённое подмножество данных.

Azure Service Bus позволяет определять правила и фильтры для подписок с использованием синтаксиса, похожего на SQL, или свойств корреляции. Например, вы можете настроить подписку так, чтобы она получала только сообщения, у которых свойство Region равно NorthAmerica, или те, у которых OrderAmount превышает заданный порог.

Фильтрация снижает объём сетевого трафика и гарантирует, что последующие потребители обрабатывают только релевантные для них данные, существенно сокращая лишние вычислительные издержки.

Обработка сбоев с помощью очередей недоставленных сообщений

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

Azure Service Bus изящно справляется с этим с помощью очередей недоставленных сообщений (Dead-Letter Queues, DLQ). У каждой очереди и каждой подписки топика есть связанная вспомогательная очередь, которая называется очередью недоставленных сообщений. Если обработка сообщения завершается неудачей слишком много раз (превышено максимальное количество доставок) или срок его действия истекает, Service Bus автоматически перемещает такое сообщение в DLQ.

Этот механизм изолирует «ядовитые сообщения», чтобы они не блокировали основной конвейер обработки. Инженеры могут просмотреть DLQ, проанализировать причину сбоя, исправить основную ошибку, а затем вернуть сообщение в основной процесс для успешной обработки.

Рекомендации по проектированию распределённых приложений

Чтобы извлечь максимум из внедрения Azure Service Bus, крайне важно следовать проверенным архитектурным рекомендациям:

• Изолируйте среды: используйте отдельные пространства имён Service Bus для сред разработки, тестирования и продуктивной среды, чтобы сбои не распространялись между средами.
• Внедряйте инфраструктуру как код: описывайте очереди, топики, подписки и фильтры с помощью шаблонов ARM, Bicep или Terraform, чтобы обеспечить единообразие развёртываний.
• Задавайте подходящие политики хранения: настраивайте время жизни сообщений (TTL) и длительность блокировок исходя из реальных бизнес-потребностей, а не полагайтесь на максимальные значения по умолчанию.
• Осуществляйте мониторинг и оповещения: используйте Azure Monitor и Application Insights для отслеживания таких метрик, как количество сообщений, активные сообщения в DLQ и задержка сервера.

Заключение: выбор правильного шаблона для вашей архитектуры

Выбор правильного шаблона обмена сообщениями в Azure Service Bus — основа для создания отказоустойчивых и масштабируемых облачных приложений. Используйте очереди, когда нужен надёжный механизм «один к одному» для балансировки нагрузки и последовательной обработки задач. Выбирайте топики и подписки, когда требуется модель «публикация/подписка» для рассылки событий нескольким независимым системам.

Чтобы услышать больше обсуждений облачной архитектуры, безопасности и современных паттернов разработки, обязательно послушайте полный эпизод: Azure Service Bus - Simply Explained. Правильная интеграция этих паттернов обмена сообщениями обеспечит устойчивость, адаптивность и готовность ваших облачных приложений к масштабированию под любой нагрузкой.