Функции и терминология в Центрах событий Azure

Центры событий Azure — это масштабируемая служба обработки событий, которая обрабатывает большие объемы событий и данных с низкой задержкой и высокой надежностью. Общие сведения о службе см. в разделе "Что такое Центры событий?".

В этой статье приведены сведения, приведенные в статье обзора, а также технические сведения о компонентах и функциях Центров событий.

Пространство имен

Пространство имен Event Hubs — это контейнер управления для центров событий (или топиков на языке Kafka). Он предоставляет конечные точки сети, интегрированные с DNS, и ряд функций управления доступом и сетевой интеграции, таких как фильтрация IP-адресов, конечная точка службы виртуальной сети и приватный канал.

Перегородки

Центры событий упорядочивают последовательности событий, отправленных в концентратор событий, в одну или несколько секций. По мере поступления новых событий они добавляются в конец этой последовательности.

Раздел можно рассматривать как журнал фиксации. Разделы содержат данные о событиях, включающие следующие сведения:

• Содержимое события
• Определяемый пользователем контейнер свойств, описывающий событие
• Метаданные, такие как смещение в разделе, номер в последовательности потока
• Метка времени на стороне службы, в которой она была принята

Преимущества использования секций

Служба "Центры событий" предназначена для обработки больших объемов событий, а секционирование помогает при этом двумя способами.

• Несмотря на то, что Центры событий — это служба PaaS, под ней есть физическая реальность. Сохранение журнала, сохраняющего порядок событий, требует, чтобы эти события хранились вместе в базовом хранилище и ее репликах, что приводит к потолку пропускной способности для такого журнала. Секционирование позволяет использовать несколько параллельных журналов для одного концентратора событий и, таким образом, увеличивает доступную пропускную способность ввода-вывода.
• Ваши приложения должны справляться с обработкой объема событий, отправляемых в концентратор событий. Это может быть сложно и требует значительных ресурсов для масштабной, параллельной обработки. Емкость одного процесса обработки событий ограничена, поэтому вам требуется несколько процессов. Разделы — это способ, как ваше решение распределяет эти процессы и при этом заботится о том, чтобы у каждого события был четкий ответственный за обработку.

Количество разделов

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

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

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

Когда речь идет о ценообразовании, не важно, сколько разделов находится в концентраторе событий. Это зависит от количества единиц ценообразования (единиц пропускной способности для стандартного уровня, единиц обработки для уровня "Премиум" и единиц мощности для уровня "Выделенный") для пространства имен или выделенного кластера. Например, концентратор событий стандартного уровня с 32 секциями или с одной секцией влечет за собой одинаковую стоимость, если пространство имен имеет вместимость в один TU. Кроме того, можно масштабировать единицы транзакций (TUs) или единицы процесса (PUs) в вашем пространстве имен или единицы вычислительной мощности (CUs) в выделенном кластере независимо от количества разделов.

Раздел — это механизм организации данных, который обеспечивает параллельную публикацию и использование. Хотя она поддерживает параллельную обработку и масштабирование, общая емкость остается ограниченной выделением пространства имен. Рекомендуется сбалансировать единицы масштабирования (единицы пропускной способности для стандартного уровня, единицы обработки для уровня "Премиум" или единицы емкости для выделенного уровня) и секции для достижения оптимального масштабирования. Как правило, рекомендуется использовать максимальную пропускную способность в 1 МБ/с на секцию. Таким образом, общее правило для вычисления количества разделов — делить максимальную ожидаемую пропускную способность на 1 МБ/с. Например, если для вашего варианта использования требуется 20 МБ/с, рекомендуется выбрать по крайней мере 20 секций для достижения оптимальной пропускной способности.

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

Сопоставление событий с разделами

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

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

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

Издатели событий

