Форматы обмена данными: от JSON до protobuf

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

Почему формат — это архитектурное решение

Выбор формата данных часто воспринимают как мелочь: «ну JSON же, что тут думать». А зря. Формат напрямую влияет на производительность, масштабируемость, надёжность и — что нередко забывают — на удобство отладки. Один и тот же поток данных в текстовом виде читается глазами и отлично дебажится, но занимает больше места и медленнее парсится. В бинарном — наоборот: компактно и быстро, но без специальных инструментов ты в этот поток даже не заглянешь.

Поэтому «какой формат выбрать» — это не вопрос вкуса, а вопрос требований. Тебе важнее скорость разработки или пропускная способность? Строгая валидация или гибкость? Ответы на них и определяют, что ты положишь в основу интеграции. А заодно — это отличный способ проверить архитектурную зрелость собеседника на интервью: спроси, чем Protobuf отличается от JSON и когда он оправдан. Ответ расскажет о человеке больше, чем список фреймворков в резюме.

Текстовая тройка: JSON, XML, YAML

Начнём с того, что читается человеком.

JSON — рабочая лошадка веба. Основной формат для REST и GraphQL: лёгкий, быстро обрабатывается, одинаково понятен и людям, и машинам. Простой синтаксис плюс отличная поддержка практически в любом языке программирования — вот почему он стал форматом по умолчанию. Если сомневаешься, с чего начать интеграцию, начни с JSON и не прогадаешь в девяти случаях из десяти.

XML — тяжеловесный ветеран, который никуда не делся. Он живёт в SOAP-сервисах и до сих пор встречается в корпоративных REST-контурах, где нужна строгая структура и валидация. Главный козырь XML — схемы (XSD): ты можешь заранее описать, как обязаны выглядеть данные, и отбраковывать всё, что не соответствует. Для сложных взаимодействий в банках и энтерпрайзе это не бюрократия, а страховка.

YAML — формат, который в самих API-запросах встречается редко, зато вокруг них он повсюду. Описания API (OpenAPI/Swagger), конфиги, всё, что связано с DevOps, — это YAML. Его любят за то, что он максимально дружелюбен к человеку: читать и редактировать руками приятнее, чем что-либо ещё в этом списке. Данные по проводу им гонять не будешь, но описать ими систему — самое то.

Какой формат в каком API

Формат редко выбирают в вакууме — чаще его диктует тип API, с которым ты работаешь.

REST API — в основном JSON, изредка XML. REST ценят за гибкость и простоту, и JSON под эту философию идеально ложится.
SOAP API — только XML. Строгая валидация и высокий уровень контроля структуры делают его частым выбором там, где цена ошибки высока: банки, страхование, корпоративные интеграции.
GraphQL API — JSON. Здесь фишка в самих запросах: клиент забирает ровно те поля, которые ему нужны, без лишнего балласта.
WebSocket API — обычно JSON, но когда важна производительность и размер сообщений, в дело идут бинарные форматы вроде MessagePack.

Брокеры сообщений: сердцебиение распределённых систем

Отдельная история — брокеры сообщений. В мире микросервисов они работают как кровеносная система, и формат передачи данных здесь напрямую бьёт по производительности и надёжности.

Apache Kafka — лидер для больших данных и стриминга: события, логи, обмен между сервисами. В Kafka уживается целый зоопарк форматов: JSON — для простоты, Avro — за компактность и поддержку эволюции схем, Protobuf — когда нужна бинарная скорость, MessagePack — как компромисс между размером и структурой.

RabbitMQ — универсал для задач, где критична надёжность доставки: очереди, фоновые задачи, микросервисы. Чаще всего внутри ходит JSON, в legacy-контурах попадается XML, а Protobuf подключают, когда нужно ужать сообщения и ускорить обмен.

Apache ActiveMQ и его современная реинкарнация — частый гость корпоративных систем с зоопарком протоколов и высокими требованиями к надёжности. Здесь в ходу JSON и XML, а в связке с документными хранилищами иногда всплывает BSON.

NATS — лёгкий и быстрый брокер, популярный в микросервисах и IoT. По умолчанию JSON, но когда нужно срезать задержки и размер сообщений, берут Protobuf и MessagePack.

Закономерность простая: чем ближе к высокой нагрузке, тем чаще текст уступает место бинарным форматам.

Когда текст становится дорогим

JSON и XML прекрасны, пока данных немного и на первом месте — скорость разработки и лёгкость отладки. Но у текстовых форматов есть неустранимый налог: они многословны. Каждое имя поля, каждая кавычка и скобка — это байты, которые ты гоняешь по сети и парсишь на каждом конце. На потоке в миллионы сообщений этот налог превращается в реальные деньги и реальные задержки.

