Создание событийно-ориентированных решений на AWS
Производство, обнаружение, асинхронная и реактивная обработка событий
В основе разработки приложения для обработки событий должны лежать следующие соображения:
Разделение: необходимо разделить производителя и потребителя события.
Асинхронный - система в процессе обработки событий должна быть неблокирующей (асинхронной).
Обратный вызов - событие должно содержать URL-адрес обратного вызова / конечную точку для подтверждения обработки события.
На приведенной ниже диаграмме показаны варианты обработки событий, доступные в AWS, и то, как мы можем использовать их для создания хороших приложений, управляемых событиями.
Обсудим компоненты и их назначение:
Event Producer - система, в которой происходят изменения. Это может быть сервис AWS или стороннее приложение.
Событие - значительное изменение состояния. Примером может служить инициация адаптации сотрудника. Или файл, загруженный в корзину S3, или запись, измененная в таблице DynamoDb.
Проверка схемы событий. События должны иметь согласованный формат, чтобы избежать двусмысленности и убедиться, что потребитель может извлечь все данные, необходимые для обработки событий. Поскольку мы хотим, чтобы наши компоненты были разделены, нам нужен контракт схемы событий между производителем и потребителем. Для простоты я делегировал эту задачу сервису вроде EventBridge. Это может быть реализовано как отдельный компонент, где у нас есть реестр схемы событий, и потребитель обращается к реестру для анализа события.
Фильтрация событий - выберите только те события, которые необходимы, а не все события для обработки. Это можно сделать путем проверки схемы и отбрасывания всех искаженных событий. Или у нас могут быть собственные правила, которые решают, какое событие разрешить. Для фильтрации или перенаправления событий мы можем использовать правило моста событий, правило события облачного наблюдения или правила Интернета вещей.
Выбор места назначения события. Различные события будут иметь разные наборы требований с точки зрения хранения, воспроизведения, трансляции и т. д. В зависимости от этих атрибутов необходимо выбрать правильное хранилище, например Event Bridge позволяет нам воспроизводить события, а SQS не позволяет. В то время как Kinesis позволит анализировать события в реальном времени и может сохранять события в S3. SNS позволяет транслировать события.
Потребитель события - компоненты, которые будут обрабатывать событие. Они должны уметь масштабироваться. Для событий, которые можно быстро обработать, подойдет лямбда. Он также может быстро масштабироваться. Для модификации сервисов AWS мы можем использовать SSM (автоматизация и запуск документа). Если событие запускает рабочий процесс, мы можем использовать пошаговую функцию. Пошаговая функция позволяет нам обрабатывать события с помощью различного диапазона AWS и наших собственных приложений.
Две оранжевые пунктирные стрелки показывают, что событие может быть напрямую отправлено на разные уровни для обработки. Кроме того, черная пунктирная линия внизу изображает вариант обратного вызова для уведомления системы-производителя о том, что событие было обработано.
Один важный аспект, который я не добавил к диаграмме, - это механизм повтора. Это зависит от того, выдержит ли ваше мероприятие провал или нет. Но хорошей практикой является наличие компонента для размещения неудачных / недоставленных событий. EventBridge позволяет нам использовать SQS DLQ & retry policy. Очереди SQS могут быть настроены с другой очередью в качестве DLQ для недоставленных сообщений. Lambda также разрешает DLQ для событий, которые не удалось обработать. Лямбда, если вызывается асинхронно, автоматически повторит попытку, прежде чем пометить обработку события как неудачную.
В этом блоге мы рассмотрели доступные в AWS сервисы, которые можно использовать для создания различных типов событийных приложений.
Больше контента на plainenglish.io
