Kafka с событиями домена - PullRequest
Новая
       123

Kafka с событиями домена

0 голосов
/ 09 мая 2020

В моем управляемом событиями проекте у меня есть сообщения типа Commands, а в ответ я получаю Events.

Эти Commands и Events сообщения express домен, поэтому они содержат сложные типы из домена.

Пример: 

RegisterClientCommand(Name, Email)

ClientRegisteredEvent(ClientId)

В домене еще десятки таких пар команд и событий.

Я думал о чем-то вроде: 

RawMessage(payloadMap, sequenceId, createdOn)

Полезная нагрузка будет содержать имя типа класса домена сообщения и поля сообщения.

Я также читал о формате Avro, но, похоже, много работы по определению формата сообщения для каждого сообщения.

Каков наилучший метод с точки зрения формата сообщений, которые фактически передаются через брокеров Kafka?

1 Ответ

1 голос
/ 09 мая 2020

Не существует единственного «лучшего» способа сделать это, все будет зависеть от опыта вашей команды / организации и конкретных c требований к вашему проекту.

Самому Kafka безразлично, что сообщения действительно содержат. В большинстве случаев он просто видит значения сообщений и ключи как непрозрачные массивы байтов. преобразовать его в Kafka, потому что этого требует KafkaProducer. Возможно, у вас уже есть настраиваемый сериализатор строк, может быть, вы можете сериализовать POJO в JSON с помощью Jackson или чего-то подобного. Или, может быть, вы просто отправляете в качестве сообщения огромную строку, разделенную запятыми. Это полностью зависит от вас.

Важно то, что потребитель, когда он извлекает сообщение из kafka topi c, может правильно и надежно прочитать данные из каждого поля в сообщении, без каких-либо ошибки, конфликты версий и т. д. c. Большинство существующих механизмов serde / schema, таких как Avro, Protobuf или Thrift, пытаются облегчить вам эту работу. Особенно сложные вещи, такие как обеспечение обратной совместимости новых сообщений с предыдущими версиями того же сообщения.

  • Большинство людей в конечном итоге используют комбинацию:
    • механизмов Serde для создания байта массивы для создания в Kafka, некоторые популярные: Avro , Protobuf , Thrift .
    • Raw JSON strings
    • Огромная строка с каким-то внутренним / настраиваемым форматом, который может анализироваться / анализироваться.
  • Некоторые компании используют централизованную службу схем. Это сделано для того, чтобы вашим потребителям данных не нужно было заранее знать, какую схему содержит сообщение, они просто извлекают сообщение и запрашивают соответствующую схему у службы. У Confluent есть собственное решение для реестра с настраиваемой схемой, которое поддерживает Avro в течение многих лет, а через несколько недель go официально поддерживает Protobuf. Это не требуется , и если вы владеете сквозным производителем / потребителем, вы можете решить выполнить сериализацию самостоятельно, но многие люди к этому привыкли.
  • В зависимости от типа сообщения иногда требуется сжатие, потому что сообщения могут быть очень повторяющимися и / или большими, поэтому в конечном итоге вы сэкономите довольно много места для хранения и пропускной способности, если отправляете сжатые сообщения, за счет некоторой загрузки ЦП и задержка. С этим также можно справиться самостоятельно на стороне производителя / потребителя, сжимая массивы байтов после того, как они были сериализованы, или вы можете запросить сжатие сообщений непосредственно на стороне производителя (ищите compression.type в документации Kafka).
...