Переход от JSON к Protobuf. Стоит ли оно того?

23

У нас есть веб-сервисы REST, которые могут обслуживать XML или JSON (WCF). Я играю с идеей реализации Protobufs. Зачем?

ПРОФИ

Меньшая нагрузка на серверы.
Меньший размер сообщения - меньше трафика.
Теперь легче переключиться, чем позже.

МИНУСЫ

Нужно реализовать
Будет сложнее устранять неполадки / прослушивать сообщения для отладки.
Я могу включить GZip на сервере и JSON будет потреблять столько же трафика

Каково ваше предложение и / или опыт в этом?

web-services wcf serialization

— катит
источник

1

Я посмотрел на страницу википедии, и на самом деле было больше символов на пару ключ-значение, так почему же оно содержит меньше сообщений?

— Рамзи Кахил

Из-за сериализации. Двоичные данные поступают как двоичные (например, байтовые массивы). Кроме того, он не содержит имен свойств в сообщении. Они идут по порядку собственности. developers.google.com/protocol-buffers/docs/encoding#structure

— katit

10

Технически вы ответили на свой вопрос, сожмите JSON и покончите с этим. Самое главное, вы никогда не упоминаете фактическое экономическое обоснование для траты денег и времени на эту деятельность.

39

Превышает ли бизнес ценность их реализации над стоимостью?

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

Так что значение превышает это? Вы сталкиваетесь с выбором «наши расходы на пропускную способность составляют X% наших доходов, и мы не можем это поддержать»? Или даже «нам нужно потратить 20 000 долларов, чтобы добавить серверы для поддержки JSON»?

Если у вас нет насущных потребностей в бизнесе, ваши «плюсы» на самом деле не профи, а преждевременная оптимизация.

— Парсифаль
источник

23

я поддерживаю apis, и кто-то до меня добавил protobuf (потому что это было "быстрее"). Единственное, что быстрее - это RTT из-за меньшей полезной нагрузки, и это можно исправить с помощью gzipped JSON.

Часть, которая мне неприятна, - это относительная работа по поддержке protobuf (по сравнению с JSON). Я использую Java, поэтому мы используем сопоставление объектов Джексона для JSON. Добавление к ответу означает добавление поля в POJO. Но для protobuf мне нужно изменить файл .proto, а затем обновить логику сериализации и десериализации, которая перемещает данные в / из буферов протокола и в POJO. Неоднократно случалось, что случался релиз, когда кто-то добавил поле и забыл вставить код сериализации или десериализации для буферов протокола.

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

Вероятно, из этого можно догадаться, мой совет - не делай этого.

— Kevin
источник

5

Если вы пишете (де) сериализационный код для перемещения данных в POJO, вы делаете это неправильно. Просто используйте сгенерированные протобуфом классы напрямую.

— Марсело Кантос

Я думаю, что в этом случае я перемещался в / из POJO, потому что кодовая база поддерживала запросы и ответы как JSON, XML, так и Protobuf, и учитывая, что я не могу добавить аннотации Джексона и / или JAXB в сгенерированные Protobuf классы, и я хочу чтобы использовать одни и те же объекты модели во всем коде, я не знаю, у меня есть варианты просто использовать сгенерированные классы. Я вижу, как это можно было бы сделать, если бы я писал, скажем, сервисы GRPC, которые говорят только на protobuf.

— Кевин