Обработка событий в асинхронной коммуникации

Оригинал статьи: ссылка (Roberto Iturralde, Solutions Architect)

В первом посте этой серии, мы рассмотрели обмен сообщениями, а также плюсы и минусы синхронной и асинхронной коммуникации сервисов. В этом посте мы посмотрим на общие критерии, которые стоит принять во внимание при выборе технологии обмена сообщениями. Мы также познакомимся с Amazon EventBridge, serverless шиной событий от AWS.

Что такое событие?

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

Ниже приведен пример события в AWS. События создаются сервисами AWS и представляют собой JSON-объекты. Все поля метаданных на верхнем уровне, представленные в примере ниже, являются обязательными. Кроме того, событие содержит дополнительные сведения, специфичные для сервиса-отправителя, в поле «detail».

Пример события в AWS

{
  "version": "0",
  "id": "6a7e8feb-b491-4cf7-a9f1-bf3703467718",
  "detail-type": "EC2 Instance State-change Notification",
  "source": "aws.ec2",
  "account": "111122223333",
  "time": "2017-12-22T18:43:48Z",
  "region": "us-west-1",
  "resources": [
    "arn:aws:ec2:us-west-1:123456789012:instance/ i-1234567890abcdef0"
  ],
  "detail": {
    "instance-id": " i-1234567890abcdef0",
    "state": "terminated"
  }
}

Схемы событий

Рассматривая пример выше, а также документацию по событиям в AWS, вы можете заметить, что существует как схема полей на верхнем уровне для всех событий, так и отдельные схемы для специфичных атрибутов сервисов-отправителей в поле «detail». Причина этому в том, что разные сервисы AWS создают события в шине сообщений по-умолчанию в Amazon EventBridge. В отличие от различных HTTP API, которые часто имеют опубликованную схему и проверяют запросы на соотвествие этой схеме, транспортные каналы событий обычно разрешают прохождение разнородных событий через единый канал, как, например, шина событий по-умолчанию в EventBridge.

Чтобы упростить определение, обнаружение и разработку на основе схем событий, в Amazon EventBridge присутствует реестр схем (Schema Registry). Реестр предзаполняется схемами в формате OpenAPI для существующих сервисов AWS, а также позволяет вам задавать свои схемы. Кроме того, в нем можно скачать примеры кода на популярных языках программирования с классами для объектов, определенных в схемах реестра.

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

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

Порядок: есть ли гарантия доставки событий в том же порядке, в каком они были отправлены?
Дупликация: могут ли появиться дубликаты событий? Будет ли происходить дедупликация событий?
Копии данных: может ли каждое событие быть доставлено или обработано несколькими получателями?
Push или pull: посылаются ли события получателям или они должны сами извлекать их?
Фильтрация: могут ли получатели задавать правила фильтрации для ограничения событий, которые будут приходить к ним через канал?
Serverless: должна ли инфраструктура сервиса управляться и настраиваться владельцем канала?

Amazon EventBridge

Приложение с использованием Amazon EventBridge

Amazon EventBridge – это serverless шина данных, предоставляемая как управляемый сервис (managed service). Отправителями могут быть сервисы AWS, поддерживаемые Software as a Service (SaaS) партнеры, а также ваши собственные приложения, которые могут писать JSON-сообщения в шину событий EventBridge. Сообщения доставляются получателям, которые настраиваются как цели для правил сообщений. Правила могут фильтровать сообщения на основе атрибутов в данных JSON, при этом одно правило может отправлять события нескольким целям. Правила повторяют попытку доставки событий к настроенным целям с использованием экспоненциального алгоритма отсрочки (exponential backoff) в течение 24 часов. EventBridge не гарантирует порядок доставки событий, а сама доставка совершается как минимум один раз, что означает возможность появления дубликатов событий. Рассматривайте EventBridge для кейсов, где необходима функциональность фильтрации событий, копирование событий десяткам получателей, доставка или получение сообщений в различные учетные записи AWS, или когда есть необходимость получать события от большого количества сервисов AWS или сообщения от партнерских SaaS-систем.

Заключение

В этом посте мы определили, что такое события, и определили критерии, которые стоит учитывать при выборе технологии транспортировки событий. Мы также кратко рассмотрели Amazon EventBridge в соответствии с этими критериями. Для более глубокого обсуждения технологий обмена событиями, я рекомендую посмотреть запись сессии Moving to Event-Driven Architectures, которую провел Tim Bray, AWS Distinguished Engineer, на AWS re:Invent 2019. Для более глубокого погружения в Amazon EventBridge, посмотрите этот AWS Tech Talk. Для примера интеграции Amazon EventBridge в serverless-архитектуру, почитайте этот пост, в котором рассматривается пример такого приложения.

Блог Amazon Web Services