основные понятия пространства имен Сетка событий Azure

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

События

Событие — это наименьший объем информации, который полностью описывает то, что произошло в системе. Мы часто называем событие дискретным событием, так как представляет собой отдельный самостояющийся факт о системе, которая предоставляет аналитические сведения, которые могут быть действенными. Каждое событие имеет общие сведения, такие как source событие, time произошло событие и уникальный идентификатор. Каждое событие также имеет typeуникальный идентификатор, описывающий тип объявления, для которого используется событие.

Например, событие создания файла в службе хранилища Azure содержит сведения о файле, такие как значение lastTimeModified. Событие Центров событий имеет URL-адрес захваченного файла. Событие о новом порядке в микрослужбе Orders может иметь orderId атрибут и атрибут URL-адреса для представления состояния заказа. Ниже приведены несколько примеров типов событий: com.yourcompany.Orders.OrderCreated, org.yourorg.GeneralLedger.AccountChangedio.solutionname.Auth.MaximumNumberOfUserLoginAttemptsReached.

Ниже указан пример события.

{
    "specversion" : "1.0",
    "type" : "com.yourcompany.order.created",
    "source" : "/orders/account/123",
    "subject" : "O-28964",
    "id" : "A234-1234-1234",
    "time" : "2018-04-05T17:31:00Z",
    "comexampleextension1" : "value",
    "comexampleothervalue" : 5,
    "datacontenttype" : "application/json",
    "data" : {
       "orderId" : "O-28964",
       "URL" : "https://com.yourcompany/orders/O-28964"
    }
}

Другой вид события

Сообщество пользователей также называется "событиями" сообщений, которые несут точку данных, например одно устройство чтения или щелчка на странице веб-приложения. Этот вид события обычно анализируется в течение периода времени для получения аналитических сведений и принятия действий. В документации сетки событий мы называем это событие точкой данных, потоковой передачей данных или телеметрией. Среди других типов сообщений этот тип событий используется с функцией брокера передачи сообщений телеметрии (MQTT) сетки событий.

Источники облачных

Разделы пространства имен сетки событий принимают события, которые соответствуют открытой спецификации CloudEvents 1.0 с использованием привязки протокола HTTP с форматом JSON. CloudEvent — это своего рода сообщение, содержащее обмен данными, называемые данными о событиях и метаданными об этом. Данные событий в архитектуре, управляемой событиями, обычно содержат сведения об изменении состояния системы. Метаданные CloudEvents состоят из набора атрибутов, которые предоставляют контекстные сведения о сообщении, например о том, где она возникла (исходная система), тип и т. д. Все допустимые сообщения, которые относятся к спецификациям CloudEvents, должны содержать следующие обязательные атрибуты контекста:

Спецификация CloudEvents также определяет необязательные атрибутыконтекста расширения, которые можно включить при использовании сетки событий.

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

CloudEvents con режим палатки s

Спецификация CloudEvents определяет три кон режим палатки: двоичные, структурированные и пакетные.

Внимание

