Microsoft AZ-204: Решения Azure для событий и сообщений — Руководство по подготовке

By Laurynas Brazys · 5 August 2026 · #microsoft #az-204 #certification #exam-prep #study-guide

Часть Microsoft Azure Developer Associate AZ-204 — Руководство по подготовке. Практикуйтесь с проверенными ответами в центре экзаменов Microsoft, или пройдите тесты на время на ExamRoll.io.

Обзор

Портфель сервисов Azure для работы с событиями и сообщениями включает четыре взаимодополняющих сервиса: Event Grid для реактивной обработки событий, Event Hubs для высокопроизводительного приёма потоковых данных, Service Bus для обмена сообщениями корпоративного уровня и координации рабочих процессов, и Notification Hubs для push-уведомлений для мобильных устройств. Для их освоения необходимо знать ключевые абстракции каждого сервиса, семантику доставки и повторных попыток, модели масштабирования, а также понимать, когда один сервис предпочтительнее другого в типичных шаблонах приложений, таких как pub/sub, обработка команд, приём телеметрии и уведомления для устройств или пользователей.

Event Grid: Разделы, подписки, схемы, фильтрация и очереди недоставленных сообщений

Event Grid — это полностью управляемая инфраструктура для публикации/подписки (pub/sub) на основе push-уведомлений для дискретных событий. Издатели (publishers) отправляют события в раздел (topic); подписчики (subscribers) регистрируют подписки на события в разделе и получают соответствующие события в поддерживаемых обработчиках, таких как веб-перехватчики HTTPS (webhooks), Azure Functions, Logic Apps, Service Bus, Storage Queues и Event Hubs. Event Grid определяет две модели издателей. Системные разделы (System topics) — это управляемые Azure ресурсы-разделы, представляющие встроенные сервисы Azure, которые публикуют события в вашей подписке или группе ресурсов (например, создание blob-объекта в Storage, ротация секрета в Key Vault или события Resource Manager). Пользовательские разделы (Custom topics) — это создаваемые пользователем конечные точки разделов, в которые публикуют события ваши приложения, что позволяет реализовывать шаблоны, управляемые событиями, в ваших собственных сервисах и доменах. Системные разделы не требуют кода издателя и упрощают связывание ресурсов Azure с реактивными обработчиками; пользовательские разделы дают вам полный контроль над контрактами и жизненным циклом событий.

События Event Grid могут использовать нативную схему Event Grid или спецификацию CloudEvents v1.0. В схеме Event Grid каждое событие включает id (уникальный идентификатор), eventType (действие), subject (иерархический путь, поддерживающий фильтрацию), eventTime (UTC), data (полезная нагрузка), dataVersion, metadataVersion и topic. CloudEvents предоставляет стандартизированный набор атрибутов, таких как id, source, type, time, subject и data. Выбор CloudEvents упрощает взаимодействие между платформами; схема Event Grid сохраняет паритет с событиями, исходящими от Azure, и обеспечивает расширенную фильтрацию по полю subject.

Подписки на события определяют маршрутизацию, параметры доставки и фильтры. Базовые фильтры включают фильтрацию по типу события, а также по префиксу/суффиксу поля subject (subjectBeginsWith, subjectEndsWith), что эффективно для иерархического именования ресурсов. Расширенные фильтры выполняют сопоставление по полям в событии верхнего уровня или внутри данных (например, сравнения числовых диапазонов, поиск подстроки без учёта регистра, проверка на равенство для логических значений и проверка на содержание в массиве). Вы можете комбинировать фильтры для точного контроля над разветвлением (fan-out), минимизируя работу нижестоящих систем и исходящий трафик (egress).

Доставка осуществляется по push-модели с семантикой “как минимум один раз” (at-least-once). Event Grid выполняет повторные попытки с экспоненциальной задержкой (exponential back-off). Вы можете настроить максимальное количество попыток и время жизни события (time-to-live); когда доставка в конечном итоге не удаётся или истекает срок жизни события, Event Grid может отправить его в очередь недоставленных сообщений (dead-letter) в контейнер Blob Storage, который вы указываете в подписке. Отправка в очередь недоставленных сообщений сохраняет полезную нагрузку и метаданные для аудита или повторной обработки; при необходимости используйте отдельный процесс для восстановления и воспроизведения событий. Конечные точки веб-перехватчиков (webhook endpoints) участвуют в рукопожатии для подтверждения владения (validation handshake), а для сетей с ограниченным доступом вы можете предпочесть управляемые конечные точки Azure (Functions, Service Bus, Storage Queue), которые не требуют публичного доступа и могут использовать авторизацию на основе Azure AD.