Вот тут на сцену выходят бинарные форматы. Их идея проста: не таскать с собой структуру в каждом сообщении, а описать её один раз схемой — и передавать только сами данные, упакованные максимально плотно. Разберём три главных.

Protobuf — стандарт де-факто для gRPC

Protocol Buffers от Google — бинарный формат сериализации, где ты описываешь структуру данных схемой, а по ней генерируется код сразу под несколько языков. Он компактнее и быстрее JSON и XML, плюс даёт строгую типизацию — то есть гарантию, что данные соответствуют заданной структуре, и меньше шансов словить ошибку на ровном месте.

Схема выглядит так:

syntax = "proto3";

message Message {
  string sender = 1;
  string text = 2;
}

Где Protobuf особенно к месту:

Высоконагруженные системы и микросервисы — быстрая сериализация и десериализация снижают задержки и объём трафика.
gRPC — Protobuf это его родной формат. Работаешь с gRPC — неизбежно работаешь с Protobuf.
Сложные структуры данных — вложенные объекты, массивы, разные типы описываются и валидируются через схему.

Главные плюсы: компактность и производительность, строгая типизация как защита от кривых данных, поддержка генерации кода для кучи языков. Для того, кто проектирует высоконагруженные архитектуры, знание Protobuf — не опция, а базовый инструмент.

Avro — король эволюции схем

Avro родился внутри экосистемы Apache Hadoop, но быстро вышел за пределы больших данных. Это тоже компактный бинарный формат со схемами, но у него есть суперспособность, ради которой его и любят.

Схема сообщения на Avro:

{
  "type": "record",
  "name": "Message",
  "fields": [
    { "name": "sender", "type": "string" },
    { "name": "text", "type": "string" }
  ]
}

Когда Avro выстреливает:

Большие данные и стриминг — Kafka, Flink и подобные платформы, где поток событий огромный, а формат должен быть лёгким и быстро читаемым.
Сложные структуры — вложенные записи и массивы, а не просто «ключ-значение».
Эволюция схем — вот оно, главное. Ты можешь добавлять новые поля и менять структуру данных, не ломая старые записи и не переписывая всё, что уже накоплено. Для больших систем, где схема неизбежно меняется со временем, это спасает от боли.

Итог по Avro: компактность против текстовых форматов, быстрая сериализация под нагрузкой и гибкость схем без остановки системы. Если ты работаешь с потоками данных, изучить Avro точно стоит.

MessagePack — «JSON, только компактный»

Если JSON кажется громоздким, а Protobuf со схемами и кодогенерацией — избыточным, есть золотая середина. MessagePack стремится быть таким же простым, как JSON, но пакует данные в плотные бинарные сообщения. Бонусом он поддерживает больше типов — например, бинарные строки и расширенные типы, что делает его универсальнее.

Идея на пальцах: берёшь привычный JSON…

{
  "sender": "Владимир",
  "text": "Это пример MessagePack."
}

…и после упаковки в MessagePack те же данные занимают меньше места и летят быстрее. Где он хорош:

Высоконагруженные системы и микросервисы — там, где важны производительность и минимальная задержка.
WebSocket и реальное время — обмен в реальном времени с меньшей нагрузкой на сеть.
Системы с ограниченными ресурсами — IoT и мобильные приложения, где каждый байт на счету.

Главное преимущество MessagePack в том, что он легко встраивается туда, где уже используется JSON: интеграция минимальная, а обмен данными ускоряется почти бесплатно.

Как выбирать

Единственно правильного формата не существует — есть подходящий под задачу. Логика примерно такая:

Нужны простота, скорость разработки и лёгкая отладка — бери JSON (а для конфигов и описаний — YAML).
Нужна строгая структура и валидация в корпоративном контуре — XML со схемами.
Пошла высокая нагрузка, важны компактность и низкие задержки — переходи на бинарные: Protobuf для gRPC и микросервисов, Avro для стриминга и эволюции схем, MessagePack там, где хочется просто ускорить существующий JSON.

Текстовые форматы удобны для человека, но проигрывают в эффективности. Бинарные выигрывают по производительности, но требуют схем и чуть большей дисциплины на старте. Это классический размен, и осознанно сделать его — часть системного проектирования. Чем лучше ты понимаешь эти форматы, тем проще собирать решения, которые работают как надо — а не как у всех.

Впервые опубликовано в моём Telegram-канале @it_underside.

Ваш ДПУПП