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

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

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

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

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

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

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

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

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

пожалуйста, посмотрите на eventuate.IO microservices open source framework, чтобы узнать больше о потенциальных проблемах:http://eventuate.io/

обновление от 8 февраля 2018

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

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

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

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

2. для магазина событий я рекомендую superior Postgresql расширение называется TimescaleDB, которое фокусируется на высокопроизводительной обработке данных timeseries (события-это timeseries) в большом объеме. Конечно, CQRS, источник событий (replay и т. д. характеристики) построены в рамках light4j из коробки которая использует Postgres как низкое хранение.

3. для обмена сообщениями попробуйте посмотреть на хронику очередь, карта, двигатель, сеть. Я имею в виду избавиться от этой старомодный брокер центральный решения и идут с микро-системой сообщений (врезанной одной). Очередь хроник на самом деле даже быстрее, чем Кафка. Но я согласен, что это не все в одном решении, и вам нужно сделать некоторую разработку, иначе вы идете и покупаете корпоративную версию (платную). В конце концов, попытка построить из Chronicle свой собственный уровень обмена сообщениями будет оплачена, удалив бремя поддержания кластера Кафки.

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

ТЛ;ДР: да или нет, в зависимости от вашего использования поиска события.

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

нисходящие обработчики событий = Yes

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

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

применение-контролируемый источник истины = нет

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

отсутствие изоляции сущности

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

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

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

дополнительная информация

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

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

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

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

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

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

о:

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

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