Вопросы по использованию Apache Kafka Streams для реализации микросервисов источников событий

Question

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

Apache Kafka - это потрясающая платформа, которая благодаря Apache KafkaAPI Streams объявляется как инструмент, который позволяет нам реализовать эту парадигму с помощью ее многочисленных функций (развязка, отказоустойчивость, масштабируемость ...): https://www.confluent.io/blog/event-sourcing-cqrs-stream-processing-apache-kafka-whats-connection/

С другой стороны, есть несколько статейотговаривая нас от использования его для поиска событий: https://medium.com/serialized-io/apache-kafka-is-not-for-event-sourcing-81735c3cf5c

Вот мои вопросы относительно пригодности потоков Кафки в качестве источника событий:

1. Статья вышеродом из Йеспера Хаммарбека (работает на serialized.io, платформу для поиска событий).Я хотел бы получить ответ на основные проблемы, которые он поднимает:

   • Загрузка текущего состояния .На мой взгляд, с уплотнением журналов и хранилищами состояний это не проблема.Я прав?

   • Последовательные записи .

2. При перемещении определенных функций в потоки Кафки я не уверен, что они подходят естественным образом:

   • Аутентификация и безопасность : представьте, что ваши клиенты хранятся в государственном хранилище, созданном по теме клиента.Должны ли мы хранить их пароли в теме / магазине?Звучит недостаточно безопасно, не так ли?Тогда как мы должны управлять этим аспектом наличия клиентов в государственном магазине и их паролей в другом месте?Любая рекомендуемая хорошая практика?

   • Запросы : Интерактивные запросы - хороший инструмент для создания запрашиваемых представлений наших данных (по ключу).Можно получить сущность по идентификатору, но как насчет сложных запросов (объединений) ?Нужно ли нам генерировать хранилищ состояний по запросу ?Например, один магазин для покупателей по идентификатору, другой для клиентов по штатам, другой магазин для клиентов, которые приобрели продукт в прошлом году ... Это не звучит управляемо.Другим моментом является отсутствие нумерации страниц : как мы можем обрабатывать большие наборы данных при запросах к хранилищам состояний?Еще один момент, мы больше не можем делать динамические запросы (как API критериев JPA).Это может привести к CQRS, может быть?Сложность продолжает расти таким образом ...

   • Рост данных : с базами данных мы привыкли иметь тысячи и тысячи строк на таблицу.Приложения Kafka Streams хранят локальное хранилище состояний, которое со временем будет расти и расти.Насколько это масштабируемо?Как хранится это локальное хранилище (локальный диск / ОЗУ)?Если это диск, мы должны обеспечить приложения достаточным пространством, если оперативной памяти достаточно.

Answer 1

1. Загрузка текущего состояния: механизм, описанный в блоге, о реакции текущего состояния ad-hoc для одного объекта действительно будет дорогостоящим сКафка.Однако потоки Кафки следуют философии, чтобы сохранить текущее состояние для всех объектов в KTable (который распределен / разорван).Таким образом, этого никогда не требуется - конечно, это связано с определенными затратами памяти.

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

3. Я не уверен, каково будет точное требование.В текущей реализации Kafka Streams не предлагает никаких специфичных для магазина функций аутентификации или безопасности.Хотя для безопасности можно сделать несколько вещей: (а) зашифровать локальный диск: это может быть самым простым способом защиты данных.(2) зашифруйте сообщения в рамках бизнес-логики, прежде чем поместить их в хранилище.

4. Интерактивные запросы предлагают ограниченную поддержку по многим причинам (не хотят вдаваться в подробности), и этоникогда не был разработан с целью поддержки сложных запросов.Идея заключается в стремлении вычислить результат, который можно получить с помощью простого поиска.Как вы указали, это не очень масштабируемо (затратно), если у вас много разных запросов.Чтобы решить эту проблему, имеет смысл загрузить данные в базу данных и позволить БД делать то, для чего она собирается.Один только Kafka Streams не является подходящим инструментом для этого банкомата - однако, нет причин не объединять оба.

5. По умолчанию Kafka Streams использует RocksDB для сохранения локального состояния (вы можете переключитьсяв магазины в памяти тоже).Таким образом, можно записывать на диск и использовать очень большое состояние.Конечно, вам необходимо соответствующим образом подготовить свои экземпляры (см. https://docs.confluent.io/current/streams/sizing.html).. Кроме того, Kafka Streams масштабируется по горизонтали и полностью эластичен. Таким образом, вы можете добавлять новые экземпляры в любой момент времени, позволяя хранить террабайтысостояния, если у вас большие диски и достаточно экземпляров. Обратите внимание, что количество разделов входной темы ограничивает число экземпляров, которые вы можете использовать (внутренне Kafka Streams является группой потребителей, и вы не можете иметь больше экземпляров, чем разделов). Если этоЭто проблема, в первую очередь рекомендуется разделить входные темы.