Comments 10
Event-sourcing на Kafka перестал быть антипаттерном?
- “Apache Kafka is not for Event Sourcing” by Jesper Hammarbäck https://link.medium.com/7k18T5czyV
- Why there will be no Kafka EventStore in prooph. https://www.sasaprolic.com/2018/03/why-there-will-be-no-kafka-eventstore.html
- Stack overflow. https://stackoverflow.com/a/49868866/899911
И так далее. Собственно, сам Грег Янг об этом прямо говорил, но не могу найти с телефона ссылку.
Для агрегации (схлопывания, дегидрации) событий в конечную версию модели Kafka действительно не очень подходит, ибо нет возможности выбрать события только для заданного идентификатора. То есть, либо выбирать все-все события и фильтровать подряд руками, что далеко не производительно. Либо под каждый идентификатор (или группу) — отдельный топик, но Kafka плохо дружит с зашкаливающем кол-вом топиков, ведь все-таки Kafka — это последовательный лог.
В статье же, Kafka не используется в данном ключе, а используется только как надежный доставщик событий. Где потом эти события хранятся, хранятся ли вообще, и в каком виде (чистом или агрегированном) — уже вопрос каждого микросервиса отдельно.
Event-sourcing на Kafka — вещь типичная.
Половина первого предложения моего комментария — цитата из статьи, я не проставил сразу кавычки; так как писал с телефона, отредактировать комментарий после отправки не смог, прошу прощения.
Кроме того, в статье прямо говорится (выделение моё):
Кратко, что мы сделали:
- ...
- ...
- Максимальный вариант — полноценный event sourcing, state transfer, при котором event содержит всю информацию, необходимую для обработки: откуда и в какой статус перешли, как именно поменялись данные и пр. Вопрос только в целесообразности и в объеме информации который вы можете себе позволить хранить.
В рамках запуска Refund Tool мы использовали третий вариант. Это упростило обработку событий, поскольку не нужно добывать подробную информацию, плюс исключило сценарий, когда каждое новое событие порождает всплеск уточняющих get-запросов от потребителей.
Могу предположить, что автор доклада использует неверную терминологию (event sourcing невозможен без event store), особенно с учётом продолжения, что несколько сбивает с толку.
Кроме того, описание нюансов подсказывает, что не раскрыты некоторые важные детали. Например, сказано, что порядок важен, но в разделе о partitioning совершенно не упомянуто, что порядок сообщений гарантируется только в пределах одной partition. Ну, и вообще складывается ощущение (верю, что ошибочное), что определённые главы из, скажем, IDDD от Вернона Вона и различные материалы типа Versioning in an Event Sourced System от Грега Янга помогли бы избежать некоторых шероховатостей при проектировании.
Почему Kafka плохо подходит под Event Sourcing я понимаю, спасибо, сам рассматривал в своё время этот продукт в качестве event bus + event store, но отказался в результате. Вопрос как раз и возник для того, чтобы понять: а не изменилось ли что.
P.S. Вообще, любопытно наблюдать, как используемые инструменты порождают сами по себе проблемы, которых при выборе других инструментов можно было бы избежать либо которые решаются "из коробки". Говорю ни в коем случае не в качестве критики: это очень амбивалентный вопрос, одновременно и философский, и практический; каждая команда для себя самостоятельно выделяет набор плюсов и минусов.
Я с Эликсир работаю, а там есть ES-фреймворк сommanded с адаптерами под "родной" (в смысле, под библиотеку от того же разработчика — slashdotslash — на Elixir поверх postgresql) EventStore и под Event Store от Грега Янга. Так как проект ещё в разработке, пока родной EventStore.
slashdotslash писал в своё время неплохую статью Building a CQRS/ES web application in Elixir using Phoenix, где как раз используется библиотека, и у него в процессе написания книга Building Conduit о написании точного клона Medium.com (проект RealWorld) на Elixir в парадигме CQRS/ES.
Но это, конечно, Elixir-специфичная вещь, которая, к тому же, предлагает подписку на события прямо из коробки, без внешней event bus.
Если более в общем, то под Event Store Грега Янга есть адаптеры под разные языки, насколько я знаю. Но, опять же, "два в одном".
Events-bus Или автобус событий
Я конечно понимаю, что это ирония, но лучше бы исправить, т.к некоторые читатели могут воспринять этот вариант перевода всерьез.
И делите ли вы как-то в названии топики командные (в которых могут передаваться модели) и событийные?
Опыт разработки сервиса Refund Tool с асинхронным API на Kafka