Что такое архитектура, управляемая событием (EDA)?

Архитектура, управляемая событием (EDA), – это современный архитектурный шаблон, созданный из небольших несвязанных сервисов, которые публикуют, потребляют или маршрутизируют события.

Событие представляет собой изменение состояния или его обновление. Например, товар помещен в корзину, файл загружен в систему хранения данных или заказ, который становится готовым к отправке. События могут либо сохранять состояние (например, название товара, цена или его количество в заказе) или просто содержать идентификаторы (например, «заказ № 8942 отправлен») для поиска соответствующей информации.

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

Почему важна развязанная архитектура?

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

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

Подробнее о преимуществах модернизации монолитных приложений см. раздел Обеспечение сохранности данных в микросервисах в Нормативном руководстве AWS.

Каковы преимущества архитектуры, управляемой событиями (EDA)?

Архитектура, управляемая событиями (EDA), способствует слабой взаимозависимости между компонентами системы, что приводит к большей гибкости. Микросервисы могут масштабироваться независимо, выходить из строя без влияния на другие сервисы и снижать сложность рабочих процессов. События можно гибко маршрутизировать, буферизировать и регистрировать для целей аудита. Потоки событий на основе технологии push могут работать в режиме реального времени, сокращая расходы, связанные с созданием и эксплуатацией кода, который постоянно опрашивает системы на предмет изменений.

Независимое масштабирование и сбои

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

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

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

Гибкая разработка

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

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

Создание расширяемых систем

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

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

Уменьшение сложности

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

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

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

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

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

Легкость работы с инструментами аудита

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

Сокращение расходов

EDA основаны на принципе push, поэтому все происходит по требованию, когда событие появляется в маршрутизаторе. Таким образом, вы не платите за постоянный опрос для проверки наличия события. Это означает меньшее потребление пропускной способности сети, меньшую загрузку процессора, меньшую незадействованную емкость парка и меньшее количество рукопожатий SSL/TLS.

Как работает архитектура, управляемая событиями (EDA)?

Ниже приведен пример событийно-управляемой архитектуры (EDA) для сайта электронной коммерции:

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

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

Какие типы рабочих нагрузок подходят для архитектуры, управляемой событиями (EDA)?

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

Как событийно-управляемая архитектура (EDA) улучшает приложения?

Событийно-ориентированная архитектура (EDA) способствует свободному соединению компонентов, что делает ее хорошим подходом для построения современных распределенных приложений.

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

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

Каковы общие примеры использования архитектуры, управляемой событиями (EDA)?

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

Сайты розничной торговли или СМИ и индустрии развлечений часто должны масштабироваться для обработки непредсказуемого трафика. Клиенты посещают сайт электронной коммерции и оформляют заказ. Событие заказа отправляется на маршрутизатор событий. Все последующие микросервисы могут принять событие заказа для обработки. Примеры действий могут включать: отправку заказа, авторизацию платежа и отправку информации о заказе поставщику сервисов доставки.

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

Автоматизация делового документооборота

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

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

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

Интеграция приложений SaaS

Одной из главных проблем для сред программного обеспечения как услуги (SaaS) является недостаточная видимость действий и данных пользователей. Чтобы разблокировать изолированные данные, архитектуры, управляемые событиями, могут получать события приложений SaaS или отправлять события своим приложениям SaaS. Например, вы можете создать промежуточное программное обеспечение для получения данных о входящих заказах партнеров и отправки заказов непосредственно в собственное приложение для обработки заказов.

Автоматизация облачной инфраструктуры

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

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

Когда следует использовать архитектуры, управляемые событиями (EDA)?

Архитектуры, управляемые событиями (EDA), идеально подходят для повышения гибкости и быстрого продвижения. Они часто встречаются в современных приложениях, использующих микросервисы, или в любых приложениях с разделенными компонентами.

Интеграция гетерогенных систем

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

Межрегиональная и межаккаунтная репликация данных

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

Мониторинг состояния ресурсов и получение оповещений

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

Веерная и параллельная обработка

Если у вас много систем, которые должны работать в ответ на событие, вы можете использовать EDA для веерного распространения события без необходимости писать собственный код для каждого потребителя. Маршрутизатор передает событие системам, каждая из которых может параллельно обрабатывать событие с разной целью.

Каковы общие шаблоны архитектуры, управляемой событиями (EDA)?

Множество простых функций

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

Обработка по требованию вместо пакетной обработки

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

В архитектуре, управляемой событиями (EDA), система пользовательской обработки может реагировать на каждое событие. Это позволяет сервису масштабировать параллелизм по мере необходимости для обработки транзакций практически в реальном времени.

Восстановление после сбоев

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

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

Какие проблемы возникают при использовании архитектуры, управляемой событиями (EDA)?

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

Переменная задержка

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

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

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

Конечная согласованность

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

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

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

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

Возвращение значений операторам

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

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

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

Отладка по службам и функциям

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

Оркестрация

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

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

Какие сервисы AWS используют архитектуру, управляемую событиями (EDA)?

Сервисы AWS обычно производят или потребляют события, что упрощает создание решений с архитектурой, управляемой событиями (EDA).

Кроме того, такие сервисы, как Amazon EventBridge, Amazon SNS, Amazon SQS и AWS Step Functions, включают функции, которые помогают клиентам писать меньше шаблонного кода и быстрее создавать EDA.

Amazon EventBridge

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

EventBridge применяет правила для маршрутизации событий от источников событий к различным целям. Целями могут быть сервисы AWS, такие как AWS Lambda, Step Functions и Amazon Kinesis, или любая конечная точка HTTP через назначения API EventBridge.

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

AWS Step Functions

AWS Step Functions включает Workflow Studio, визуальный конструктор рабочих процессов с низким кодом, который используется разработчиками для оркестровки различных сервисов AWS. Вы можете использовать Workflow Studio для создания распределенных приложений, автоматизации ИТ- и бизнес-процессов, а также построения конвейеров данных и машинного обучения с использованием сервисов AWS.

Amazon SNS

Мы рекомендуем использовать Простой сервис уведомлений Amazon (Amazon SNS) для создания приложений, реагирующих на события с высокой пропускной способностью и низкой задержкой, публикуемые другими приложениями, микросервисами или службами AWS. Вы также можете использовать Amazon SNS для приложений, которым требуется очень высокая скорость распространения на тысячи или даже миллионы конечных точек.

Amazon SQS

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