Event Hubs: Секции, группы потребителей, пропускная способность, захват и надежное потребление

Event Hubs принимает большие объемы телеметрии и потоки журналов с низкой задержкой. Данные добавляются в секции, которые представляют собой независимые, упорядоченные журналы фиксации. Секции выбираются во время создания для распараллеливания пропускной способности; производители назначают ключ секционирования для сохранения порядка для каждого ключа, а служба хеширует ключи для распределения по секциям. Несколько читателей могут обрабатывать секции параллельно; в пределах одной секции порядок гарантируется.

Группы потребителей предоставляют независимые представления потока, позволяя различным приложениям обработки поддерживать свои собственные позиции, не мешая друг другу (например, детектор аномалий в реальном времени и конвейер архивации). Горизонтальное масштабирование читателей требует балансировки владения секциями; EventProcessorClient из SDK координирует назначение и перебалансировку секций между экземплярами.

Единицы пропускной способности (Throughput Units, TU) на уровне Standard определяют емкость: каждая TU предоставляет квоты на входящую и исходящую пропускную способность. Функция автоматического расширения (Auto-inflate) может автоматически увеличивать количество TU для удовлетворения пиковых нагрузок. Уровень Premium использует единицы обработки (Processing Units) с выделенными вычислительными ресурсами и предсказуемой задержкой. Отслеживайте метрики регулирования (throttling), чтобы проверить правильность выделенных ресурсов. Event Hubs поддерживает протокол Kafka на той же конечной точке, что упрощает миграцию lift-and-shift для клиентов Kafka без необходимости запускать брокеры.

Производители могут использовать AMQP или HTTPS. AMQP (включая AMQP-over-WebSockets на порту 443) обеспечивает мультиплексированные, постоянные соединения и эффективную пакетную обработку и рекомендуется как для отправки, так и для получения. HTTPS подходит для простых или спорадических отправок, но не поддерживается для получения; длинные опросы (long-polling) недоступны, и вы жертвуете эффективностью и управлением потоком. В ограниченных корпоративных сетях AMQP-over-WebSockets сохраняет производительность, проходя через типичные исходящие прокси-серверы.

Создание контрольных точек и управление смещениями критически важны для корректности. Каждое событие имеет порядковый номер и смещение для каждой секции. Получатели продвигаются по потоку и после успешной обработки пакета сохраняют свою позицию в виде контрольной точки в надежном хранилище — обычно это контейнер Azure Blob Storage через EventProcessorClient. При перезапуске или сбое обработчик возобновляет работу с последней контрольной точки, достигая обработки «как минимум один раз» с помощью идемпотентных обработчиков. Без контрольных точек потребители начинают с позиции по умолчанию (последней или самой ранней) и рискуют повторно обработать или пропустить события.

Функция «Захват» (Capture) обеспечивает архивацию на стороне сервера, автоматически записывая пакетные файлы Avro, доступные только для добавления, в Azure Blob Storage или Azure Data Lake Storage Gen2 по настраиваемому временному или размерному окну. Это избавляет от необходимости создавать собственные обработчики пакетов для аналитики «холодного» пути (cold-path), позволяя последующим инструментам (Spark, Synapse) потреблять неизменяемые сегменты потока с семантикой «ровно один раз» относительно конвейера захвата.

Service Bus и Queue Storage: команды, рабочие процессы, сеансы и обработка опасных сообщений

Service Bus — это брокер сообщений корпоративного уровня для команд, рабочих процессов и сценариев интеграции, которым требуются надежные гарантии доставки. Очереди реализуют обмен сообщениями по принципу «точка-точка»; каждое сообщение получает один конкурирующий потребитель. Разделы (topics) с подписками реализуют модель «публикация-подписка» (pub/sub): издатели отправляют сообщения в раздел, а независимые подписки получают копии на основе правил. Правила подписки могут быть SQL-фильтрами, фильтрами корреляции или логическими фильтрами (boolean true filters), которые вычисляют для каждого сообщения, нужно ли его включать, и могут добавлять или изменять свойства сообщения с помощью действий.

Сеансы обеспечивают упорядоченную и монопольную обработку связанных сообщений. Присваивайте один и тот же SessionId сообщениям, которые относятся к одной группе (например, всем шагам в заказе 123). Получатель принимает блокировку сеанса и обрабатывает сообщения для этого сеанса в порядке их поступления, поддерживая необязательное состояние сеанса, а затем освобождает сеанс, чтобы следующий потребитель мог стать его владельцем. Это предпочтительный шаблон для реализации FIFO в больших масштабах. Без сеансов порядок обработки сообщений между конкурирующими потребителями не гарантируется.