Любая сущность, которая отправляет данные в концентратор событий, является издателем событий (синонимом, используемым с производителем событий). Издатели событий могут публиковать события с помощью ПРОТОКОЛА HTTPS или AMQP 1.0 или протокола Kafka. Издатели событий используют авторизацию на основе Microsoft Entra ID с помощью JWT, выданных OAuth2, или маркера Shared Access Signature (SAS) для концентратора событий для получения доступа к публикации.

Событие можно опубликовать с помощью ПРОТОКОЛА AMQP 1.0, протокола Kafka или HTTPS. Служба Центров событий предоставляет REST API и .NET, Java, Python, Java, JavaScript и Go клиентские библиотеки для публикации событий в концентраторе событий. Для других сред выполнения и платформ можно использовать любой клиент AMQP 1.0, например Apache Qpid.

Выбор использования AMQP или HTTPS зависит от сценария использования. AMQP требует установления постоянного двунаправленного сокета, а также использования защиты транспортного уровня (TLS) или SSL/TLS. AMQP имеет более высокие затраты на сеть при инициализации сеанса, однако HTTPS требует дополнительных затрат TLS для каждого запроса. AMQP имеет более высокую производительность для частых издателей и может достичь значительно меньшей задержки при использовании с асинхронным кодом публикации.

Можно публиковать события по отдельности или в пакетном режиме. Одна публикация имеет ограничение в 1 МБ, независимо от того, является ли это одним событием или пакетом. События публикации, превышающие это пороговое значение, отклоняются.

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

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

Хранение событий

Опубликованные события удаляются из концентратора событий на основе настраиваемой политики хранения на основе времени. Вот несколько важных моментов:

• Значение по умолчанию и самый короткий срок хранения составляет 1 час.
• Для Центров событий "Стандартный" максимальный срок хранения составляет 7 дней.
• Для Центров событий "Премиум " и "Выделенный" максимальный срок хранения составляет 90 дней.
• При изменении срока хранения он применяется ко всем событиям, включая события, которые уже находятся в концентраторе событий.

Центры событий сохраняют события для настроенного времени хранения, которое применяется во всех секциях. События автоматически удаляются при достижении периода хранения. Если вы указали период хранения в течение одного дня (24 часа), событие становится недоступным ровно через 24 часа после его принятия. События нельзя явно удалять.

Если необходимо архивировать события за пределы допустимого периода хранения, их можно автоматически хранить в службе хранилища Azure или Azure Data Lake, включив функцию отслеживания центров событий. Если вам нужно искать или анализировать такие глубокие архивы, их можно легко импортировать в Azure Synapse или другие аналогичные магазины и платформы аналитики.

Причина ограничения на хранение данных в Центрах событий по времени заключается в предотвращении того, чтобы большие объемы исторических данных клиентов не оказались в глубине хранилища, которое индексируется только меткой времени и допускает только последовательный доступ. Архитектурная философия здесь заключается в том, что исторические данные требуют более развитого индексирования и более прямого доступа, чем интерфейс обработки событий в реальном времени, который предоставляют Event Hubs или Kafka. Подсистемы потоковой передачи событий не подходят для того, чтобы играть роль озер данных или долгосрочных архивов для источника событий.

Политика издателя

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

//<my namespace>.servicebus.windows.net/<event hub name>/publishers/<my publisher name>

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

Захват

Захват центров событий (Event Hubs Capture) позволяет автоматически записывать потоковые данные в Центрах событий и сохранять их в выбранной учетной записи хранилища Blob или учетной записи Azure Data Lake Storage. Вы можете включить запись на портале Azure и указать минимальный размер и период времени для выполнения записи. Используя функцию захвата в центрах событий, вы указываете собственную учетную запись Azure Blob Storage и контейнер, или учетную запись Azure Data Lake Storage, одна из которых используется для хранения данных. Записанные данные записываются в формате Apache Avro.

Файлы, созданные функцией Event Hubs Capture, имеют следующую схему Avro:

Токены SAS

