Сериализация и Schema Registry

В прошлом уроке мы добились, чтобы каждая оплата «Гонца» дала ровно одну проводку. Но для Kafka сообщение это просто байты. Что внутри, знают только продюсер и консьюмеры, и знают по договорённости. В понедельник разработчик приложения заказов поменял поле amount с числа на строку, и биллинг упал на первом же заказе. Сегодня разберём, как такие договорённости записывают и проверяют до того, как они сломают прод.

Бланк заказа

В типографии «Гонца» печатают бланки заказов: номер, сумма, подпись. Бланки заполняют курьеры, а бухгалтерия их разбирает. В новой версии бланка добавили графу «чаевые». Что будет со стопкой старых бланков, где этой графы нет?

Если бухгалтер знает правило «нет графы, значит чаевых ноль», всё в порядке. Если правила нет, он застрянет на первом же старом бланке. А если в новом бланке вместо графы «сумма» напечатали «сумма прописью», бухгалтер не прочтёт ни один новый бланк.

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

Байты и схема

Продюсер превращает объект в байты, это делает сериализатор, мы встречали его в уроке про продюсеры. Консьюмер собирает объект обратно. Формат байтов выбирают сами:

Формат	Как выглядит	Что с договорённостью
JSON	текст {"orderId":"order-9001","amount":690}	имена полей в каждом сообщении, типы нигде не записаны
Avro	компактные байты без имён полей	сообщение читается только вместе со схемой
Protobuf	компактные байты с номерами полей	схема в файле .proto

JSON удобен глазам, но ничего не обещает: продюсер может прислать "amount":"690" строкой, и узнает об этом только упавший консьюмер. В Avro и Protobuf структура записана в схеме, а без неё байты не прочесть. Значит, схема должна лежать там, где её найдут все.

Вот схема события «заказ создан» на Avro. Это обычный JSON:

{
  "type": "record", "name": "OrderCreated",
  "fields": [
    {"name": "orderId", "type": "string"},
    {"name": "amount", "type": "int"}
  ]
}

Schema Registry

Schema Registry это та самая папка с образцами. Отдельный сервис рядом с Kafka, в самой Kafka его нет. Работает он так:

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

Схемы хранятся по субъектам: у значения топика orders субъект по умолчанию orders-value. Каждая новая регистрация это новая версия субъекта.

Главное: реестр не примет новую версию, если она ломает договорённость. Как именно «ломает», задаёт режим совместимости.