Service Bus поддерживает режимы PeekLock и ReceiveAndDelete. PeekLock — это режим по умолчанию для обеспечения надежности: потребитель блокирует сообщение на время блокировки, обрабатывает его, а затем подтверждает получение с помощью операции Complete. Если обработка завершается неудачно, потребитель может выполнить операцию Abandon (сделать сообщение снова доступным), Defer (отложить получение до более позднего момента по порядковому номеру) или Dead-letter (переместить сообщение в отдельную подочередь недоставленных сообщений сущности с указанием причины и описания ошибки). Режим ReceiveAndDelete жертвует надежностью в пользу пропускной способности, удаляя сообщение сразу после получения.

Ключевые свойства управляют жизненным циклом. Свойство Time to Live (TTL) можно установить по умолчанию для сущности и переопределить для каждого отдельного сообщения; сообщения с истекшим сроком жизни перемещаются в очередь недоставленных сообщений или удаляются в зависимости от конфигурации. Длительность блокировки (Lock duration) определяет, как долго сообщение остается заблокированным для обработки; SDK может автоматически продлевать блокировки для длительных операций в пределах установленных максимумов. Максимальное количество доставок (Max delivery count) настраивается для каждой очереди или подписки; после указанного числа попыток доставки (через Abandon или потерю блокировки) сообщение автоматически перемещается в очередь недоставленных сообщений (DLQ). Операторы извлекают сообщения из DLQ для диагностики или повторной обработки с использованием корректирующей логики.

Azure Queue Storage — это более простой, но при этом массово масштабируемый сервис очередей с REST-интерфейсом, который лучше всего подходит для базового разделения компонентов, сценариев с большим числом получателей (high fan-out) и нагрузок, чувствительных к стоимости. Он обеспечивает доставку по крайней мере один раз (at-least-once), тайм-аут видимости для скрытия сообщений во время обработки и TTL для каждого сообщения (по умолчанию 7 дней, настраивается, вплоть до бессрочного). Отдельные сообщения ограничены по размеру, а такие функции, как сеансы, транзакции, гарантии порядка, обнаружение дубликатов, подочереди недоставленных сообщений и расширенные фильтры, недоступны. Выбирайте Queue Storage для простых фоновых задач и очень высокой пропускной способности при низкой стоимости. Выбирайте Service Bus, когда вам нужна сложная маршрутизация (разделы/подписки), FIFO с помощью сеансов, доставка по расписанию, отложенная обработка, транзакции между сущностями, окна для обнаружения дубликатов, поддержка AMQP, или когда важны надежность и управляемость интеграции. Распространенный шаблон — собирать легковесные события через Event Grid или Queue Storage и координировать критически важные для бизнеса команды и переходы состояний с помощью Service Bus.

Notification Hubs: Маршрутизация push-уведомлений и управление учетными данными платформ

Notification Hubs — это кроссплатформенный механизм push-уведомлений, который управляет регистрацией устройств в большом масштабе и маршрутизирует целевые уведомления на платформы Apple (APNs), Android (FCM), Windows (WNS) и другие. Приложения регистрируют устройства, используя теги и выражения тегов, что позволяет точно выбирать аудиторию (например, user:42 AND region:emea OR topic:promotions). Шаблоны позволяют отправлять единую локализованную полезную нагрузку, которую обработчики для конкретных платформ разворачивают, что уменьшает объем серверной логики и обеспечивает персонализацию для каждого устройства с минимальным ветвлением на бэкенде. Модель Installation упрощает управление жизненным циклом устройств, инкапсулируя дескриптор платформы, теги и шаблоны в единый ресурс для каждого устройства.

Управление учетными данными платформ играет центральную роль в надежной доставке. Для APNs загрузите учетные данные на основе сертификатов или токенов (с Key ID, Team ID и токеном .p8) и выберите конечные точки для песочницы или продакшена для каждого центра или пространства имен, чтобы разделить среды. Для FCM настройте соответствующие учетные данные сервера (для HTTP v1 используйте сервисный аккаунт Google с областями действия OAuth2). Для WNS зарегистрируйте приложение, чтобы получить Package SID и секрет клиента. Учетные данные периодически ротируются; планируйте ротацию и отслеживайте каналы обратной связи на предмет недействительных дескрипторов устройств. Notification Hubs использует SAS для аутентификации на уровне центра с вашего сервера приложений, в то время как роли Azure AD защищают операции управления. Используйте соглашения по тегированию для разделения мультитенантных приложений и регулируйте отправку с помощью запланированных или пакетных push-уведомлений для соблюдения квот платформы.

