Что вы можете делать, когда группируете свои мероприятия

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

Вот несколько примеров событий.

  • Статус продукта X изменен
  • Платеж Y авторизован
  • Клиент C разместил заказ
  • На счет A зачислено 100 фунтов стерлингов

Типичное приложение может генерировать множество событий во время своей работы.

Состав мероприятия

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

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

Вот пример события, информирующего о подаче заказа.

{
  "id": "0c90d427-c90bb8ae53fd",
  "detail-type": "event",
  "source": "service-checkout",
  "time": "2019-12-17T10:29:48Z",
  "detail": {
      "type": "ORDER",
      "status": "SUBMITTED",
      "orderNumber": "T123123123"
    }
  }
}

Классификация событий

События можно классифицировать и сгруппировать по-разному. Общая классификация основана на домене. События, принадлежащие определенному домену, имеют подкатегории, относящиеся к этому домену. Например, события, принадлежащие домену «Сотрудник», могут иметь категории, связанные с личными данными, обучением, счетами, отделом и т. Д. И т. Д.

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

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

Критические события

Критическое событие - это событие, требующее немедленных действий. Точно так же событие, которое содержит важные данные и, следовательно, не может быть потеряно, также является критическим событием.

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

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

Некритические события

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

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

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

Amazon EventBridge

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

Это часто называют узором «ступица и спица», как показано ниже.

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

Гибкая структура мероприятий

В EventBridge событие - это простой документ JSON. На верхнем уровне есть несколько обязательных атрибутов и раздел detail для добавления пользовательских данных, как объясняется в документации AWS.

{
  "id": "0c90d427-c90bb8ae53fd",
  "detail-type": "event",
  "source": "email-registration",
  "time": "2019-12-17T10:29:48Z",
  "detail": {
    "metadata": {
      "domain": "LEGO-SHOP",
      "service": "email-registration",
      "type": "REGISTRATION_REQUEST",
      "status": "REQUEST"
    },
    "data": {
      "requestId": "unique_request_id",
      "email": "[email protected]",
      "product": "987654",
      "notificationType": "SOLD_OUT"
    }
  }
}

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

Одно событие, два значения

Важно понимать, что событие, которое мы отправляем и получаем, не совсем то, как оно отображается внутри AWS.

В то время как наши приложения рассматривают событие как единый объект данных, для биллинга EventBridge AWS учитывает событие как установленный объем блока данных.

Событие - в контексте данных

Событие данных - это то, что мы обсуждали в этом блоге. Для события приложения максимальный размер 256 КБ позволяет упаковать разумный объем данных. Однако в большинстве случаев события меньше, чем размер КБ.

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

Событие - в контексте биллинга

событие биллинга - это мой термин, обозначающий то, что AWS внутренне считает событием для ценообразования и выставления счетов.

Как показано выше, для расчета цены каждый блок данных размером 64 КБ считается одним событием. Например, событие данных размером 256 КБ - это четыре события биллинга.

  • 64 КБ данных = 1 событие биллинга
  • Событие данных 100 КБ = 2 события биллинга

Пакетное событие

Проще говоря, пакетное событие - это одно событие EventBridge, которое переносит несколько бизнес-событий, другими словами, пакет бизнес-событий в одном событии EventBridge!

Почему?

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

Пример использования

Amazon Simple Email Service (SES) в качестве службы отправки электронной почты можно настроить для получения различных типов обратной связи для отправляемых вами электронных писем. Если вы отправляете большой объем электронных писем с этой конфигурацией, вы можете рассчитывать на получение большого количества событий обратной связи.

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

Вот урезанная версия события обратной связи SES типа Send.

{
  "eventType": "Send",
  "mail": {
    "timestamp": "2020-10-23T13:10:09.270Z",
    "source": "[email protected]",
    "sendingAccountId": "1234567",
    "messageId": "010701755594b076",
    "destination": [
      "[email protected]"
    ],
    "headersTruncated": false,
    "headers": [
      {
        "name": "From",
        "value": "[email protected]"
      },
      {
        "name": "To",
        "value": "[email protected]"
      }
    ],
    "tags": {
      "country": [
        "GB"
      ],
      "ses:configuration-set": [
        "email-notifications"
      ],
      "ses:from-domain": [
        "sample.domian.com"
      ],
      "notificationType": [
        "BACKORDER"
      ],
      "sku": [
        "987654"
      ]
    }
  },
  "send": {}
}

Если эти события обратной связи SES поступают через Amazon Kinesis DataFirehose, это позволяет нам обрабатывать эти события SES пакетами. Обработка может очищать события SES, удаляя ненужные данные, группируя их по типу и другим параметрам, переупаковывая и отправляя их как события EventBridge, как показано на диаграмме ниже.

Пример пакетного события

Ниже показан образец пакетного события EventBridge, содержащего два события обратной связи. Раздел metadata содержит общие атрибуты, такие как feedbackType и emailType, , тогда как раздел данных содержит массив обрезанных событий SES.

{
  "id": "0c90d427-c90bb8ae53fd",
  "detail-type": "event",
  "source": "email-feedback-processor",
  "time": "2019-12-17T10:29:48Z",
  "detail": {
    "metadata": {
      "domain": "LEGO-SHOP",
      "service": "email-feedback-processor",
      "feedbackType": "Send",
      "emailType": "BACKORDER"
    },
    "data": [
      {
        "timestamp": "2020-10-23T13:10:09.270Z",
        "messageId": "010701755594b076",
        "email": "[email protected]",
        "country": "GB",
        "sku": "987654"
      },
      {
        "timestamp": "2020-10-23T13:10:08.280Z",
        "messageId": "010701755594b098",
        "email": "[email protected]",
        "country": "US",
        "sku": "123456"
      }
    ]
  }
}

Преимущества

Это зависит! Это не универсальное решение, оно предназначено для конкретных случаев использования. Вот несколько преимуществ.

  • Уменьшает шум событий. Как и в приведенном выше варианте использования, этот подход уменьшает объем событий, переполняющих EventBridge. Для отправки настраиваемых событий с помощью API-интерфейсов EventBridge предусмотрены квоты и ограничения, подробно описанные в документации AWS.
  • Снижает нагрузку на потребителей событий. В случае лямбда-функций в качестве потребителей событий это уменьшило бы количество одновременных выполнений, тем самым не съедая без надобности параллелизм учетной записи.
  • Снижает стоимость. Поскольку события измеряются в блоках данных размером 64 КБ для выставления счетов, пакетирование событий может снизить общую стоимость.
  • Уменьшает доступ к данным. Организации критически относятся к защите данных и конфиденциальности данных. Снижение видимости непреднамеренных данных помогает частично снять эти опасения.

Лучшие практики

  • Знайте предельный размер полезной нагрузки события. Никогда не собирайте слишком много вещей на одном мероприятии.
  • Избегайте смешивания элементов данных разных типов в одном пакете. Это поможет упростить настройку правил фильтрации и маршрутизации.
  • Подумайте о потенциальных целях события. Знайте свои ограничения на размер данных. Не все потребители соответствуют размеру полезной нагрузки события EventBridge.
  • Понять значимость событий и требования к их обработке. Если сомневаетесь, не производите пачку.

Заключение

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

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