📬 Пост 45. Что такое Schema Registry и зачем он нужен в Kafka
Когда команда только начинает работать с Kafka, сообщения часто выглядят примерно так: { "orderId": 123, "status": "PAID" } Все счастливы. Потом появляется второй сервис. Потом третий. Потом десятый. И внезапно начинается веселье: • кто-то удалил поле • кто-то поменял тип данных • кто-то переименовал status в state • consumer упал в проде • интеграция сломалась
Именно для решения этих проблем появился Schema Registry.
⚙️ Что такое Schema Registry Schema Registry - это отдельный сервис, который хранит схемы сообщений. Проще говоря: если Kafka хранит сами сообщения, то Schema Registry хранит описание того, как эти сообщения должны выглядеть. Можно представить его как библиотеку контрактов или единый справочник структур данных для всей компании.
⚙️ Что такое схема Схема описывает структуру сообщения. Например: { "type": "record", "name": "OrderEvent", "fields": [ { "name": "orderId", "type": "long" }, { "name": "status", "type": "string" } ] }
Такая схема говорит: • поле orderId обязательно • тип - число • поле status обязательно • тип - строка То есть это уже не "пример сообщения", а полноценный контракт.
⚙️ Где хранится Schema Registry Очень частый вопрос на собесах. Schema Registry НЕ хранится внутри Kafka. Это отдельный сервис. Схематично выглядит так: Producer │ ▼ Schema Registry │ ▼ Kafka │ ▼ Consumer
Обычно это отдельное приложение, которое поднимается рядом с Kafka.
⚙️ Что хранится внутри Registry Для каждой схемы сохраняется: • уникальный идентификатор (schemaId) • версия схемы • сам текст схемы
⚙️ Что происходит при отправке сообщения Представим, что продюсер хочет отправить: { "orderId": 123, "status": "PAID" }
Последовательность такая: 1️⃣ Продюсер обращается в Schema Registry Говорит: "У меня есть схема OrderEvent"
2️⃣ Registry проверяет наличие схемы Если схема уже зарегистрирована: возвращает её ID Например: schemaId = 17 3️⃣ Продюсер сериализует данные Через Avro, Protobuf или JSON Schema. Получается бинарный payload.
4️⃣ В Kafka отправляется Не схема целиком. А только: [schemaId][payload] Например: 17 + бинарные данные (это как раз согласно авро формату)
⚙️ Что делает Consumer со всем эти делом Consumer получает сообщение. Видит: schemaId = 17 Дальше: 1️⃣ идет в Schema Registry 2️⃣ получает схему №17 3️⃣ десериализует сообщение 4️⃣ получает объект То есть потребитель всегда знает, как правильно читать данные.
⚙️ Зачем нужен Schema Registry На практике задач много:
⚪️ Единый контракт Все сервисы работают по одной схеме. Нет ситуации: "я думал это строка" "а мы сделали integer"
⚪️ Контроль качества данных Если сообщение не соответствует схеме: оно вообще не отправится. Например: Схема ожидает: { "orderId": "long" } А приходит: { "orderId": "hello" } Получим ошибку сериализации.
⚪️ Управление версиями Schema Registry умеет хранить: v1 v2 v3 v4 Это позволяет эволюционировать контракты без поломок.
⚪️ Контроль совместимости Одна из главных фишек. Registry может запрещать опасные изменения. Например:
- удаление обязательного поля
- изменение типа string → int
- изменение структуры, ломающей старых потребителей
⚙️ Где Registry хранит схемы Технически схемы обычно лежат в специальном внутреннем Kafka-топике. Например у Confluent Schema Registry: _schemas То есть: Kafka хранит данные схем. А Schema Registry предоставляет API для работы с ними. Получается интересная рекурсия
⚙️ Что будет, если Registry упадет Частый вопрос на интервью. Новые схемы зарегистрировать не получится. Но многие клиенты используют локальный кэш. Поэтому уже известные схемы обычно продолжают работать.
⚠️ Что Schema Registry НЕ делает Он не:
- хранит сообщения
- маршрутизирует сообщения
- валидирует бизнес-логику
- заменяет Kafka Это исключительно сервис управления схемами.
