Kafka Streams Architecture

Question

Я надеюсь прояснить несколько идей о потоках Кафки с архитектурной точки зрения.

Я понимаю, что используются потоковая обработка и обогащение данных, и что эти данные могут быть повторно использованы другими приложениями, если они возвращаются в Kafka, но какова правильная реализация потокового приложения?

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

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

Answer 1

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

В архитектуре, управляемой событиями, куда приложение будет отправлять события (и каким образом), если вы считаете, что темы Kafka не должны быть предназначением для обмена событиями с другими приложениями?У вас есть другие предпочтения?

Если эти данные используются несколькими службами, то каждая из них материализует свою собственную таблицу, верно?

Да, это один из вариантов.

Другим вариантом является использование функции интерактивных запросов в KStreams (иначе запрашиваемое состояние), которая позволяет вашему первому приложению напрямую представлять свои таблицы и хранилища состояний другим приложениям (например, через REST API).).Тогда другим приложениям не нужно было бы материализовывать свои собственные таблицы.Однако архитектурный недостаток заключается в том, что теперь у вас есть прямая связь между вашим первым приложением и любыми другими последующими приложениями через связь запрос-ответ.В то время как этот шаблон прямой межсервисной связи популярен для архитектуры микросервисов, убедительной альтернативой является не использовать прямую связь, а вместо этого позволить микросервисам / приложениям связываться друг с другом косвенно через Kafka (то есть использовать предыдущую опцию).

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

Это вопрос предпочтения, см. Выше.Чтобы сообщить свое мышление, вы можете прочитать мини-серию из 4 частей об управляемых событиями архитектурах с Kafka: https://www.confluent.io/blog/journey-to-event-driven-part-1-why-event-first-thinking-changes-everything (отказ от ответственности: эта серия блогов была написана моим коллегой).