#apache-kafka
#apache-kafka
Вопрос:
В сценарии, когда несколько типов событий одного домена создаются для одной темы, и только подмножество типов событий используется потребителем, мне нужен хороший способ прочитать тип события, прежде чем предпринимать действия. Я вижу 2 варианта:
- Поместите тип события (пример «ORDER_PUBLISHED») в само тело сообщения (полезную нагрузку), что было бы похоже на независимый от брокера подход и имело бы другие преимущества. Но это потребовало бы разбора каждого сообщения только для того, чтобы узнать тип события.
- Используйте заголовки сообщений Kafka, которые позволили бы использовать сообщения без дополнительного анализа полезной нагрузки.
Контекст — это источник событий. Небольшие команды, небольшие полезные нагрузки. Нет огромных тел для анализа. Golang. Все сообщения являются протобуфами. gRPC.
Каков типичный рабочий процесс в таком сценарии.
Я попытался поискать в Google по этой теме, но не нашел много примеров использования заголовков и рекомендуемых практик. Было бы здорово услышать, когда и как использовать заголовки сообщений Kafka, а когда не использовать.
Комментарии:
1. Я думаю, что заголовки в любом случае должны быть общими. Нет никаких «рекомендаций» о том, как их использовать, однако вам все равно необходимо проанализировать эту информацию, чтобы знать, как обрабатывать данные, нет?
2. Создайте специальную тему для каждого типа события. confluent.io/blog/put-several-event-types-kafka-topic
3. @JRibkr В связанной статье говорится, что НЕ следует создавать специальные темы для типов событий. Несколько типов событий, которые применяются к одному и тому же агрегату или сущности, должны быть представлены в одной теме. Это необходимо для того (извините за каламбур), чтобы обрабатывать их по порядку. Это также помогает логике приложения следовать принципу проектирования логической централизации .
Ответ №1:
Очевидно, что один и тот же раздел следует использовать для разных типов событий, которые применяются к одному и тому же объекту / агрегату (ссылке). Пример: BookingCreated, BookingConfirmed, BookingCancelled и т.д. Все должны переходить в одну тему, чтобы (извините за каламбур) гарантировать заказ доставки (в этом случае идентификатор бронирования является ключом сообщения).
Когда потребитель получает одно из этих событий, ему необходимо определить тип события, проанализировать полезную нагрузку и соответствующим образом перенаправить к логике обработки. Тип события — это часть метаданных сообщения, которая позволяет эту идентификацию.
Таким образом, я думаю, что пользовательский заголовок сообщения Kafka — лучшее место для указания типа события. Я не одинок:
-
Фелипе Дутра: «Kafka позволяет вам помещать метаданные в заголовок вашего сообщения. Поэтому используйте его для размещения информации о сообщении, версии, типе, идентификаторе корреляции. Если у вас есть цепочка событий, вы также можете добавить идентификатор корреляции opentracing «
-
В этой системе GE ERP есть заголовок с надписью «тип события», чтобы показать «Тип события, которое публикуется» в разделе kafka (например, «ProcessOrderEvent»).
-
В этом другом решении упоминается, что «Заголовок ‘event’ с типом события включен в каждое сообщение» в их интеграции с Kafka.
Заголовки являются новыми в Kafka. Кроме того, насколько я видел, книги Kafka посвящены 17 тысячам параметров конфигурации Kafka и топологии Kafka. К сожалению, нам нелегко найти много информации о том, как архитектура, управляемая событиями, может быть отображена с надлежащей семантикой на элементы брокера сообщений Kafka.
Комментарии:
1. Спасибо, что уделили время написанию этого ответа. Этот вопрос был уже довольно старым, и сейчас я работаю в немного другой области. Но лично я также считаю, что заголовки — хороший вариант. Также … я мог бы добавить аргумент против размещения каждого типа сообщения в отдельной теме — поступая таким образом, вы должны начать беспокоиться о таких вещах, как синхронизированные атомные часы, чтобы правильно установить временные метки сообщений. При определенных скоростях передачи сообщений становится действительно важной проблемой, если каждый тип события домена / объекта выделяется в отдельные разделы. Чтобы избежать подобных проблем, лучше использовать single topic.
2. М. Клеппманн в статье confluent.io/blog/put-several-event-types-kafka-topic говорится, что … если вам нужны надежные гарантии упорядочения, тогда вам следует рассмотреть отдельную тему, что в значительной степени логично. Таким образом, синтаксический анализ типа события должен быть реализован у потребителей. И если вы должны выбирать события по их типу (события обработки несколькими потребителями), то анализ каждого отдельного сообщения требует затрат на обработку. Вот почему использование заголовков сообщений кажется наиболее эффективным способом, но менее переносимым.
3. Да, и действительно, его статья — первая ссылка, на которую я ссылался. Я просто хотел бы, чтобы Клеппманн также описал эффективные методы разграничения типов событий в рамках темы.