Практический сценарий

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

1. Настроить жизненный цикл заказа на основе событий с помощью Event Grid

• Создайте пользовательский топик Event Grid с именем OrderEvents и публикуйте дискретные доменные события, такие как OrderPlaced, PaymentAuthorized и OrderReady. Используйте пути темы, например /stores/{storeId}/orders/{orderId}, чтобы обеспечить фильтрацию по префиксу для каждого заведения. Настройте подписки: одну на топик Service Bus для обработки рабочего процесса и одну на Azure Function для легковесного обогащения данных. Event Grid выбран за низкую задержку при рассылке (fan-out), нормализацию схемы (CloudEvents) и эффективную фильтрацию, которая позволяет избежать ненужных вызовов нижестоящих сервисов.

2. Координировать рабочий процесс бариста с помощью топиков и сессий Service Bus

• Определите топик Service Bus с именем Orders с подписками для каждого этапа обработки (Preparation, Handoff), каждая из которых имеет корреляционные или SQL-фильтры по eventType. Публикуйте команды как сообщения с SessionId = {orderId} для гарантии FIFO для каждого заказа. Потребители используют PeekLock с автоматическим продлением блокировки и вызывают Complete в случае успеха; при временном сбое Abandon инициирует повторную попытку; при постоянном сбое или для отравленных сообщений (poison messages) превышение Max delivery count перемещает их в DLQ для последующего анализа. TTL для сообщений, специфичных для этапа, предотвращает обработку устаревших задач после закрытия кофейни. Service Bus выбран за упорядоченную, надежную обработку команд, богатые возможности по завершению обработки сообщений (settlement) и pub/sub на основе правил.

3. Принимать и архивировать телеметрию оборудования с помощью Event Hubs

• Подготовьте Event Hub с именем Telemetry с достаточным количеством разделов (partitions) для распараллеливания по deviceId и включите автоматическое увеличение TUs для поглощения пиковых нагрузок. Шлюзы устройств отправляют данные по протоколу AMQP-over-WebSockets для эффективного прохождения через корпоративные прокси-серверы. Используйте EventProcessorClient с сохранением контрольных точек (checkpointing) в Blob Storage для выполнения обнаружения аномалий и оповещения почти в реальном времени. Включите Capture в ADLS Gen2 для создания неизменяемых архивов в формате Avro, поддерживающих офлайн-аналитику в Synapse. Event Hubs выбран за устойчивый прием данных с высокой пропускной способностью, с надежным сохранением смещений (durable offsets) и простым экспортом по холодному пути (cold-path).

4. Направлять целевые push-уведомления с помощью Notification Hubs

• Регистрируйте мобильные устройства, используя модель Installation, присваивая каждому теги user:{userId}, store:{storeId} и теги платформы. Загрузите учетные данные на основе токена APNs для iOS и сервисный аккаунт FCM для Android; используйте отдельные центры для разработки и продакшена, чтобы изолировать учетные данные и каналы обратной связи. Когда поступают события OrderReady, Azure Function отправляет единое шаблонное уведомление в Notification Hubs, адресованное тегам user:{userId} AND store:{storeId}. Notification Hubs выбран за независимую от платформы маршрутизацию, выражения тегов и централизованное управление учетными данными в глобальном масштабе.

5. Обеспечить наблюдаемость и отказоустойчивость

• Настройте для Event Grid отправку недоставленных сообщений (dead-lettering) в контейнер Blob для их сохранения с целью аудита и повторной обработки. Отслеживайте DLQ в Service Bus и предоставьте оператору рабочий процесс для анализа и повторной постановки в очередь исправленных сообщений. Отслеживайте отставание потребителей (consumer lag) Event Hubs с помощью метрик, чтобы проверять работу контрольных точек и горизонтально масштабировать обработчики при росте очереди. Эта комбинация обеспечивает сквозную надежность: доставка по крайней мере один раз (at-least-once) с путями для повторной обработки в исключительных ситуациях, при этом сохраняя основной сценарий (happy path) быстрым и экономически эффективным.

Эта архитектура четко разделяет зоны ответственности: Event Grid управляет реактивной оркестрацией, Service Bus гарантирует корректность и порядок выполнения рабочего процесса, Event Hubs обрабатывает непрерывную телеметрию в большом масштабе, а Notification Hubs доставляет точные, специфичные для платформы уведомления клиентам с минимальной сложностью на бэкенде.

← Azure API Management · Все домены · Кэширование →

Отработать эти вопросы → · Тесты на время на ExamRoll.io →

Просмотреть Microsoft →