Azure Fundamentals · Урок

Azure Service Bus для слабосвязанного обмена сообщениями

«Azure Service Bus для слабосвязанного обмена сообщениями» — бесплатный урок Azure Fundamentals на CoddyKit. Это урок 2 из 4. Ты можешь прочитать весь урок бесплатно ниже — а потом практиковать его прямо в браузере с встроенным редактором кода и ИИ-репетитором 24/7. Это часть пути обучения Azure Fundamentals, и твой прогресс синхронизируется между веб-версией и приложением CoddyKit. Курс Azure Fundamentals содержит 4 уроков всего.

Зачем разделять компоненты с помощью обмена сообщениями?

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

Пространства имён и уровни Service Bus

Пространство имён Service Bus — это контейнер верхнего уровня для всех сущностей обмена сообщениями (очередей и тем), предоставляющий конечную точку FQDN (например, myns.servicebus.windows.net). Пространства имён доступны на трёх уровнях: базовый (только очереди, без тем, максимальный размер сообщения — 256 КБ), Standard (очереди и темы, максимум 256 КБ) и Премиум (очереди и темы, сообщения размером до 100 МБ, выделенная ёмкость, интеграция с VNet и георезервное восстановление). Уровень Премиум необходим для рабочих нагрузок, которым требуется производительность, обеспеченная SLA.

# Create a Service Bus namespace (Standard tier)
az servicebus namespace create \
  --resource-group myRG \
  --name myservicebusns \
  --location eastus \
  --sku Standard

Очереди: обмен сообщениями один к одному

Очередь Service Bus хранит сообщения в порядке FIFO и доставляет каждое сообщение ровно одному потребителю. Потребители получают сообщения с помощью механизма просмотра с блокировкой: на время обработки сообщение скрывается от других потребителей. Если потребитель успешно завершает обработку, он вызывает CompleteMessage(), чтобы удалить сообщение из очереди. Если обработка завершается неудачно, потребитель вызывает AbandonMessage(), и сообщение снова становится видимым для следующей попытки. После настраиваемого числа попыток доставки необрабатываемые сообщения перемещаются в очередь недоставленных сообщений (DLQ).

# Create a Service Bus queue with DLQ enabled
az servicebus queue create \
  --resource-group myRG \
  --namespace-name myservicebusns \
  --name orders \
  --max-delivery-count 5 \
  --default-message-time-to-live P7D \
  --dead-lettering-on-message-expiration true

Темы и подписки

Темы реализуют шаблон публикации и подписки: производитель отправляет сообщение в тему, а любое количество подписок на эту тему получает собственную копию сообщения. Подписки могут иметь фильтры (SQL-выражения или выражения корреляции), чтобы получать только часть сообщений — например, подписка HighPriority, которая получает только сообщения, где свойство Priority равно High. Это позволяет одной теме распределять сообщения между множеством зависимых служб, каждая из которых заинтересована в своей части событий.

# Create a topic and two subscriptions with filters
az servicebus topic create \
  --resource-group myRG \
  --namespace-name myservicebusns \
  --name order-events

az servicebus topic subscription create \
  --resource-group myRG \
  --namespace-name myservicebusns \
  --topic-name order-events \
  --name high-priority-sub

az servicebus topic subscription rule create \
  --resource-group myRG \
  --namespace-name myservicebusns \
  --topic-name order-events \
  --subscription-name high-priority-sub \
  --name PriorityFilter \
  --filter-sql-expression 'Priority = '"'"'High'"'"''

Отправка и получение сообщений

Azure Service Bus SDK предоставляет ServiceBusClient для отправки и получения сообщений. Для отправки создайте ServiceBusSender и вызовите SendMessageAsync(). Для получения создайте ServiceBusReceiver и вызовите ReceiveMessageAsync() (получение по запросу) или используйте ServiceBusProcessor с обработчиком событий для непрерывной обработки по инициативе службы. Использование DefaultAzureCredential с Service Bus SDK устраняет необходимость в строках подключения и сохраняет подход без паролей.

# Python: Send a message to a Service Bus queue
from azure.servicebus import ServiceBusClient, ServiceBusMessage
from azure.identity import DefaultAzureCredential

credential = DefaultAzureCredential()
client = ServiceBusClient(
  fully_qualified_namespace='myservicebusns.servicebus.windows.net',
  credential=credential
)
with client.get_queue_sender(queue_name='orders') as sender:
    msg = ServiceBusMessage('{ 'orderId': '12345', 'amount': 99.99 }')
    sender.send_messages(msg)
    print('Message sent')

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

Очередь недоставленных сообщений (DLQ) — это вспомогательная очередь, в которую автоматически попадают сообщения, которые невозможно доставить. Сообщения помещаются в очередь недоставленных сообщений, когда превышено максимальное число доставок, истёк срок их действия (истёк TTL) или они не прошли проверку фильтра подписки на тему. Мониторинг DLQ имеет решающее значение: рост DLQ указывает на систематический сбой обработки. Сообщения DLQ сохраняют исходное содержимое, а также свойства причина помещения в очередь недоставленных сообщений и описание, добавленные Service Bus для диагностики первопричины.

# Read messages from the dead-letter queue
az servicebus queue show \
  --resource-group myRG \
  --namespace-name myservicebusns \
  --name 'orders/$DeadLetterQueue' \
  --query 'countDetails.deadLetterMessageCount'

Сеансы сообщений для упорядочивания

Сеансы обеспечивают строгий порядок сообщений, относящихся к одной логической группе. Каждому сообщению присваивается SessionId (например, идентификатор клиента или заказа), а потребитель, поддерживающий сеансы, получает все сообщения для определённого сеанса исключительно в порядке FIFO. Сеансы необходимы для рабочих процессов, в которых шаги должны выполняться последовательно, например при обработке всех событий для конкретного заказа: Created → PaymentReceived → Shipped → Delivered. Сеансы включаются при создании очереди или подписки.