Центры событий используют разделяемые ключи доступа, которые доступны на уровне пространства имен и концентратора событий. Маркер SAS создается из ключа SAS и представляет собой хэш SHA URL-адреса, закодированный в определенном формате. Центры событий могут повторно создать хэш, используя имя ключа (политики) и маркер, и тем самым аутентифицировать отправителя. Как правило, маркеры SAS для издателей событий создаются только с привилегиями отправки в определенном концентраторе событий. Этот механизм URL-адреса маркера SAS является основой идентификации издателя, введенной в политике издателя. Дополнительные сведения о работе с SAS см. в статье "Проверка подлинности подписанного URL-адреса с помощью служебной шины".

Потребители событий

Любая сущность, считывающая данные о событиях из концентратора событий, является потребителем событий. Потребители или получатели используют AMQP или Apache Kafka для получения событий из концентратора событий. Центры событий поддерживают только модель потребления, где потребители сами извлекают события. Даже если обработчики событий используются для обработки событий из концентратора событий, обработчик событий внутренне использует модель извлечения для получения событий из концентратора событий.

Потребительские группы

Механизм публикации и подписки Центров событий включен через группы потребителей. Группа потребителей — это логическая группа потребителей, которые считывают данные из концентратора событий или раздела Kafka. Это позволяет нескольким потребляющим приложениям считывать одни и те же потоковые данные в концентраторе событий независимо друг от друга, на своем собственном темпе, с использованием своих смещений. Он позволяет параллельно использовать сообщения и распределять рабочую нагрузку между несколькими потребителями, сохраняя порядок сообщений в каждой секции.

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

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

Некоторые клиенты, предлагаемые пакетами SDK Azure, — это автоматические агенты-потребители, которые автоматически управляют сведениями о том, чтобы в каждом разделе был только один считыватель и что все разделы концентратора событий считываются. Он позволяет коду сосредоточиться на обработке событий, считываемых из концентратора событий, чтобы игнорировать многие сведения о секциях. Дополнительные сведения см. в разделе "Подключение к секции".

В следующих примерах показано соглашение URI группы потребителей:

//<my namespace>.servicebus.windows.net/<event hub name>/<Consumer Group #1>
//<my namespace>.servicebus.windows.net/<event hub name>/<Consumer Group #2>

На следующем рисунке показана архитектура потоковой обработки центров событий:

Смещения потоков данных

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

Создание контрольных точек

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

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

Следуйте этим рекомендациям при использовании хранилища BLOB-объектов Azure в качестве хранилища контрольных точек:

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

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

• Иерархическое пространство имен
• Обратимое удаление BLOB-объекта
• Управление версиями

сжатие логов

Центры событий Azure поддерживают сжатие журнала событий, чтобы сохранить последние события заданного ключа события. С помощью компактных центров событий или раздела Kafka можно использовать хранение на основе ключей, а не использование грубого хранения на основе времени.

Дополнительные сведения о сжатиях журналов см. в разделе "Сжатие журналов".

Распространенные задачи потребителей

Все потребители Центров событий подключаются через сеанс AMQP 1.0 — двунаправленный канал связи с поддержкой состояния. Каждая секция имеет сеанс AMQP 1.0, который упрощает транспортировку событий, разделенных по секциям.

Подключение к разделу

При подключении к секциям обычно используется механизм аренды для координации подключений читателей к определенным секциям. Таким образом, для каждого раздела в группе потребителей может быть только один активный читатель. Контрольные точки, аренда и управление считывателями упрощаются благодаря использованию клиентов в пакетах SDK Event Hubs, которые действуют как интеллектуальные потребительские агенты. В их число входят:

• EventProcessorClient для .NET
• EventProcessorClient для Java
• EventHubConsumerClient для Python
• EventHubConsumerClient для JavaScript/TypeScript

Читать события

