Доставка по запросу с помощью HTTP

В этой статье используются материалы статей "Общие сведения о Сетка событий Azure " и статья концепции для предоставления важной информации перед началом использования доставок Event Grid по протоколу HTTP. В ней рассматриваются основные понятия, модели ресурсов и поддерживаемые режимы доставки сообщений. В конце этого документа вы найдете полезные ссылки на статьи, которые помогут вам использовать сетку событий и статьи, которые предлагают подробные концептуальные сведения.

Примечание.

Этот документ помогает приступить к работе с возможностями сетки событий, которые используют протокол HTTP. Эта статья подходит для пользователей, которым требуется интегрировать приложения в облако. Если вам нужно обмениваться данными IoT-устройства, см. Обзор функции брокера MQTT в Сетка событий Azure.

CloudEvents

Разделы пространства имен сетки событий принимают события, соответствующие открытой спецификации CloudEvents 1.0 с помощью привязки протокола HTTP с форматом JSON.

Дополнительные сведения см. в разделе "Поддержка CloudEvents".

Режимы содержания CloudEvents

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

Внимание

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

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

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

Сообщения и события

CloudEvent обычно содержит данные о событии, которые сообщают о происшествии в системе, то есть об изменении состояния системы. Однако при использовании CloudEvents можно передавать любые данные. Например, можно использовать формат обмена CloudEvents для отправки командного сообщения для запроса действия в подчиненное приложение. Еще одним примером является маршрутизация сообщений с брокера MQTT Event Grid в тему. В этом сценарии вы направляете сообщение MQTT, завернутое в конверт CloudEvents.

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

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

Поставка по запросу обеспечивает следующие преимущества потребления событий:

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

  • Потребляйте события в удобное для вас время. Например, учитывая бизнес-требования, обработать сообщения ночью.

  • Потребляйте события через частную ссылку, чтобы данные использовали частное IP-пространство.

Примечание.

  • Пространства имен предоставляют более простую модель ресурсов с одним типом раздела. В настоящее время Служба "Сетка событий" поддерживает публикацию собственных событий приложения с помощью разделов пространства имен. Вы не можете получать события из служб Azure или партнерских систем SaaS, используя топики пространства имен. Вы также не можете создавать системные разделы, разделы домена или партнерские разделы в пространстве имен.
  • Темы пространства имен поддерживают формат CloudEvents JSON.

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

При получении событий или использовании операций, которые управляют состоянием события, приложение указывает конечную точку пространства имен HTTP, имя раздела и имя подписки на событие очереди . Значение deliveryMode для подписки на событие очереди установлено в *queue*. Подписки на события в очереди используются для обработки событий с помощью API доставки по запросу. Дополнительные сведения о создании этих ресурсов см. в статье о создании пространств имен, разделов и подписок на события.

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

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

Операции доставки по требованию

Приложение использует следующие операции при работе с доставкой по запросу.

  • Операция получения считывает одно или несколько событий с помощью одного запроса в Сетку событий. По умолчанию брокер ожидает до 60 секунд, пока события будут доступны. Например, события становятся доступными для доставки, когда они впервые опубликованы. Успешный запрос на получение данных возвращает ноль или больше событий. Если события доступны, он возвращает максимально возможное количество доступных событий до запрошенного количества событий. "Event Grid" также возвращает токен блокировки для каждого прочитанного события.
  • Маркер блокировки — это своего рода дескриптор, определяющий событие, которое можно использовать для управления его состоянием.
  • Когда приложение-получатель получает событие и обрабатывает его, оно признает это событие. Эта операция инструктирует Event Grid удалить событие, чтобы оно не было доставлено другому клиенту повторно. Пользовательское приложение подтверждает один или несколько токенов с одним запросом, указав их токены блокировки до истечения срока действия.

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

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

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

Область, на которой выполняются операции доставки по принципу pull

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

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

При доставке событий с помощью доставки по запросу сетка событий включает массив объектов, которые, в свою очередь, включают объекты события и brokerProperties . Значение свойства события: CloudEvent, доставляемое в режиме структурированного контента. Объект 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 и доставка по запросу

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

Внимание

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

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

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

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

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

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

Пуш-уведомление

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

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

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