В чем разница между потоковой передачей событий и источником событий и при чем здесь Apache Kafka: разбираемся с паттернами проектирования событийно-ориентированной архитектуры.
2 паттерна проектирования EDA-архитектуры
Напомним, что сегодня для построения сложных систем, зачастую состоящих из множества взаимодействующих компонентов, и реактивно реагирующих на события внешнего мира, активно используется идея архитектуры, управляемой событиями (EDA, Event Driven Architecture). Для реализации этой событийно-ориентированной архитектуры применяются соответствующие шаблоны, паттерны проектирования. В частности, к ним относятся потоковая передача событий и источник событий. Это две связанные, но разные EDA-концепции. EDA управляется событиями, которые обычно связаны с изменением состояния каких-либо объектов, и передает эти события, используя разделение в шаблоне публикации-подписки (pub-sub), где продюсер публикует событие, а подписчик (потребитель) наблюдает за ними. Продюсер и потребитель не зависят друг от друга.
При потоковой передаче событий между системами существует непрерывный поток данных, причем данные представляют новое состояние событий, транслируемых с использованием шаблона pub-sub. Потоковая передача событий (Event Streaming) — это процесс непрерывного захвата и хранения событий по мере их возникновения в системе. Эти события затем можно обрабатывать и анализировать в режиме реального времени или сохранять для последующего анализа. Потоковая передача событий часто используется в системах, требующих обработки больших объемов данных в реальном времени, таких как финансовые торговые системы или платформы социальных сетей.
С другой стороны, источник событий сохраняет каждое новое событие в журнале добавления. Это служит источником истины, содержащим хронологический порядок событий и контекстов. Источник событий (Event Sourcing) — это шаблон построения систем, которые сохраняют все изменения состояния приложения в виде последовательности событий. Эти события затем можно использовать для восстановления состояния приложения в любой момент времени. Источник событий часто используется в системах, требующих возможности аудита, отслеживания или соответствия требованиям, например, в области страхования или здравоохранения. Как мы писали здесь, источник событий — это метод регистрации каждого изменения, внесенного в агрегат, путем добавления его в непрерывный поток. Чтобы восстановить окончательное состояние агрегата, необходимо последовательно прочитать эти события, а затем применить их к агрегату. Это контрастирует с немедленными изменениями, выполняемыми в системе создания, чтения, обновления и удаления (CRUD). В типичной CRUD-системе любые изменения состояния записи сохраняются в базе данных, фактически перезаписывая предыдущую версию того же агрегата. Для эффективных реализаций паттерна Event Sourcing рекомендуется использовать хранилища событий, которые обеспечивают надежные гарантии согласованности и используют оптимистичный контроль параллелизма. На практике это означает, что когда одновременно происходит несколько изменений, только первоначальная модификация может добавлять события в поток. Последующие изменения, возможно, придется повторить, или они могут полностью завершиться неудачей.
Таким образом, источник событий и потоковая передача событий могут используются в EDA одновременно, но реализуют разные задачи и работают по-разному. Event Streaming обеспечивает асинхронную связь между различными микросервисами, а Event Sourcing отвечает за историю событий, сохраняя новые события в журнале, предназначенном только для добавления. Более того, эти подходы реализуются разными технологиями. Например, не рекомендуется использовать Apache Kafka в качестве лога в Event Sourcing из-за ограниченного времени жизни топика, определяемого в конфигурациях retention, о чем мы писали здесь. Кроме того, Apache Kafka гарантирует порядок только внутри разделов топика. Поэтому эта распределенная платформа потоковой передачи событий идеально подходит для шаблона Event Streaming, а не Event Sourcing, что мы разбираем в этой статье. Чтобы показать разницу обработки потоков данных в Event Streaming и Event Sourcing, далее рассмотрим эти подходы более подробно.
Event Sourcing
Источник событий сохраняет данные в виде событий в журналах добавления. Этот процесс фиксирует каждое изменение состояния приложения в объекте события и сохраняет эти объекты событий в виде журналов в хронологическом порядке. При использовании источников событий хранилища событий компилируют состояние бизнес-объекта как событие в последовательности, а изменение состояния, например новые заказы или отмена заказа, добавляет последнее состояние к списку событий. Чтобы источник событий работал эффективно и потреблял минимальное количество ресурсов, каждый объект события должен содержать только необходимые сведения. Это сводит к минимуму пространство для хранения и предотвращает использование ценных ресурсов для обработки данных, что приводит к получению бесполезной информации. Хранилища событий собирают деловые события и контекст, а добавление длинных потоков в журналы событий быстро потребляет хранилище базы данных. Сохранение только необходимых контекстов событий как части объекта события помогает освободить место для хранения для добавления нескольких журналов событий, которые позволяют получить полезную информацию. В таких случаях можно использовать моментальные снимки (snapshots), чтобы оптимизировать производительность. Такие снимки позволяют хранить текущее состояние объекта, достаточное для воссоздания временной шкалы. Тем не менее, не следует создавать моментальные снимки слишком часто, т.к. это снижает производительность. Однако, чрезмерно редкое создание снапсшотов может привести к рассинхронизации с событиями. Здесь важно найти баланс, который будет определяться особенностями каждого конкретного случая.
Хранилища событий поддерживают строгую согласованность при добавлении и оптимистичный параллелизм. Большинство из них гарантируют глобальный порядок, и некоторые имеют встроенную обработку идемпотентности. В источнике событий события — это состояние, а сам поток выглядит так:
- события в порядке их появления читаются из потока, который представляет все факты, произошедшие с сущностью, чтобы построить текущее состояние;
- при создании нового события, оно добавляется в поток;
- не нужно кэшировать состояние модели записи, поскольку оно находится в событиях.
События являются источником истины, только если они используются в модели записи в качестве основы для определения состояния. Хранилища событий, как реляционные, так и NoSQL, оптимизированы для быстрого чтения событий. Примечательно, что потоки событий не должны быть слишком длинными, поскольку они навсегда сохраняются в долговременном хранилище. Большой объем событий снижает производительность и усложняет управление версиями схемы данных.
В заключение отметим, что источник событий сам по себе не имеет прямого отношения к конечной согласованности и типу хранилища. Это детали реализации и компромиссы, которые определяются требованиями к проектируемой системе. Каждое хранилище данных имеет свои достоинства и недостатки, например, реляционные базы данных отлично реализуют OLTP-сценарии за счет нормализации, документо-ориентированные СУБД подходят для аналитических кейсов, а key-value хранилища быстро работают с простыми структурами. Подробнее об этом мы писали здесь.
Паттерн источник событий позволяет снизить зависимости микросервисов друг от друга и повышает устойчивость системы. Микросервисы получают возможность воспроизводить события, а также вести полный журнал изменений для определенной функции, например профиля пользователя.
Event Streaming и Event Sourcing: versus или вместе
Потоковая передача событий реализует следующий набор действий:
- Продюсер публикует событие в потоке событий, который представляет собой канал. Событие публикуется в конце канала (очередь в JMS-брокере или топик Apache Kafka).
- Один ил несколько потребителей подписываются на канал, чтобы получать события и реагировать на них.
- Реакция потребителя на событие может привести к запуску следующего этапа рабочего процесса, включая обновление состояния модели чтения с согласованностью в конечном счете. При этом нельзя гарантировать атомарность или оптимистичный параллелизм, поскольку такие инструменты, как Kafka, его не поддерживают, хотя позволяют эффективно публиковать сообщения и подписываться на них.
Если необходимо, чтобы модель записи была материализована из событий, придется бороться с ситуациями нарушении их порядка, а также обеспечить идемпотентность продюсера и потребителя подобно тому, как мы рассказывали здесь.
Хотя источник событий и потоковая передача событий — это разные шаблоны, которые можно использовать совместно. Потоковая передача событий добавляет возможности подключения к источникам событий, позволяя использовать данные о событиях многим микросервисам, использующим множество различных баз данных, которые могут играть роль хранилища данных для шаблона источник событий.
Источник событий — это устойчивое состояние, которое хранится и считывается как события, а потоковая передача событий — это перемещение событий из одного места в другое. Хранилища событий могут интегрироваться с платформами потокового вещания, чтобы публиковать события и продвигать их вперед. Большинство из них даже имеют встроенную реализацию шаблона Outbox, позволяющего публиковать события. Их обычно называют подписками. Их можно использовать для построения моделей чтения, запуска других потоков или маршрутизации событий на платформы потоковой передачи.
Однако, для моделей чтения не требуется тех же гарантий, что и для моделей записи. Поэтому может возникнуть ситуация, когда в потоковой передаче событий модели записи устарели, а в источнике событий — нет. Поэтому важно принимать решение по текущему состоянию.
Впрочем, между потоковой передачей событий и источником событий есть некоторые сходства. Оба подхода используются в микросервисной архитектуре, чтобы улучшить масштабируемость и производительность всей системы. Хотя хранилища и потоки событий различаются по устойчивости состояния, они необходимы для предоставления текущих состояний событий приложений. Однако, потоковая передача событий оптимальна для передачи данных в движении, отделяя продюсеров от потребителей, и упрощает публикацию миллионов сообщений с высокой производительностью. Источник событий помогает воссоздать их историю, сохраняя каждое новое состояние объекта в журнале, предназначенном только для добавления. В источнике событий данные существуют в состоянии покоя, поскольку события неизменяемы. Однако, потоки событий включают в себя данные, которые всегда находятся в пути, проходя между несколькими системами хранения и приложений.
Таким образом, потоковая передача событий и источник событий помогают координировать события в EDA-архитектуре, позволяя создать надежную и высокопроизводительную систему. Потоковая передача событий использует разделенный шаблон pub-sub для непрерывной потоковой передачи данных из различных источников. Хотя инструменты потоковой передачи событий могут обладать надежным хранилищем, они не предназначены для длительного хранения сообщений, поскольку функции долговременного хранения нужны для обеспечения отказоустойчивости. Источник событий добавляет новое событие в текущий список событий в упорядоченном порядке, поэтому может выступать в качестве источника достоверной информации для надежного аудита и получения текущего состояния событий в любое время. Шаблон Event Sourcing отлично подходит для страхования, медицины и других доменов с жесткими нормативными и аудиторскими требованиями. А потоковая передача событий имеет решающее значение в приложениях финансовой торговли, где действия имеют ограниченное по времени окно и требуют немедленных действий.
Узнайте больше про современные архитектуры для аналитики больших данных на специализированных курсах в нашем лицензированном учебном центре обучения и повышения квалификации для разработчиков, менеджеров, архитекторов, инженеров, администраторов, Data Scientist’ов и аналитиков Big Data в Москве:
Источники
