Давайте Познакомимся С Event Sourcing. Часть 2

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

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

Журнал событий — это очень распространенный шаблон, используемый в сочетании с системами обмена сообщениями (брокер сообщений, промежуточное программное обеспечение, ориентированное на сообщения) и системами обработки потоков событий.

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

Реляционные и документальные модели обычно фокусируются на моделировании сущностей.

В таких моделях текущее состояние можно легко получить, прочитав одну или несколько строк или документов.

Стоит отметить, что источник событий и реляционная модель не являются взаимоисключающими.

Системы источников событий часто включают в себя и то, и другое.

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

Его можно заменить или перестроить путем повторной обработки журнала событий.

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

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

По сути, такое разделение задач и есть CQRS (Command Query Responsibility Segregation, разделение обязанностей на команды и запросы).

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

Помимо технической части, есть и другие моменты, на которые стоит обратить внимание.

Самые большие проблемы обычно возникают из-за мышления разработчика.

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

Теперь основной концепцией должны стать события.

При использовании Event Sourcing много усилий тратится на моделирование событий.

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

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

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

И нельзя забывать об ошибочных и подозрительных событиях при корректной обработке проверки данных.

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

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

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

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

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

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

хранятся.

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

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

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

Или, точнее, немного устаревший.

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

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

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

Одно дело просто записать их после обработки, другое дело работать со всей историей.

Без этой функциональности журнал событий полностью теряет свою ценность.

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

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

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

Необходимо также учитывать структуру событий.

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

Набор полей может измениться.

Могут возникнуть ситуации, когда старые события должны обрабатываться текущей бизнес-логикой.

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

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

Одна из них — облегчить расширение системы в будущем.

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

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

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

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

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

И, наконец, не забывайте самый важный принцип разработки программного обеспечения — стремиться сделать все как можно проще (принцип KISS).