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

23

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

ПРОФИ

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

МИНУСЫ

  1. Нужно реализовать
  2. Будет сложнее устранять неполадки / прослушивать сообщения для отладки.
  3. Я могу включить 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.
Кевин