После открытия сеанса AMQP 1.0 и ссылки для определенной секции события передаются клиенту AMQP 1.0 службой Центров событий. Этот механизм доставки обеспечивает более высокую пропускную способность и низкую задержку, чем механизмы на основе извлечения, такие как HTTP GET. При отправке событий на клиент каждый экземпляр данных события содержит важные метаданные, такие как смещение и порядковый номер, которые используются для упрощения процесса создания контрольной точки в последовательности событий.

Данные события:

• Смещение
• Порядковый номер
• Тело
• Свойства пользователя
• Свойства системы

Ваша ответственность — управлять смещением.

Группы приложений

Группа приложений — это коллекция клиентских приложений, которые подключаются к пространству имен Центров событий, которые совместно используют уникальное условие идентификации, например контекст безопасности — политику общего доступа или идентификатор приложения Microsoft Entra.

Центры событий Azure позволяют определять политики доступа к ресурсам, такие как политики регулирования для определенной группы приложений, а также управлять потоковой передачей событий (публикацией или потреблением) между клиентскими приложениями и Центрами событий.

Дополнительные сведения см. в разделе "Управление ресурсами" для клиентских приложений с группами приложений.

Поддержка Apache Kafka

Поддержка протокола для клиентов Apache Kafka (версии >=1.0) предоставляет конечные точки, позволяющие существующим приложениям Kafka использовать центры событий. Большинство существующих приложений Kafka можно перенастроить, чтобы указать s namespace вместо сервера начальной загрузки кластера Kafka.

С точки зрения затрат, операционных усилий и надежности Центры событий Azure — это отличная альтернатива развертыванию и эксплуатации собственных кластеров Kafka и Zookeeper, а также предложения Kafka as-a-Service, не принадлежащих Azure.

Помимо получения той же основной функциональности, что и брокер Apache Kafka, вы также получаете доступ к функциям Центров событий Azure, таким как автоматическая пакетная обработка и архивация с помощью Event Hubs Capture, автоматическое масштабирование и балансировка, аварийное восстановление, поддержка зоны доступности без затрат, гибкая и безопасная сетевая интеграция, а также поддержка нескольких протоколов, включая протокол AMQP-over-WebSockets.

Протоколы

Производители или отправители могут использовать протоколы advanced Messaging Queuing (AMQP), Kafka или HTTPS для отправки событий в концентратор событий.

Потребители или получатели используют AMQP или Kafka для получения событий из концентратора событий. Центры событий поддерживают только модель потребления, где потребители сами извлекают события. Даже если обработчики событий используются для обработки событий из концентратора событий, обработчик событий внутренне использует модель извлечения для получения событий из концентратора событий.

AMQP

Протокол AMQP 1.0 можно использовать для отправки событий и получения событий из Центров событий Azure. AMQP обеспечивает надежную, исполнительную и безопасную связь как для отправки, так и для получения событий. Его можно использовать для высокопроизводительной и потоковой передачи в режиме реального времени и поддерживается большинством пакетов SDK центров событий Azure.

HTTPS/REST API

События можно отправлять только в Центры событий с помощью HTTP-запросов POST. Центры событий не поддерживают получение событий по протоколу HTTPS. Он подходит для упрощенных клиентов, где прямое TCP-подключение невозможно.

Apache Kafka

Центры событий Azure имеют встроенную конечную точку Kafka, которая поддерживает производителей и потребителей Kafka. Приложения, созданные с помощью Kafka, могут использовать протокол Kafka (версия 1.0 или более поздней версии) для отправки и получения событий из Центров событий без каких-либо изменений кода.

Пакеты SDK Azure абстрагируют базовые протоколы связи и предоставляют упрощенный способ отправки и получения событий из Центров событий с помощью таких языков, как C#, Java, Python, JavaScript и т. д.

Дальнейшие шаги

Дополнительные сведения о Центрах событий см. по следующим ссылкам:

• Начало работы с Центрами событий
  • .СЕТЬ
  • Ява
  • Питон
  • JavaScript

• Доступность и согласованность в Центрах событий
• Часто задаваемые вопросы о Центрах событий
• Примеры центров событий