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

Один из основных моментов, которые поддерживает Кафка:

• Захват / хранение событий, все ГА, конечно.
• Паб / суб архитектура
• Возможность воспроизведения журнала событий, что позволяет новым подписчикам регистрироваться в системе после факта.

По общему признанию, я не на 100% разбираюсь в CQRS / Event Sourcing, но это кажется довольно близко к тому, каким должно быть хранилище событий. Забавная вещь: я действительно не могу найти так много о том, что Кафка используется в качестве хранилища событий, так что, возможно, я что-то упускаю.

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

По сути, состояние системы сохраняется на основе транзакций / событий, которые система когда-либо получала, вместо простого сохранения текущего состояния / снимка системы, что обычно и делается. (Думайте об этом как о Главной книге в бухучете: все транзакции в конечном итоге сводятся к конечному состоянию). Это позволяет делать разные интересные вещи, но просто читайте по предоставленным ссылкам.

Kafka - это система обмена сообщениями, которая имеет много общего с хранилищем событий, однако процитирую их введение:

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

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

ОБНОВИТЬ

Кафка документация :

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

ОБНОВЛЕНИЕ 2

Одной из проблем, связанных с использованием Kafka для поиска источников, является количество необходимых тем. Обычно в источниках событий имеется поток (тема) событий для каждой сущности (такой как пользователь, продукт и т. Д.). Таким образом, текущее состояние объекта может быть восстановлено путем повторного применения всех событий в потоке. Каждый раздел Kafka состоит из одного или нескольких разделов, и каждый раздел хранится в виде каталога в файловой системе. Также будет давление со стороны ZooKeeper по мере увеличения количества znodes.

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

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

Я думаю, что вы мало что слышите об использовании Kafka для источников событий, в первую очередь потому, что терминология источников событий, кажется, не очень распространена в потребительском веб-пространстве, где Kafka является наиболее популярным.

Я написал немного об этом стиле использования Кафки здесь .

Я продолжаю возвращаться к этому QA. И я не нашел существующие ответы достаточно нюансированные, поэтому я добавляю этот.

TL; DR. Да или Нет, в зависимости от вашего использования источника событий.

Я знаю о двух основных видах систем, основанных на событиях.

Процессоры нижестоящих событий = Да

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

В этом контексте понятно, почему люди Kafka отстаивают его как решение для поиска событий. Потому что это очень похоже на то, как оно уже используется, например, в потоках кликов. Однако люди, использующие термин Event Sourcing (в отличие от Stream Processing), скорее всего, ссылаются на второе использование ...

Контролируемый приложением источник правды = Нет

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

Отсутствие изоляции объекта

В этом сценарии требуется возможность загрузки потока событий для конкретной сущности. Распространенной причиной этого является построение модели переходной записи для бизнес-логики, используемой для обработки запроса. Делать это нецелесообразно в Кафке. Использование темы для каждой сущности может позволить это, за исключением того, что это не начало, когда могут быть тысячи или миллионы сущностей. Это связано с техническими ограничениями в Kafka / Zookeeper.

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

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

Отсутствие обнаружения конфликта

