Как безопасно изменить схему события, если его одновременно читают независимо разворачиваемые потребители?
Безопасное изменение схемы требует явного контракта, проверки совместимости до публикации и поэтапного перехода потребителей. Обычно новое поле добавляют как необязательное с безопасным значением по умолчанию, не меняя смысл и тип существующих полей; совместимость проверяет реестр схем или аналогичный механизм контроля.
Такая проверка защищает от структурных поломок, но не гарантирует сохранение бизнес-смысла. Поэтому изменение схемы должно включать правила версионирования, порядок rollout и проверку фактического поведения потребителей.
В централизованных системах изменение структуры данных часто можно синхронно выполнить вместе с изменением приложения. В распределённых потоках данных производитель и потребители разворачиваются независимо, а одно событие может обрабатываться множеством команд и сервисов.
Из-за этого появилась потребность отделить публикацию данных от жизненного цикла конкретного приложения. Схемы сообщений, политики совместимости и реестры схем решают исходную проблему: изменение формата должно быть проверяемым контрактом, а не устной договорённостью между командами.
Предположим, производитель начинает отправлять событие с изменённым типом существующего поля или удаляет поле, которое старый потребитель считает обязательным. Новый производитель может успешно работать, но старый потребитель начнёт отклонять сообщения, неверно интерпретировать значения или аварийно завершаться.
Особенно опасны изменения, которые формально проходят синтаксическую проверку, но меняют семантику: например, значение в секундах начинают передавать в миллисекундах. Последствия включают потерю сообщений, задержку обработки, некорректные аналитические показатели и необходимость срочного отката.
Сначала фиксируют схему события в машиночитаемом виде: имена полей, типы, обязательность, допустимые значения и правила эволюции. Перед публикацией новой версии проверяют её относительно используемых версий потребителей.
Наиболее безопасное распространённое изменение — добавление необязательного поля. Старые потребители его игнорируют, а новые должны корректно работать, если поле отсутствует. Удаление или переименование поля обычно требует более длительного перехода: сначала перестают использовать старое поле, затем добавляют новое, после миграции потребителей удаляют прежнее.
Важны направления совместимости:
Выбор политики зависит от порядка обновления. Если производитель обновляется раньше потребителей, нужна защита старых читателей от новых сообщений. Если потребители обновляются заранее, важна способность новых читателей обрабатывать старый формат. При независимых поставках часто выбирают полную совместимость, но она ограничивает допустимые изменения.
Проверка схемы не заменяет управление rollout. Нужно определить владельца контракта, отслеживать версии потребителей, проверять реальные сообщения и иметь план отката. Для несовместимого изменения используют новую версию события или отдельный поток, а не незаметно меняют смысл существующего поля.
Компромисс состоит в том, что строгая совместимость снижает риск поломок, но замедляет развитие модели. Слабые правила ускоряют изменения, однако переносят стоимость на потребителей и эксплуатацию. Кроме того, schema registry контролирует структуру, но не бизнес-правильность данных, диапазоны значений и соответствие доменной семантике.
Платёжный сервис публикует событие о списании средств. Нужно добавить признак способа оплаты, при этом старые потребители строят отчёты и рассчитывают комиссии.
Рассматривались три варианта. Изменить существующее поле означало бы риск неправильной интерпретации старыми потребителями. Создать полностью новый тип события обеспечило бы изоляцию, но потребовало бы одновременной поддержки двух потоков и усложнило маршрутизацию. Остановить публикацию на время миграции было бы проще концептуально, но недопустимо из-за требований к непрерывности обработки.
Выбрали добавление необязательного поля с заранее определённым значением для старых сообщений и проверкой обратной совместимости. Сначала обновили потребителей, чтобы они игнорировали отсутствие нового поля, затем включили его публикацию у производителя. После подтверждения обработки старое поведение сохранили для исторических сообщений, а в мониторинг добавили контроль доли событий с новым признаком.
Такой вариант не потребовал синхронного релиза и не изменил смысл существующих полей. Главный результат — постепенная миграция без остановки потока; при этом отдельно пришлось проверить, что значение по умолчанию не искажает финансовую аналитику.
Нет. Нужно проверить, что сериализатор действительно допускает отсутствие поля, потребители используют корректное значение по умолчанию, а новое поле не меняет трактовку существующих. Также необходимо учитывать ограничения конкретного формата сообщений и используемой политики совместимости.
Схемная совместимость отвечает на вопрос, сможет ли потребитель разобрать сообщение. Бизнес-контракт дополнительно определяет смысл полей, единицы измерения, диапазоны, обязательные взаимосвязи и допустимые переходы состояний. Сообщение может успешно десериализоваться, но стать неправильным для расчёта комиссии или отчёта.
Новую версию оправданно вводить, когда нельзя сохранить требуемую совместимость: меняется смысл поля, тип не имеет безопасного преобразования, удаляется обязательная информация или меняется модель взаимодействия. Версии нужно поддерживать ограниченное время, назначить план миграции и определить момент вывода старого контракта; иначе версионирование превращается в постоянное дублирование потоков.