Event driven architecture что это
Стиль архитектуры, управляемой событиями
Управляемая событиями архитектура включает поставщики событий, которые создают потоки событий, и потребители событий, которые прослушивают эти события.
События доставляются практически мгновенно, что позволяет потребителям немедленно реагировать на происходящие события. Поставщики не связаны с потребителями — ни один поставщик не знает, кто прослушивает его события. Потребители также не зависят друг от друга, и каждый из них получает все события. Это важное отличие от шаблона конкурирующих клиентов, в котором пользователи извлекают сообщения из очереди, и каждое сообщение обрабатывается только один раз (если не возникает ошибок). В некоторых системах, таких как Интернет вещей, события обрабатываются в огромных объемах.
В основе управляемой событиями архитектуры может лежать модель публикации и подписки или модель потока событий.
Публикация и подписка. Инфраструктура обмена сообщениями поддерживает список подписок. Каждое публикуемое событие отправляется каждому подписчику. Полученное сообщение нельзя воспроизвести повторно. Также оно не доставляется тем подписчикам, которые добавляются позднее.
Потоковая передача событий. Все события записываются в журнал. События в пределах каждой секции строго упорядочены и сохраняются в течение долгого времени. Клиенты не подписываются на поток, а просто считывают события из любой его части. Каждый клиент самостоятельно управляет своим положением в потоке. Это означает, что клиент может подключиться в любое время и (или) прослушать события повторно.
На стороне получателя есть несколько распространенных вариантов реализации.
Обработка простых событий. Каждое событие немедленно запускает действие в объекте-получателе. Например, в Функциях Azure можно создать триггер служебной шины, который будет выполнять некоторую функцию при каждой публикации сообщения в определенном разделе служебной шины.
Обработка сложных событий. Объект-получатель обрабатывает последовательность событий и отслеживает в них определенные закономерности с помощью некоторого технологического решения, например Azure Stream Analytics или Apache Storm. Например, можно выполнять статистическую обработку показаний встроенного устройства за некоторый период времени, чтобы создавать уведомления, когда скользящее среднее значение выходит за определенные пороговые значения.
Обработка потока событий. Платформу потоковой передачи данных, например Центр Интернета вещей Azure или Apache Kafka, можно использовать как конвейер для приема событий и передачи их в обработчики потоков. Обработчики потоков определенным образом реагируют на эти процессы или преобразовывают поток. Может существовать несколько обработчиков потока для разных подсистем приложения. Такой подход хорошо подходит для рабочих нагрузок Интернета вещей.
Источник событий может находиться за пределами системы, например это могут быть физические устройства в решении Интернета вещей. В такой ситуации система должна поддерживать прием данных в таких объемах и на такой скорости, которые соответствуют характеристикам источника данных.
На представленной выше логической схеме каждый тип потребителя обозначен отдельным блоком. На практике обычно используется несколько экземпляров каждого поставщика, чтобы они не становились единой точкой отказа. Наличие нескольких экземпляров также может требоваться для обработки событий в нужных объемах и (или) с нужной скоростью. Кроме того, каждый объект-получатель может обрабатывать события в нескольких потоках. Это может привести к проблемам, если события должны обрабатываться по порядку или требовать ровно одну семантику. См. руководство по минимизации координации.
Применение Event-driven модели в веб-приложении
Взаимодействие частей приложения друг с другом — важная часть архитектуры любой программы.
И существует немало паттернов для их реализации. Я бы хотел на примере веб-приложения показать применение одного из них, а именно — Event-driven модели.
Она хорошо известна любому frontend-разработчику — всякий раз, работая с событиями DOM, вы используете эту модель. Давайте попробуем построить на ней не маленькое веб-приложение — файловый менеджер.
Почему именно файловый менеджер? Потому что, на мой взгляд, эта модель отлично подходит для приложений, которые должны уметь работать с различными наборами модулей (и не только своих собственных). Ну и еще потому, что я сейчас работаю над новой версией нашего файлового менеджера, где и использую ее. Так что все примеры вполне реальны, хотя и упрощены до неузнаваемости.
Из чего состоит наше приложение?
А чтобы наше просветление обрело истинную силу Дао, сначала мы опишем неудачный способ взаимодействия модулей — «прямой контакт» друг с другом.
Ядро получает от серверной части список файлов и отдает его виду. Вид показывает пользователю, что содержится в текущей директории и ждет его действий.
Пользователь кликает по файлу. Вид обращается к ядру за разъяснением происходящего. Ядро успокаивает вид, говоря, что ничего не случилось — просто файл выбран, и оно теперь в курсе.
Пользователь дважды кликает по папке. Вид в панике молит ядро о помощи. Ядро хладнокровно сообщает виду, что он не по адресу обратился, и посылает его к команде «open»…
Но пока терпимо. А теперь добавим еще один вид — дерево директории. Теперь ядро должно помнить, что и этому виду надо передать список полученных файлов.
И еще добавим вид — «favorites».
Ядро в шоке — «а этому-то что нужно?».
Продолжать не буду — и так ясно, что никакой возможности для расширений у нас нет. Для реализации каждой новой команды нам придётся постоянно дописывать ядро.
Идеология событий
А теперь будем медитировать над задачей, пока в результате просветления (я же обещал, что оно наступит) мы не изречем:
— Любое изменение — есть событие!
Вернемся к нашему примеру и убедимся, насколько все стало проще.
Ядро получает от серверной частей список файлов и генерирует событие «open». Все виды рисуют то, что должны.
Пользователь кликает по файлу. Вид генерирует событие «select». Ядро запоминает, какой файл выбран.
Пользователь дважды кликает по папке. Вид генерирует событие «dblclick». Ни секунды не медля, команда «open» бросается в бой и заставляет ядро совершить запрос к серверу.
А теперь перейдем к тому, что мы любим больше всего — писать код!
Реализация будет выглядеть так же, как в jQuery, за одним исключением —
данные, связанные с конкретным вызовом события будут передаваться в поле самого объекта события.
Еще раз повторю, что код сильно упрощен и значительно отличается от реального кода нашего проекта. Если любопытно посмотреть как он выглядит на самом деле — проект на github
А теперь подведем итоги.
Какую пользу мы получили, использовав event-driven модель?
Недостатки:
Как событийно-ориентированная архитектура решает проблемы современных веб-приложений
Пока у нас продолжается распродажа на самые взыскательные вкусы, мы обратим ваше внимание на еще одну тему нашего творческого поиска: событийно-ориентированную архитектуру (EDA). Под катом вас ожидают красивые блок-схемы и рассказ о том, как данная инновационная парадигма помогает при разработке веб-приложений.
В этой статье будут рассмотрены некоторые проблемы, подстегивающие развитие инноваций в современной веб-разработке. Далее мы погрузимся в тему событийно-ориентированной архитектуры (EDA), призванной решить эти проблемы, по-новому трактуя архитектуру серверной части.
Веб-приложения прошли долгий путь с тех времен, когда контент, оформленный в виде статических HTML-страниц, подавался с сервера. Сегодня веб-приложения стали гораздо сложнее, в их работе используются разнообразные фреймворки, датацентры и технологии. В последние пару лет можно отметить две тенденции, определяющие развитие IT-рынка:
Актуальные проблемы современного веба
Любая веб-технология должна справляться с теми вызовами, которым должны отвечать современные многопользовательские асинхронные приложения, рассчитанные на бесперебойную работу:
Доступность
Теперь мы работаем не с одним приложением, а с многими – десятками или даже сотнями – связанными сервисами, и каждый из них должен решать свои задачи круглосуточно, семь дней в неделю. Как этого добиться? Чаще всего сервис горизонтально масштабируют на множество инстансов, которые могут быть распределены в нескольких датацентрах – так обеспечивается высокая доступность. Все запросы, поступающие на данный конкретный сервис, маршрутизируются и равномерно распределяются по всем инстансам. В некоторых инструментах развертывания предоставляются возможности самовосстановления, поэтому при отказе одного инстанса создается другой, заступающий на его место.
Масштабируемость
Масштабируемость во многом сродни доступности. Суть доступности – обеспечить, что как минимум один экземпляр сервиса активен и работает, готов обслуживать входящие запросы. Масштабируемость, в свою очередь, связана, прежде всего, с производительностью. Если какое-либо приложение перегружено, то создаются новые экземпляры этого приложения, чтобы подстроиться к возросшему количеству запросов. Но вертикальное масштабирование приложений – нетривиальная задача, в особенности если речь идет о приложениях с сохранением состояния.
Единый источник истины
До появления микросервисов такая задача решалась довольно просто. Все данные располагались в одном местоположении, как правило, это была та или иная реляционная база данных. Но, когда множество сервисов совместно используют базу данных, могут создаваться такие проблемы, как возникающие между разными командами зависимости, касающиеся изменений схемы или проблем с производительностью. Обычно эта проблема решалась выделением своей базы данных на каждый сервис. Распределенный источник истины очень хорошо помогает соблюдать чистую архитектуру, но в такой ситуации приходится иметь дело с распределенными транзакциями и сложностью, сопряженной с поддержкой множественных баз данных.
Синхронность
При реализации типичного сценария вида «запрос-отклик» клиент дожидается, пока ответит сервер; он блокирует все действия, пока не получит ответ, либо пока не истечет заданная задержка. Если взять такое поведение и внедрить его в микросервисную архитектуру при помощи цепочек вызовов, пронизывающих всю систему, то можно легко оказаться в так называемом «микросервисном аду». Все начинается с вызова всего одного сервиса, назовем его «сервис А». Но затем сервис A должен вызвать сервис B, и начинается самое интересное. Проблема с данным поведением такова: если сам сервис связан с заблокированными ресурсами (например, висит поток), то задержки растут экспоненциально. Если у нас разрешена задержка в 500 мс на сервис, а в цепочке пять вызовов сервисов, то первому сервису понадобится задержка в 2500 мс (2,5 секунды), а последнему – 500 мс.
Вызовы современного веба
Знакомство с событийно-ориентированной архитектурой
Событийно-ориентированная архитектура (EDA) – это парадигма программной архитектуры, способствующая порождению, обнаружению, потреблению событий и реакции на них.
В классических трехуровневых приложениях ядром системы является база данных. В EDA фокус смещается на события и на то, как они просачиваются через систему. Такая смена акцентов позволяет полностью изменить подход к проектированию приложений и решению вышеупомянутых проблем.
Прежде, чем рассмотреть, как именно это делается в EDA, рассмотрим, что же такое «событие». Событие – это действие, инициирующее либо некоторое уведомление, либо изменение в состоянии приложения. Свет включился (уведомление), термостат отключил обогревательную систему (уведомление), у пользователя изменился адрес (изменение состояния), у кого-то из ваших друзей изменился номер телефона (изменение состояния). Все это — события, но еще не факт, что мы должны добавлять их в событийно-ориентированное решение. Предполагается, что в архитектуру добавляются лишь события, важные с точки зрения бизнеса. Событие «пользователь оформляет заказ» важно с точки зрения бизнеса, а «пользователь съедает заказанную пиццу или обед» — нет.
Если подумать над некоторыми событиями, то по поводу некоторых сразу понятно, что они важны для бизнеса, а по поводу некоторых – нет. Особенно по поводу тех, что происходят в ответ на другие события. Для выявления событий, идущих через систему, применяется техника под названием «событийный штурм». Созываются участники разработки приложения (от программистов до разработчиков бизнес-логики и экспертов в предметной области) и общими силами картируют все бизнес-процессы, представляя их в виде конкретных событий. Когда такая карта будет готова, результат работы формулируется в виде требований, которые должны выполняться при разработке приложений.
Пример приложения для бронирования, описанного методом событийного штурма
Выявив интересующие нас события и определившись, как их идентифицировать, давайте рассмотрим, как при помощи данной парадигмы можно решить типичные проблемы, упомянутые выше.
Поток событий является однонаправленным: от производителя к потребителю. Сравните данную ситуацию с вызовом REST. Производитель событий в принципе не ожидает отклика от потребителя, тогда как в случае REST-вызова отклик будет всегда. Нет отклика – значит не необходимости блокировать выполнение кода, пока не произойдет что-то еще. В таком случае события становятся асинхронными по природе своей, что полностью исключает риск увязнуть в задержках.
События происходят в результате действия, поэтому целевой системы здесь нет; нельзя сказать, что сервис A инициирует события в сервисе B; но можно сказать, что сервис B интересуют события, порождаемые сервисом A. Правда, в этой системе могут быть и другие «заинтересованные стороны», например, сервисы C или D.
Как же нам убедиться, что событие, инициированное в некоторой системе, достигнет всех «заинтересованных» сервисов? Как правило, подобные системы решаются при помощи брокеров сообщений. Брокер – это просто приложение, действующее в качестве посредника между генератором события (приложением, создавшим это событие) и потребителем события. Таким образом, приложения удается аккуратно открепить друг от друга, позаботившись о проблеме доступности, речь о которой шла выше в этом посте. Если именно в данный момент приложение недоступно, то, вернувшись в онлайн, оно начнет потреблять события и обрабатывать их, наверстав все те события, которые успели произойти за период, пока оно оставалось недоступным.
Что насчет хранилища данных? Можно ли хранить события в базе данных, либо вместо базы данных требуется что-то иное? Определенно, события можно хранить в базах данных, но в таком случае утрачивается их «событийная» сущность. Как только событие произошло, скорректировать его мы уже не можем, поэтому события по сути своей неизменяемы. Базы данных, в свою очередь… изменяемы, после занесения данных в базу их вполне можно изменить.
Лучше хранить события в логах событий. Логи событий – не что иное, как централизованное хранилище данных, где каждое событие записано в виде последовательности неизменяемых записей, так называемого «лога». Лог можно сравнить с журналом, где каждое новое событие добавляется в конец списка. Всегда можно воссоздать наиболее актуальное состояние, воспроизведя все события лога от начала до настоящего момента.
Итак, мы затронули все вопросы, кроме масштабируемости. Сервисы, создаваемые в событийно-ориентированном ключе, всегда рассчитаны на развертывание во множестве инстансов. Поскольку состояние как таковое хранится в логе событий, сам сервис будет без сохранения состояния, что обеспечивает хирургически точное масштабирование любого интересующего нас сервиса.
Единственным исключением из этого принципа являются сервисы, предназначенные для создания материализованных представлений. В сущности, материализованное представление – это состояние, описывающее лог событий в определенный момент времени. Такой подход используется, чтобы было проще запрашивать данные. Возвращаясь к проблеме масштабирования, скажем, что материализованное представление – это просто совокупное представление событий, напоминающее по форме таблицу; но где мы храним эти таблицы? Чаще всего приходится видеть такие агрегации в памяти, и при этом наш сервис автоматически превращается в сохраняющий состояние. Быстрое и легкое решение – снабдить локальной базой данных каждый сервис, создающий материализованные представления. Таким образом, состояние хранится в базе данных, и сервис работает без сохранения состояния.
Хотя, событийно-ориентированная архитектура существует уже более 15 лет, она лишь недавно снискала серьезную популярность, и это неслучайно. Большинство компаний проходят этап «цифровой трансформации», сопровождаемый дикими требованиями. Из-за сложности этих требований инженерам приходится осваивать новые подходы к проектированию ПО, предполагающие, в частности, ослабление связанности сервисов друг с другом и снижение издержек на обслуживание сервисов. EDA — одно из возможных решений этих проблем, но не единственное. Также не рассчитывайте, что все проблемы решатся, стоит только перейти на EDA. Для реализации некоторых фич по-прежнему могут потребоваться надежные дедовские REST API или хранение информации в базе данных. Выберите наиболее подходящий для вас вариант и спроектируйте его как следует!
Что такое событийная архитектура
Событийная архитектура использует события для запуска и обмена данными между разделенными службами и является обычным явлением в современных приложениях, созданных с использованием микросервисов.
1. Что такое событийная архитектура
Шаблон управляемой событиями архитектуры (событийная архитектура, event-driven architecture, EDA) — это популярный шаблон распределенной асинхронной архитектуры, используемый для создания масштабируемых приложений. EDA состоит из разделенных одноцелевых компонентов, которые асинхронно получают и обрабатывают события.
2. Пример
Приведем пример событийной архитектуры — сайт электронной коммерции. Такая архитектура позволяет сайту реагировать на изменения в различных источниках во время пикового спроса без сбоев приложения или избыточного выделения ресурсов.
Пример событийной архитектуры для сайта электронной коммерции. (1) — Продюсеры событий; (2) — Начальные события; (3) — Маршрутизаторы событий; (4) — События обработки; (5) — Потребители событий.
3. Компоненты
Управляемые событиями архитектуры включают пять ключевых компонентов: продюсеры (производитель) событий, начальные события и события обработки, маршрутизаторы событий и потребители событий. Продюсер публикует начальное событие в маршрутизаторе, который фильтрует и передает событие обработки потребителям. Сервисы продюсера и потребителя разделены, что позволяет масштабировать, обновлять и развертывать их независимо.
3.1 Продюсеры мероприятий
В этом примере производители событий представлены eCommerce сайтом, мобильным приложением и торговым терминалом. В принципе, все, что регистрирует факт и представляет факт как сообщение о событии, может быть продюсером.
3.2 События
Первоначальное событие — это исходное событие, сгенерированное продюсером и полученное маршрутизатором, тогда как события обработки — это события, которые генерируются маршрутизатором событий и принимаются компонентами потребителя событий.
События могут содержать либо состояние (приобретенный товар, его цена и адрес доставки), либо события могут быть идентификаторами (уведомление о том, что заказ был отправлен).
Событие обычно состоит из двух частей: 1) заголовок события включает такую информацию, как имя события, отметка времени и тип события; 2) тело события предоставляет подробную информацию об обнаруженном изменении состояния.
3.3 Каналы
И начальные, и события обработки доставляются по каналам событий.
Первоначальные каналы событий могут быть TCP/IP-соединением или файлом (XML, JSON, электронная почта и т.д). Одновременно можно открыть несколько исходных каналов событий. Они читаются асинхронно, что позволяет обрабатывать события почти в реальном времени. События хранятся в очереди, ожидая последующей обработки маршрутизатором событий.
Каналы обработки событий обычно представлены очередями сообщений и брокерами сообщений. Брокеры сообщений наиболее широко используются, так что события могут обрабатываться несколькими потребителями событий (каждый из которых выполняет свою задачу в зависимости от полученного события обработки).
3.4 Маршрутизатор событий
Маршрутизатор событий отвечает за идентификацию начального события, а затем за выбор и выполнение шагов, содержащихся в событии. Для каждого шага в начальном событии маршрутизатор событий асинхронно отправляет событие обработки в канал событий, которое затем принимается и обрабатывается потребителем событий.
Маршрутизатор событий также может запускать ряд утверждений. Например, если событие, которое поступает в механизм обработки событий, является идентификатором продукта, запас которого на складе ограничен, это может вызвать такие реакции, как «Заказать продукт» и «Уведомить персонал».
Важно отметить, что маршрутизатор событий не выполняет бизнес-логику, необходимую для обработки исходного события — он распределяет соответствующие инструкции (= события обработки) среди потребителей событий.
3.5 Потребители событий
В этом примере потребители событий представлены управленческой базой данных, финансовой системой и отделом по работе с клиентами.
Эти компоненты содержат бизнес-логику приложения, необходимую для обработки события обработки. Потребители событий — это автономные, независимые, сильно разделенные компоненты архитектуры, которые выполняют определенную задачу в приложении или системе. Хотя степень детализации потребителей событий может варьироваться от точечной (например, расчет налога с продаж по заказу) до крупной (например, обработка страхового возмещения), важно помнить, что в целом каждый потребитель события должен выполнять одну бизнес-задачу и не полагаться на других потребителей в выполнении своей конкретной задачи.
4. Анализ шаблона
4.1 Масштабируемость: высокая
Каждый потребитель событий может масштабироваться отдельно, что обеспечивает точную масштабируемость.
4.2 Сложность разработки: высокая
Сложно из-за асинхронного характера шаблона, а также из-за создания контракта и необходимости более сложных условий обработки ошибок в коде для не отвечающих обработчиков событий и отказавших брокеров.
4.3 Производительность: высокая
Высокая производительность за счет асинхронных возможностей: возможность выполнять разделенные, параллельные асинхронные операции перевешивают затраты на постановку в очередь и удаление сообщений из очереди.
4.4 Тестируемость: низкая
Хотя индивидуальное юнит-тестирование не слишком сложно, для генерации событий требуется какой-то специализированный клиент или инструмент тестирования. Тестирование также осложняется асинхронным характером этого шаблона.
4.5 Модифицируемость: высокая
Поскольку компоненты-потребители событий являются одноцелевыми и полностью отделены от других компонентов-потребителей событий, изменения, как правило, ограничиваются одним или несколькими потребителями событий и могут быть выполнены быстро, не затрагивая другие компоненты.
5. Событийная архитектура: примеры использования
5.1 Репликация данных между аккаунтами и регионами
Системы координации между командами, работающими и развертывающимися в разных регионах и учетных записях. Используя маршрутизатор событий для передачи данных между системами, вы можете разрабатывать, масштабировать и развертывать службы независимо от других команд.
5.2 Разветвление и параллельная обработка
Если у вас много систем, которые должны работать в ответ на событие, вы можете использовать архитектуру, управляемую событиями, для разветвления события без необходимости писать собственный для отправки каждому потребителю. Маршрутизатор отправит событие в системы, каждая из которых может обрабатывать событие параллельно с разными целями.
5.3 Мониторинг состояния ресурсов и оповещение
Вместо того, чтобы постоянно проверять свои ресурсы, вы можете использовать управляемую событиями архитектуру для отслеживания и получения предупреждений о любых аномалиях, изменениях и обновлениях. Эти ресурсы могут включать сегменты хранилища, таблицы базы данных, бессерверные функции, вычислительные узлы и многое другое.
5.4 Интеграция гетерогенных систем
Если у вас есть системы, работающие в разных стеках, вы можете использовать управляемую событиями архитектуру для обмена информацией между ними без прямой связи. Маршрутизатор событий устанавливает косвенное обращение и взаимодействие между системами, поэтому они могут обмениваться сообщениями и данными, оставаясь при этом независимыми.