Во-вторых, пользователи могут создавать условия гонки из-за одновременных запросов к одному и тому же объекту. Может быть весьма нежелательно сохранять конфликтующие события и разрешать их по факту. Поэтому важно уметь предотвращать конфликтующие события. Чтобы масштабировать загрузку запроса, обычно используют службы без сохранения состояния, предотвращая конфликты записи с использованием условных записей (запись только, если последним событием объекта был #x). Ака Оптимистичный Параллелизм. Кафка не поддерживает оптимистичный параллелизм. Даже если бы он поддерживал это на уровне темы, он должен был бы быть полностью вплоть до уровня сущности, чтобы быть эффективным. Чтобы использовать Kafka и предотвращать конфликтующие события, вам нужно использовать сериализованный писатель с сохранением состояния на уровне приложения. Это существенное архитектурное требование / ограничение.

Дальнейшая информация

Обновление за комментарий

Комментарий был удален, но вопрос был что-то вроде: что люди тогда используют для хранения событий?

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

В распределенных сценариях я видел несколько разных реализаций. Проект Jet Panther использует Azure CosmosDB с функцией Change Feed для уведомления слушателей. Еще одна похожая реализация, о которой я слышал в AWS, - это использование DynamoDB с функцией Streams для уведомления слушателей. Ключ раздела, вероятно, должен быть идентификатором потока для лучшего распределения данных (чтобы уменьшить объем избыточного выделения ресурсов). Тем не менее, полное воспроизведение через потоки в Динамо является дорогостоящим (чтение и стоимость). Так что это подразумевалось также для Dynamo Streams для выгрузки событий на S3. Когда новый слушатель подключается к сети или существующий слушатель хочет полного воспроизведения, он будет читать S3, чтобы наверстать упущенное.

Мой текущий проект - мультитенантный сценарий, и я перевернул свой собственный поверх Postgres. Что-то вроде Citus кажется подходящим для масштабируемости, разделения по tentant + stream.

Кафка все еще очень полезна в распределенных сценариях. Нетривиальная проблема - выставлять события каждого сервиса другим сервисам. Хранилище событий, как правило, не создается для этого, но это именно то, что делает Кафка хорошо. Каждый сервис имеет свой собственный внутренний источник правды (может быть хранилище событий или другое), но слушает Кафку, чтобы узнать, что происходит «снаружи». Служба также может публиковать события в Кафке, чтобы информировать «извне» об интересных вещах, которые сделал служба.

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

• Kafka гарантирует только один раз доставку, и в хранилище событий есть дубликаты, которые нельзя удалить. Обновление: здесь вы можете прочитать, почему это так сложно с Кафкой, и некоторые последние новости о том, как наконец добиться этого поведения: https://www.confluent.io/blog/exactly-once-semantics-are-possible-heres-how. -apache-Кафка-делает-то /
• Из-за неизменности, нет никакого способа манипулировать хранилищем событий, когда приложение развивается, и события должны быть преобразованы (существуют, конечно, такие методы, как апкастинг, но ...). Однажды может быть сказано, что вам никогда не нужно преобразовывать события, но это неверное предположение, может быть ситуация, когда вы делаете резервную копию оригинала, но вы обновляете их до последних версий. Это действительное требование в управляемых событиями архитектурах.
• Нет места для сохранения снимков сущностей / агрегатов, и воспроизведение будет становиться все медленнее и медленнее. Создание снимков должно быть характерно для хранилища событий в долгосрочной перспективе.
• С учетом того, что разделы Кафки распределены и ими сложно управлять и их резервное копирование сравнивают с базами данных. Базы данных просто проще :-)

Итак, прежде чем сделать свой выбор, подумайте дважды. Хранилище событий как комбинация интерфейсов прикладного уровня (мониторинг и управление), хранилище SQL / NoSQL и Kafka в качестве брокера - лучший выбор, чем предоставление Kafka обеих функций для создания полноценного полнофункционального решения.

Хранилище событий - это сложный сервис, который требует большего, чем может предложить Kafka, если вы серьезно относитесь к использованию источников событий, CQRS, Sagas и других шаблонов в архитектуре, управляемой событиями, и сохраняете высокую производительность.

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

Пожалуйста, посмотрите на фреймворк с открытым исходным кодом для микросервисов eventuate.io, чтобы узнать больше о потенциальных проблемах: http://eventuate.io/

Дополнение от 8.02 2018

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

1. Не используйте Spring - это здорово (я сам часто его использую), но оно тяжелое и медленное одновременно. И это совсем не микросервисная платформа. Это «просто» фреймворк, чтобы помочь вам реализовать его (много работы за этим ..). Другие фреймворки - это "просто" облегченные REST или JPA или фреймворки с различной ориентацией. Я рекомендую, вероятно, лучшую в своем классе полную микросервисную платформу с открытым исходным кодом, которая возвращается к чистым корням Java: https://github.com/networknt

Если вас интересует производительность, вы можете сравнить себя с существующим набором тестов. https://github.com/networknt/microservices-framework-benchmark

2. Ни в коем случае не используйте Кафку :-)) Это наполовину шутка. Я имею в виду, что, хотя Кафка великолепен, это еще одна система, ориентированная на брокеров. Я думаю, что будущее за системами обмена сообщениями без посредников. Вы можете быть удивлены, но есть более быстрые, чем системы Kafka :-), конечно, вы должны перейти на более низкий уровень. Посмотри Хронику.

3. Для хранилища событий я рекомендую улучшенное расширение Postgresql под названием TimescaleDB, которое ориентировано на высокопроизводительную обработку данных временных рядов (события являются временными рядами) в большом объеме. Конечно, CQRS, Event Sourcing (функции воспроизведения и т. Д.) Встроены в фреймворк light4j из коробки, который использует Postgres в качестве места для хранения.

4. Для обмена сообщениями попробуйте взглянуть на Chronicle Queue, Map, Engine, Network. Я имею в виду избавиться от этого старомодного решения, ориентированного на брокера, и использовать микросистему сообщений (встроенную). Хроника очереди на самом деле даже быстрее, чем Кафка. Но я согласен, что это не все в одном решении, и вам нужно заняться разработкой, иначе вы пойдете и купите версию Enterprise (платную). В конце концов, усилия по созданию из Chronicle собственного уровня обмена сообщениями будут оплачены за счет снятия бремени обслуживания кластера Kafka.

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

Что касается:

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

Это может быть сложно. Я подробно рассказал об этом здесь: https://stackoverflow.com/a/48482974/741970

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

Я думаю, что вы должны взглянуть на рамки аксонов вместе с их поддержкой Кафки