Как реализовать архитектуру событий с помощью облачных платформ, таких как AWS и Azure

Понимание событийной архитектуры

Event Driven Architecture (EDA) - это современная парадигма проектирования программного обеспечения, в которой системные компоненты взаимодействуют путем производства, обнаружения и потребления событий. Событие представляет собой значительное изменение состояния - например, регистрация пользователя, размещение заказа или считывание датчика, пересекающее порог. В отличие от традиционных шаблонов ответа на запрос, EDA отделяет производителей событий от потребителей, позволяя асинхронную связь, которая масштабируется горизонтально и реагирует в режиме реального времени. Облачные платформы, такие как AWS и Azure, предоставляют управляемые услуги, которые абстрагируются от базовой инфраструктуры, что облегчает внедрение надежных систем, управляемых событиями.

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

Внедрение EDA в AWS

AWS предлагает полный набор событийных сервисов, которые легко интегрируются друг с другом и с внешними системами. Основными строительными блоками являются Amazon EventBridge, AWS Lambda, Amazon SNS и Amazon SQS. Понимание того, как эти сервисы работают вместе, имеет важное значение для построения масштабируемых, разъединенных архитектур.

Amazon EventBridge: Центральный автобус

Amazon EventBridge действует как нервная система вашего приложения, управляемого событиями. Он проглатывает события из ваших собственных приложений, сторонних поставщиков SaaS и других сервисов AWS, затем направляет их к таким целям, как функции Lambda, очереди SQS, темы SNS или даже конечные точки API Gateway. EventBridge поддерживает как пользовательские события (с использованием определенной схемы событий), так и обнаружение схемы, которое автоматически захватывает структуру входящих событий. Вы также можете определить правила фильтрации событий и трансформации, уменьшая необходимость в логике обработки вниз по течению.

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

AWS Lambda: Бессерверные устройства для обработки событий

AWS Lambda является предпочтительной вычислительной мишенью для событийных рабочих процессов. Он выполняет код в ответ на события из EventBridge, SNS, SQS или многих других источников. Функции Lambda не имеют состояния и автоматически масштабируются от нуля до тысяч одновременных исполнений на основе объема событий. Это делает их идеальными для обработки потоков событий, таких как загрузка файлов, изменения базы данных или аналитика в реальном времени.

При интеграции Lambda с EventBridge можно использовать входные трансформаторы для формирования полезной нагрузки события до того, как оно достигнет функции, уменьшая бойлерплейт. Для устойчивости настройте Lambda с очередей мертвой буквы (DLQ) для захвата событий, которые выходят из строя после всех попыток повторного использования. Кроме того, пункты назначения Lambda могут маршрутизировать успешные или неудачные вызовы последующим обработчикам событий, позволяя оркестровку, управляемую событием.

Amazon SNS и SQS: Pub/Sub и очереди

В то время как EventBridge предоставляет более богатый набор возможностей маршрутизации и фильтрации, Amazon SNS (Simple Notification Service) и Amazon SQS (Simple Queue Service) остаются основополагающими для многих событийных шаблонов. SNS реализует модель публикации-подписки: издатель отправляет сообщение на тему и тема вентиляторами его для всех подписанных конечных точек (например, очереди SQS, функции Lambda, конечные точки HTTP). SQS предлагает надежную распределенную очередь сообщений с такими функциями, как дедупликация сообщений, заказ FIFO и настраиваемые тайм-ауты видимости.

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

Архитектура в AWS

Рассмотрим систему обнаружения мошенничества в реальном времени. Клиентские транзакции регистрируются в таблице Amazon DynamoDB. Событие DynamoDB Streams запускает функцию Lambda, которая публикует событие в EventBridge. EventBridge фильтрует высокоценные транзакции и направляет их к выделенной функции обнаружения мошенничества Lambda, а также к очереди SQS для анализа партии. Функция обнаружения мошенничества записывает подозрительные маркеры активности обратно в DynamoDB. Эта архитектура легко масштабируется, потому что каждый компонент является событийным и независимо масштабируемым.

Внедрение EDA на Azure

Azure предоставляет параллельный набор услуг для архитектур, управляемых событиями: Azure Event Grid, Azure Service Bus и Azure Functions. Основополагающие принципы одинаковы, но условности и интеграционные шаблоны Azure немного отличаются. Выбор между Azure и AWS часто сводится к существующим облачным инвестициям и требованиям соответствия.

Azure Event Grid: роутер событий без сервера

Azure Event Grid - это полностью управляемая служба маршрутизации событий, которая находится между производителями и потребителями событий. Она принимает события из сервисов Azure (например, Blob Storage, Resource Groups) и пользовательских приложений, а затем предоставляет их подписчикам, таким как функции Azure, веб-хуки, очереди в сервисных автобусах или логические приложения. Event Grid поддерживает фильтрацию событий по типам событий, префиксам субъектов и расширенным условиям. Он также предлагает версию и выкуп схемы событий (политики повторных попыток) для обеспечения надежности.