Service Bus, Event Grid и Event Hubs

Эти три службы обмена сообщениями Azure часто путают: Service Bus предназначен для надёжного корпоративного обмена сообщениями с поддержкой транзакций, упорядочивания, сеансов и DLQ — он подходит для обработки заказов, финансовых транзакций и оркестрации рабочих процессов. Event Grid предназначен для реактивной маршрутизации событий (например, был загружен большой двоичный объект или удалена VM) с распределением между несколькими обработчиками, но без упорядочивания и повторного воспроизведения. Event Hubs предназначен для потоковой передачи событий с высокой пропускной способностью (миллионы событий в секунду) и возможностью повторного воспроизведения — он подходит для телеметрии IoT и приёма журналов. Выбирайте службу с учётом требований к упорядочиванию, пропускной способности и сохранности данных.

Георезервное восстановление

Георезервное восстановление (Geo-DR) Service Bus реплицирует метаданные пространства имён (очереди, темы, подписки и политики доступа) во вторичный регион. Связанные регионы используют одно имя узла псевдонима; если основной регион выходит из строя, Вы инициируете переключение, и псевдоним начинает указывать на вторичный регион. Обратите внимание: данные сообщений (сообщения, находящиеся в обработке) не реплицируются на уровне Standard — сообщения реплицируются с помощью Geo-DR только на уровне Премиум. Для критически важных систем обмена сообщениями используйте Премиум и Geo-DR, чтобы соответствовать требованиям RTO и RPO.

Масштабирование и секционированные сущности

Для сценариев с высокой пропускной способностью включите секционирование очередей и тем при их создании. Секционированные сущности используют несколько брокеров сообщений и фрагментов хранилища, что увеличивает пропускную способность. На уровне Standard общий размер секционированных сущностей составляет до 80 ГБ. Каждое сообщение направляется в секцию на основе его свойства PartitionKey (по умолчанию используется идентификатор сеанса, если сеансы включены). Секционирование выбирается один раз при создании — существующую очередь нельзя секционировать. Используйте уровень Премиум, чтобы получить максимально гарантированную пропускную способность без сложностей, связанных с секционированием.

# Create a partitioned queue (Standard tier)
az servicebus queue create \
  --resource-group myRG \
  --namespace-name myservicebusns \
  --name orders-partitioned \
  --enable-partitioning true

Мониторинг состояния Service Bus

Основные метрики Service Bus, которые следует отслеживать в Azure Monitor: Active Messages (глубина очереди — её рост указывает на отставание потребителя), Dead-lettered Messages (сбои обработки), Server Errors и User Errors (проблемы аутентификации и ограничения пропускной способности), а также Incoming Requests (общая пропускная способность). Настройте оповещения по метрикам, чтобы операционные команды получали уведомления, когда очередь недоставленных сообщений превышает пороговое значение или активные сообщения не потребляются в течение длительного времени.

Быстрая проверка

Проверьте своё понимание концепций Microsoft Azure Fundamentals (AZ-900) из этого урока.

Итоги урока

В этом уроке Вы узнали, что очереди Service Bus обеспечивают обмен сообщениями один к одному с доставкой посредством просмотра с блокировкой и очередью недоставленных сообщений для неудачных сообщений; темы и подписки распределяют сообщения между несколькими потребителями с помощью правил фильтрации; а сеансы обеспечивают упорядоченную обработку сообщений, относящихся к одной логической группе. Далее мы рассмотрим Azure Container Apps для развёртывания современных микрослужб.

Часто задаваемые вопросы

Урок «Azure Service Bus для слабосвязанного обмена сообщениями» бесплатный?

Да — полный текст урока «Azure Service Bus для слабосвязанного обмена сообщениями» бесплатно доступен здесь в веб-версии. Чтобы практиковать его интерактивно (встроенный редактор кода и ИИ-репетитор 24/7) и разблокировать остальной курс Azure Fundamentals, подпишись на CoddyKit PRO. Курс Azure Fundamentals содержит 4 уроков всего.

Чему я научусь в уроке «Azure Service Bus для слабосвязанного обмена сообщениями»?

Создайте пространство имен Service Bus с очередями и разделами, отправляйте и принимайте сообщения из приложения и настройте очереди недоставленных сообщений для обработки неудачных сообщений. Ты практикуешь Azure Fundamentals с помощью реального кода, который запускаешь прямо в браузере, и ИИ-репетитор 24/7 отвечает на твои вопросы во время урока.

Нужен ли мне опыт, чтобы начать Azure Fundamentals?

Предыдущий опыт не требуется. Azure Fundamentals на CoddyKit структурирован для всех уровней — от новичков до продвинутых, поэтому ты можешь начать отсюда или с самого начала и учиться в своем темпе. Это урок 2 из 4.

Сколько времени занимает урок «Azure Service Bus для слабосвязанного обмена сообщениями»?

Большинство уроков CoddyKit занимают около 5–10 минут. Каждый из них компактный и интерактивный, поэтому ты постоянно делаешь прогресс и продолжаешь с того же места в веб-версии и приложении.

Можно ли писать и запускать код в этом уроке Azure Fundamentals?

Да. Каждый урок Azure Fundamentals включает встроенный редактор кода, поэтому ты пишешь и запускаешь реальный код прямо в браузере и получаешь моментальную обратную связь от AI — локальная установка не требуется.

Все уроки этого курса

Управляемое удостоверение для аутентификации без паролей
Azure Service Bus для слабосвязанного обмена сообщениями
Azure Container Apps
Сквозной рабочий процесс разработчика

← Назад к Azure Fundamentals