Для чего используются Apache Thrift и Google Protocol Buffers?

Я вижу, что Thrift и Protocol Buffers много упоминаются, но я не понимаю, для чего они используются. Исходя из моего ограниченного понимания, они в основном используются, когда вы хотите сделать сериализацию на разных языках, т.е. Когда у вас есть некоторые структуры данных на одном языке, которые вы хотите отправить в другую программу, написанную на другом языке.

Это правильно? Используются ли они для чего-либо еще?

(Из моего еще ограниченного понимания, я думаю, что Thrift и Protocol Buffers - это в основном две разные версии одной и той же вещи - не стесняйтесь исправлять меня или разрабатывать.)

Ответ 1

В основном это протоколы сериализации. Каждый раз, когда вам нужно передавать данные между машинами или процессами или хранить их на диске и т.д., Он должен быть сериализован.

Xml/json/etc работают нормально, но у них есть определенные накладные расходы, которые делают их нежелательными - в дополнение к ограниченным функциям они относительно большие и вычислительно дорого обрабатываются в любом направлении. Размер может быть улучшен путем сжатия, но это еще больше увеличивает стоимость обработки. У них есть то преимущество, что они доступны для человека, но: большинство данных не читаются людьми.

Теперь люди могли бы потратить много времени на ручную работу с утомительными, искаженными ошибками, субоптимальными, не переносимыми форматами, которые являются менее подробными, или они могут использовать проверенные широкоформатные форматы сериализации, которые хорошо документированы, кросс-платформенные, дешевый для обработки и разработанный людьми, которые тратят далеко слишком долго, беспокоясь о сериализации, чтобы быть дружественными - например, версия толерантна. В идеале это также позволит использовать нейтральный для платформы уровень описания (думаю, "wsdl" или "mex" ), который позволяет вам легко сказать "вот как выглядят данные" для любого другого разработчика (не зная, какие инструменты/язык/платформа они), и они безболезненно потребляют данные без написания нового сериализатора/десериализатора с нуля.

Вот где заходят протобуф и бережливость.

В большинстве случаев по объему я бы ожидал, что оба конца будут в одной и той же технологии в одной компании: просто они должны получить данные от A до B с минимумом суеты и накладных расходов, или им нужно сохраните его и загрузите позже (например, мы используем protobuf внутри redis blobs в качестве вторичного кеша).