С помощью любого con режим палатки вы можете обмениваться текстом (JSON, text/*и т. д.) или двоичными данными событий. Двоичное con режим палатки не используется исключительно для отправки двоичных данных.

Кон режим палатки не о кодировке, используемой, двоичной или текстовой, а о том, как данные события и его метаданные описываются и обмениваются ими. Структурированный con режим палатки использует одну структуру, например объект JSON, где атрибуты контекста и данные события объединяются в полезные данные HTTP. Двоичный кон режим палатки разделяет атрибуты контекста, которые сопоставляются с заголовками HTTP и данными событий, которые являются полезными данными HTTP, закодированными в соответствии с заданным типом Content-Typeносителя.

Поддержка CloudEvents

В этой таблице показана текущая поддержка спецификации CloudEvents:

CloudEvents con режим палатки Поддерживается?
Структурированный JSON Да
Структурированный пакет JSON Да, для публикации событий
Binary Да, для публикации событий

Максимально допустимый размер события — 1 МБ. Плата за события свыше 64 КБ начисляется с приращением в 64 КБ.

Структурированный con режим палатки

Сообщение в CloudEvents структурированное con режим палатки содержит как атрибуты контекста, так и данные события вместе в полезных данных HTTP.

Внимание

В настоящее время Служба "Сетка событий" поддерживает формат JSON CloudEvents с протоколом HTTP.

Ниже приведен пример CloudEvents в структурированном режиме с использованием формата JSON. Оба метаданных (все атрибуты, которые не являются "данными") и данные сообщения или события (объект data) описываются с помощью JSON. Наш пример включает все обязательные атрибуты контекста, а также некоторые необязательные атрибуты (subject, timeи datacontenttype) и атрибуты расширения (comexampleextension1, comexampleothervalue).

{
    "specversion" : "1.0",
    "type" : "com.yourcompany.order.created",
    "source" : "/orders/account/123",
    "subject" : "O-28964",
    "id" : "A234-1234-1234",
    "time" : "2018-04-05T17:31:00Z",
    "comexampleextension1" : "value",
    "comexampleothervalue" : 5,
    "datacontenttype" : "application/json",
    "data" : {
       "orderId" : "O-28964",
       "URL" : "https://com.yourcompany/orders/O-28964"
    }
}

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

  1. Включите атрибут с типом datacontenttype носителя, в котором кодируются данные.
  2. Если тип носителя закодирован в текстовом формате, например text/plain, text/csvили application/xml, следует использовать data атрибут со строкой JSON, содержащей то, что вы взаимодействуете в качестве значения.
  3. Если тип носителя представляет двоичную кодировку, следует использовать data_base64 атрибут, значение которого — строка JSON, содержащая двоичное значение в кодировке BASE64 .

Например, этот CloudEvent содержит данные событий, закодированные для application/protobuf обмена сообщениями Protobuf.

{
    "specversion" : "1.0",
    "type" : "com.yourcompany.order.created",
    "source" : "/orders/account/123",
    "id" : "A234-1234-1234",
    "time" : "2018-04-05T17:31:00Z",
    "datacontenttype" : "application/protobuf",
    "data_base64" : "VGhpcyBpcyBub3QgZW5jb2RlZCBpbiBwcm90b2J1ZmYgYnV0IGZvciBpbGx1c3RyYXRpb24gcHVycG9zZXMsIGltYWdpbmUgdGhhdCBpdCBpcyA6KQ=="
}

Дополнительные сведения об использовании data или data_base64 атрибутах см. в разделе "Обработка данных ".

Дополнительные сведения об этом con режим палатки см. в спецификациях cloudEvents HTTP, структурированных con режим палатки.

Пакетный кон режим палатки

Сетка событий в настоящее время поддерживает пакетный конус JSON режим палатки при публикации CloudEvents в Сетку событий. Этот con режим палатки использует массив JSON, заполненный CloudEvents в структурированном con режим палатки. Например, приложение может публиковать два события с помощью массива, как показано ниже. Аналогичным образом, если вы используете пакет SDK плоскости данных сетки событий, эта полезные данные также отправляются:

[
    {
        "specversion": "1.0",
        "id": "E921-1234-1235",
        "source": "/mycontext",
        "type": "com.example.someeventtype",
        "time": "2018-04-05T17:31:00Z",
        "data": "some data"
    },
    {
        "specversion": "1.0",
        "id": "F555-1234-1235",
        "source": "/mycontext",
        "type": "com.example.someeventtype",
        "time": "2018-04-05T17:31:00Z",
        "data": {
            "somekey" : "value",
            "someOtherKey" : 9
        }
    }
]

Дополнительные сведения см. в спецификациях режима пакетного содержимого CloudEvents.

Пакетная обработка

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

Двоичное con режим палатки

CloudEvent в двоичном con режим палатки имеет атрибуты контекста, описанные как заголовки HTTP. Имена заголовков HTTP — это имя атрибута контекста, префиксированного с ce-помощью. Заголовок Content-Type отражает тип носителя, в котором кодируются данные события.

Внимание

При использовании двоичного конуса режим палатки ce-datacontenttype заголовок HTTP не должен присутствовать.

Внимание

Если вы планируете включить собственные атрибуты (т. е. атрибуты расширения) при использовании двоичного конуса режим палатки убедитесь, что их имена состоят из строчные буквы ("a" до z) или цифры ("0" до "9") из символа ASCII и что они не превышают 20 символов в длину. То есть соглашение об именовании атрибутов контекста CloudEvents является более строгим, чем для допустимых имен заголовков HTTP. Недопустимое имя заголовка HTTP является допустимым именем атрибута расширения.

Полезные данные HTTP — это данные события, закодированные в соответствии с типом носителя.Content-Type

HTTP-запрос, используемый для публикации CloudEvent в двоичном режиме содержимого, может выглядеть следующим образом:

POST / HTTP/1.1
HOST mynamespace.eastus-1.eventgrid.azure.net/topics/mytopic
ce-specversion: 1.0
ce-type: com.example.someevent
ce-source: /mycontext
ce-id: A234-1234-1234
ce-time: 2018-04-05T17:31:00Z
ce-comexampleextension1: value
ce-comexampleothervalue: 5
content-type: application/protobuf

Binary data according to protobuf encoding format. No context attributes are included.

Когда следует использовать двоичный или структурированный con режим палатки

Вы можете использовать структурированный con режим палатки если вы хотите простой подход к пересылке CloudEvents между прыжками и протоколами. Так как CloudEvent в структурированном con режим палатки содержит сообщение вместе со своими метаданными, клиенты легко использовать его в целом и пересылать его в другие системы.

Вы можете использовать двоичный con режим палатки если известно, что подчиненные приложения требуют только сообщения без дополнительных сведений (т. е. атрибутов контекста). Хотя с структурированным con режим палатки вы по-прежнему можете получить данные события (сообщение) из CloudEvent, проще, если приложение-потребитель просто имеет его в полезных данных HTTP. Например, другие приложения могут использовать другие протоколы и могут быть заинтересованы только в основном сообщении, а не его метаданных. На самом деле метаданные могут быть релевантными только для немедленного первого прыжка. В этом случае наличие данных, которые требуется обменять, помимо метаданных, упрощает обработку и пересылку.

Издатели

Издатель — это приложение, которое отправляет события в сетку событий. Это может быть то же приложение, где произошли события, источник событий. При использовании разделов пространства имен можно публиковать события из собственного приложения.

Источники событий

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

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

Пространство имен Сетки событий — это контейнер управления для следующих ресурсов:

Ресурс Поддерживаемый протокол
Разделы пространства имен HTTP
Пространства разделов MQTT
Клиенты MQTT
Группы клиентов MQTT
Сертификаты ЦС MQTT
Привязки разрешений MQTT

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

Пространство имен предоставляет две конечные точки:

  • Конечная точка HTTP для поддержки общих требований к обмену сообщениями с помощью разделов пространства имен.
  • Конечная точка MQTT для обмена сообщениями Интернета вещей или решений, использующих MQTT.

Пространство имен также предоставляет конечные точки сети, интегрированные с DNS. Он также предоставляет ряд функций управления доступом и управления сетевой интеграцией, таких как фильтрация общедоступных IP-адресов и частные каналы. Это также контейнер управляемых удостоверений, используемых для содержащихся ресурсов в пространстве имен.

Ниже приведены несколько дополнительных моментов о пространствах имен:

  • Пространство имен — это отслеживаемый ресурс с tags свойствами и location свойствами, и его можно найти в resources.azure.com.
  • Имя пространства имен может иметь длину 3–50 символов. Он может включать буквенно-цифровые и дефис(-), а также пробелы.
  • Имя должно быть уникальным для каждого региона.
  • Текущие поддерживаемые регионы: центральная часть США, Восточная Азия, восточная часть США, восточная часть США 2, Северная Европа, центральная часть США, Юго-Восточная Азия, Северная Азия ОАЭ, Западная Европа, Западная часть США 2, Западная часть США 3.

Единицы пропускной способности

Единицы пропускной способности (TUS) определяют емкость частоты событий входящего трафика и исходящего трафика в пространствах имен. Дополнительные сведения см. в разделе Сетка событий Azure квоты и ограничения.

Разделы

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

Разделы пространства имен

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

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

Подписки на события

Подписка на события — это ресурс конфигурации, связанный с одним разделом. Помимо прочего, вы используете подписку на события, чтобы задать критерии выбора событий, чтобы определить коллекцию событий, доступную подписчику из общего набора событий, доступных в разделе. События можно фильтровать в соответствии с требованиями подписчика. Например, можно фильтровать события по типу события. Можно также определить критерии фильтра для свойств данных события, если в качестве значения свойства данных используется объект JSON. Дополнительные сведения о свойствах ресурсов см. в REST API сетки событий.

Схема, показывающая раздел и связанные подписки на события.

Пример создания подписок для разделов пространства имен см. в статье "Публикация и использование сообщений с помощью тем пространства имен" с помощью ИНТЕРФЕЙСА командной строки.

Примечание.

Подписки на события в разделе пространства имен предоставляют упрощенную модель ресурсов по сравнению с той, которая используется для пользовательских, доменных, партнерских и системных разделов (Базовая сетка событий). Дополнительные сведения см. в статье "Создание, просмотр и управление подписками на события".

Доставка по запросу

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

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

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

При доставке событий с помощью доставки по запросу сетка событий включает массив объектов, которые, в свою очередь, включают объекты event и brokerProperties . Значение свойства события — CloudEvent, доставленное в структурированное con режим палатки. Объект brokerProperties содержит маркер блокировки, связанный с доставленным CloudEvent. Следующий объект JSON представляет собой пример ответа от операции получения , возвращающей два события:

{
    "value": [
        {
            "brokerProperties": {
                "lockToken": "CiYKJDUwNjE4QTFFLUNDODQtNDZBQy1BN0Y4LUE5QkE3NjEwNzQxMxISChDXYS23Z+5Hq754VqQjxywE",
                "deliveryCount": 2
            },
            "event": {
                "specversion": "1.0",
                "id": "A234-1234-1235",
                "source": "/mycontext",
                "time": "2018-04-05T17:31:00Z",
                "type": "com.example.someeventtype",
                "data": "some data"
            }
        },
        {
            "brokerProperties": {
                "lockToken": "CiYKJDUwNjE4QTFFLUNDODQtNDZBQy1BN0Y4LUE5QkE3NjEwNzQxMxISChDLeaL+nRJLNq3/5NXd/T0b",
                "deliveryCount": 1
            },
            "event": {
                "specversion": "1.0",
                "id": "B688-1234-1235",
                "source": "/mycontext",
                "type": "com.example.someeventtype",
                "time": "2018-04-05T17:31:00Z",
                "data": {
                    "somekey" : "value",
                    "someOtherKey" : 9
                }
            }
        }
    ]
}

Отправка отправки

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

Внимание

Доставка push-уведомлений пространств имен сетки событий в настоящее время поддерживает Центры событий Azure в качестве назначения. В будущем пространства имен Сетки событий будут поддерживать больше назначений, включая все назначения, поддерживаемые Сеткой событий Basic.

Доставка событий Центров событий

Служба "Сетка событий" использует пакет SDK центров событий для отправки событий в Центры событий с помощью AMQP. События отправляются в виде массива байтов с каждым элементом в массиве, содержащим CloudEvent.

Отправка и отправка по запросу

Служба "Сетка событий" поддерживает доставку событий отправки и извлечения с помощью HTTP. При принудительной доставке вы определяете назначение в подписке на события, веб-перехватчик или службу Azure, в которую сетка событий отправляет события. При доставке по запросу приложения подписчиков подключаются к сетке событий для использования событий. Доставка по запросу поддерживается для разделов в пространстве имен Сетки событий.

Внимание

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

Схема высокого уровня, показывающая доставку push-уведомлений и доставку по запросу с типом задействованных ресурсов.

Когда следует использовать доставку push-уведомлений и доставку по запросу

Ниже приведены общие рекомендации, которые помогут вам решить, когда следует использовать доставку по запросу или отправке.

Доставка по запросу

  • Вам нужен полный контроль о том, когда будут получать события. Например, приложение может не находиться в течение всего времени, недостаточно стабильно или обрабатывать данные в определенное время.
  • Вам нужен полный контроль над потреблением событий. Например, нижестоящей службы или слоя в приложении-получателе возникает проблема, которая предотвращает обработку событий. В этом случае API доставки по запросу позволяет приложению-потребителю освободить уже прочитанное событие обратно брокеру, чтобы его можно было доставить позже.
  • Вы хотите использовать частные ссылки при получении событий, что возможно только при доставке по запросу, а не при отправке push-уведомлений.
  • У вас нет возможности предоставлять конечную точку и использовать отправку push-уведомлений, но вы можете подключиться к сетке событий для использования событий.

Отправка отправки

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

Следующие шаги