Одной из отличительных особенностей Event Grid является встроенная интеграция с Azure Health Data Services и Azure Maps, позволяющая создавать шаблоны событий, специфичные для домена. Для гибридных сценариев Event Grid может подключаться к локальным событиям через Azure Arc.

Azure Functions: Event-Driven Compute (англ.) (недоступная ссылка).

Azure Functions - это бессерверный вычислитель, предлагающий аналог AWS Lambda. Он может быть запущен событиями Event Grid, сообщениями Service Bus, коммутацией Cosmos DB, HTTP-запросами или пользовательскими триггерами. Azure Functions поддерживает несколько языков (C#, JavaScript, Python, PowerShell) и обеспечивает привязки, которые упрощают операции ввода / вывода без написания явного кода подключения.

Для событийных сценариев используйте триггер Event Grid, связывающий автоматически масштабируемые функции на основе количества событий. Для высокопроизводительных сценариев хостинг премиум-плана обеспечивает более быстрый запуск и резервную емкость. Как и Lambda, реализуйте идемпотентные обработчики и используйте Dead-lettering (через конечные точки Event Grid dead-letter) для захвата неудавшихся событий.

Автобус Azure: надежная переписка

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

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

Архитектура в Azure

Представьте себе конвейер обработки документов. Когда пользователь загружает PDF-файл в хранилище Azure Blob, событие BlobCreated отправляется в Event Grid. Event Grid направляет событие в функцию Azure, которая извлекает метаданные и хранит их в Azure Cosmos DB. То же самое событие также запускает очередь Service Bus для извлечения текста с использованием когнитивных служб Azure. Как только извлечение завершается, вторая функция публикует событие обратно в Event Grid, которая затем отправляет уведомление пользователю через центры уведомлений Azure. Эта конструкция изолирует каждый этап обработки и позволяет независимое масштабирование.

Сравнение AWS и Azure для EDA

Обе платформы предлагают зрелые сервисы, основанные на событиях, но есть ключевые различия, которые следует учитывать:

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

Расширенные шаблоны событий

Помимо базовой маршрутизации событий, облачные платформы поддерживают шаблоны, которые отвечают сложным бизнес-требованиям:

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

В случае источника событий полное состояние приложения получается путем повторного воспроизведения последовательности событий, хранящихся в магазине событий. AWS предлагает Amazon EventBridge с повторением событий - вы можете воспроизводить исторические события из архива. Azure Event Grid поддерживает воспроизведение событий только для опубликованных событий (в окне сохранения). Для истинного источника событий многие команды объединяют EventBridge / Event Grid с DynamoDB (AWS) или Cosmos DB (Azure), действуя как магазин событий, используя захват изменений для восстановления состояния.

CQRS (Command Query Responsibility Segregation) — сегрегация ответственности

Разделение моделей чтения и записи становится естественным в системе, управляемой событиями. Написание команд производит события (например, через EventBridge или Event Grid), в то время как модели чтения потребляют эти события для поддержания проекций. Этот шаблон позволяет независимо масштабировать рабочие нагрузки чтения и записи. На AWS вы можете использовать потоки DynamoDB + Lambda для поддержания денормализованных просмотров. На Azure Cosmos DB изменяет питание триггеров Функции для обновления отдельного оптимизированного для чтения контейнера Cosmos DB.

Хореографический vs. оркестрованный рабочий процесс

Системы, управляемые событиями, обычно используют хореографию (каждая служба слушает события и реагирует независимо), но иногда оркестровка необходима для сложных рабочих процессов. AWS Step Functions и Azure Logic Apps интегрируются с источниками событий для обеспечения государственной оркестровки машины. Например, Step Function может ждать нескольких событий (например, одобренная оплата и резервирование запасов) перед отправкой. Этот гибридный шаблон сочетает в себе разъединение EDA с контролем рабочих процессов.

Оперативные лучшие практики

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

Импотенция и точно-разовая обработка

Облачные службы событий часто гарантируют доставку как минимум один раз. Убедитесь, что ваши обработчики событий являются идемпотентными: они могут обрабатывать одно и то же событие несколько раз без побочных эффектов. Используйте идентификаторы событий или ключи идемпотента (например, идентификатор заказа) для обнаружения дубликатов. На AWS вы можете использовать свойство Lambda ; на Azure используйте свойство Event Grid событий. Храните обработанные идентификаторы в кэше (например, AWS ElastiCache или Azure Redis) с TTL.

Обработка ошибок и Dead-Lettering

Всегда настраивайте пункты назначения с мертвой буквой для очередей, подписок на события и функций без сервера. В AWS связывайте очередь с мертвой буквой (DLQ) с вашей функцией Lambda или очередей SQS. В Azure установите конечную точку с мертвой буквой на подписках Event Grid и очередях Service Bus. Следите за DLQ для сообщений, которые не могут быть обработаны, и настройте оповещения для расследования повторных сбоев.

Мониторинг и наблюдаемость

Используйте облачные инструменты мониторинга для отслеживания потока событий. AWS CloudWatch может захватывать вызовы Lambda, метрики EventBridge (отправленные события, неудачные вызовы) и глубины очереди SQS. Azure Monitor предоставляет аналогичные метрики для функций, Event Grid и Service Bus. Включает распределенное отслеживание с помощью AWS X-Ray или Azure Application Insights для визуализации распространения событий через службы. Для отладки регистрируйте события в структурированном формате (JSON) и включайте идентификаторы корреляции.

Безопасность и соблюдение

Данные о событиях часто содержат конфиденциальную информацию. Шифровать события в состоянии покоя с помощью AWS KMS или Azure Storage Service Encryption. Используйте ресурсные политики (политики ресурсов EventBridge, идентификаторы Azure Event Grid), чтобы ограничить, какие службы могут публиковать или потреблять события. Для соответствия, сохраняйте данные о событиях для целей аудита - используйте архивы EventBridge (AWS) или сохранение подписки Event Grid (Azure). Даже с шифрованием, рассмотрите возможность токенизации чувствительных полезных нагрузок перед выпуском событий.

Реальные случаи использования в мире

Архитектура, управляемая событиями, обеспечивает работу критически важных систем в различных отраслях. В электронной коммерции EDA обрабатывает обработку заказов, обновления запасов и уведомления клиентов асинхронно. В IoT потоковая передача данных датчиков через AWS IoT Core или Azure IoT Hub запускает аналитику и оповещения, основанные на событиях. В финансовых услугах трубопроводы обнаружения мошенничества потребляют события транзакций и запускают автоматизированные действия в течение миллисекунд. Многие платформы SaaS (например, Stripe, Slack) предоставляют события веб-хокинга, которые легко интегрируются с EventBridge или Event Grid, что позволяет расширить ваше приложение с помощью внешних событий.

Например, логистическая компания использует Azure Event Grid для получения обновлений отслеживания от API-интерфейсов операторов, которые затем обновляют базу данных Cosmos DB и push-уведомления на мобильные устройства.На AWS медиакомпания обрабатывает загрузку через EventBridge: при загрузке видео на S3 EventBridge запускает функцию Lambda, которая транскодирует видео и обновляет таблицу DynamoDB.

Расчеты расходов

Системы, управляемые событиями, могут быть экономически эффективными, потому что вы платите только тогда, когда происходят события. Однако, большие объемы событий могут складываться. Плата AWS за миллион событий EventBridge (сначала 100 миллионов бесплатных, затем 1,00 долларов / М) плюс затраты на вызов Lambda. Azure Event Grid взимает 0,60 долларов за миллион операций (сначала 100 000 бесплатных). SQS и Service Bus имеют отдельную цену. Для оптимизации, фильтрация событий на основе контента в EventBridge или фильтры подписки в Event Grid, чтобы уменьшить количество событий, доставленных для вычисления целей. Кроме того, пакетные сообщения, где практично (размер пакета SQS, сеансы служебной шины).

Для высокой пропускной способности сравните варианты без сервера с обеспеченной инфраструктурой. AWS Kinesis Data Streams или Azure Event Hubs могут быть дешевле для постоянной обработки потоков (например, миллионы событий в секунду). Оцените общую стоимость владения, включая хранение, мониторинг и передачу данных.

Заключение

Внедрение архитектуры событий на облачных платформах, таких как AWS и Azure, позволяет организациям создавать системы, которые слабо связаны, масштабируются и реагируют на бизнес-события в режиме реального времени. Тщательно выбирая соответствующие службы - EventBridge, Lambda, SNS / SQS на AWS; Event Grid, Функции, Сервисная шина на Azure - и придерживаясь передовых практик для управления идемпотентностью, обработки ошибок, мониторинга и безопасности, вы можете создавать приложения, ориентированные на события производственного уровня. Расширенные шаблоны, такие как поиск событий и CQRS, дополнительно разблокируют возможности событий для управления сложной бизнес-логикой. Какую бы облачную платформу вы ни выбрали, основополагающие принципы EDA остаются теми же: охватывают асинхронную связь, дизайн для отказа и позволяют событиям управлять вашей архитектурой.

Для дальнейшего чтения обратитесь к официальной документации по Amazon EventBridge и Azure Event Grid.CloudEvents Спецификация обеспечивает нейтральный для поставщика стандарт для описания данных о событиях.