Что объединяет между собой такие удачные патерны реализации надежных высоконагруженных систем как CQRS, Event Sourcing, EDA? Все эти паттерны оперируют с потоками событий. Но при всей простоте концепции готовых инструментов для ее реализации на удивление мало и популярностью пользуется среди них фактически только один: Kafka.
Надо сказать что часто люди не делают различия между концепциями потоков событий и очередей сообщений, что приводит к недопониманию и недооценки эффективности использования потоков событий. Но достаточно абстракных разговоров, передем к сути.
Что такое потоки событий и что их отличает от очередей: потоки событий подразумевают длятельное хранение сообщений при сохраниеии их последовательности. Каждое сообщение в потоке имеет совй порядковый номер. Такаие особенности потоков событий имеют очевидные существенные преимущества перед брокерами сообщений:
- У вас всегда есть возможность обрабатывать не только текущие события но и историю событий которая вам доступна автоматически, без дополнительных усилий с вашей стороны
- Добавление новых получателей не влияет на объем данных которые обрабатывает сервер, все получатели читают события из одних и тех-же потоков
- Появляется недоступная другими путями возможнсоть легко реализовать гарантированную доставку события в правильной последовательности и без потерь. А это дорогого стоит, если конечно для вас важна надежность разрабатываемого вами софта
- Прослеживаемость — всегда можно посмотреть историю событий и как на них отреагировали ваши микросервисы и во многих случаях даже повторно обработать эти события если есть необходимость
- Расширяемость системы — всегда есть возможность добавить новый микросервис или отчет и скормить ему всю историю собыий
Как твроится чудо? Как обеспечивается гарантированная доставка в правильной последовательности и обработка каждого события только один раз? Это довольно просто сделать имея взможность получить любое событие по номеру. Микросервис при получении события обрабатывает его и при внесении измнений своего состояния в базу данных добавляет номер этого события. Если что-то пошло не так и микросервис в этот момент был остановлен, после запуска он получает из базы номер последнего обработанного события и начинает обрабатывать остальные собфтия начиная со следующего, это гарантирует что событие не повлияет на состояние микросервиса дважды и не будет потеряно.
Конечно есть и некоторые вопросы которые надо будет решать в таких системах, например что делать при изменении структуры событий при обновлении микросервисов которые эти события генерируют или как долго хранить историю и на какую глубину, яот делать если были сгенерированы и записаны некорректные события. Но эти вопросы не уникальны для потоков событий, подобные сложности возникают при работе с любыми хранилищами данных и я думаю тут можно что-то придумать или подсмотреть у других. Возможно я поразмышляю на эту тему в следующих постах.
И подводя итог хочу вас обрадовать, если вы не очень любите Kafka за ее тяжеловесность есть еще NATS с его JetStream и незаслуженно обойденный вниманием EventStoreDb. Да, за подобными системами будущее и я вам предлагаю уже сейчас к этому будущему прикоснуться, тем более многие уже давно этим пользуются.