protobuf против gRPC


101

Я пытаюсь понять protobuf и gRPC и то, как я могу их использовать. Не могли бы вы помочь мне понять следующее:

  • Учитывая модель OSI , где, например, находится Protobuf на уровне 4?
  • Подумав о передаче сообщений, как обстоят дела с «потоком», что делает gRPC, что пропускает protobuf?
  • Если отправитель использует protobuf, может ли сервер использовать gRPC или gRPC добавляет что-то, что может доставить только клиент gRPC?
  • Если gRPC может сделать возможной синхронную и асинхронную связь, Protobuf предназначен только для маршалинга и, следовательно, не имеет ничего общего с состоянием - true или false?
  • Могу ли я использовать gRPC во внешнем приложении вместо REST или GraphQL?

Я уже знаю - или предполагаю, что знаю - что:

Протобуф

  • Бинарный протокол для обмена данными
  • Разработано Google
  • Использует сгенерированное описание типа "Struct" на клиенте и сервере для отмены - / - маршаллинга сообщения

gRPC

  • Использует protobuf (v3)
  • Опять из гугла
  • Платформа для вызовов RPC
  • Также использует HTTP / 2
  • Возможна синхронная и асинхронная связь

Я снова предполагаю, что это простой вопрос для тех, кто уже использует эту технологию. Я все еще буду благодарен вам за терпение и помощь. Я также был бы очень благодарен за любое сетевое глубокое погружение в технологии.

Ответы:


85

Буферы протокола - это (есть?) Язык определения интерфейса и библиотека сериализации:

  • Вы определяете свои структуры данных в его IDL, т.е. описываете объекты данных, которые хотите использовать.
  • Он предоставляет процедуры для преобразования ваших объектов данных в двоичный файл и из него, например, для записи / чтения данных с диска.

gRPC использует тот же IDL, но добавляет синтаксис «rpc», который позволяет вам определять сигнатуры методов удаленного вызова процедур, используя структуры данных Protobuf в качестве типов данных:

  • Вы определяете свои структуры данных
  • Вы добавляете свои определения метода rpc
  • Он предоставляет код для обслуживания и вызова сигнатур методов по сети.
  • Вы по-прежнему можете сериализовать объекты данных вручную с помощью Protobuf, если вам нужно

Отвечая на вопросы:

  1. gRPC работает на уровнях 5, 6 и 7. Protobuf работает на уровне 6.
  2. Когда вы говорите «передача сообщения», Protobuf не касается самой передачи. Он работает только на обоих концах любой передачи данных, превращая байты в объекты.
  3. Использование gRPC по умолчанию означает, что вы используете Protobuf . Вы можете написать свой собственный клиент, который использует Protobuf, но не gRPC, для взаимодействия с gRPC, или подключить другие сериализаторы к gRPC, но использование gRPC будет проще.
  4. Правда
  5. Да, ты можешь

Не могли бы вы сказать мне, о каких "слоях" вы говорите? Пожалуйста, дайте мне ссылку, чтобы подробно разобраться в этой концепции. Спасибо.
Милли Хадсон,

Это модель OSI - добавлена ​​ссылка в вопросе. Спорный вопрос, принадлежит ли gRPC к уровням 5 и 6, потому что он использует протокол уровня 7 ( HTTP/2), но он определенно выполняет функции этих уровней.
Питер Уишарт,

67

На самом деле gRPC и Protobuf - это две совершенно разные вещи. Позвольте мне упростить:

  • gRPC управляет способом взаимодействия клиента и сервера (точно так же, как веб-клиент / сервер с REST API)
  • protobuf - это просто инструмент сериализации / десериализации (как и JSON)

У gRPC есть 2 стороны: сторона сервера и сторона клиента, которая может дозваниваться до сервера. Сервер предоставляет RPC (т. Е. Функции, которые можно вызывать удаленно). И у вас есть много вариантов: вы можете защитить связь (с помощью TLS), добавить уровень аутентификации (с помощью перехватчиков), ...

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

При этом вы можете комбинировать и то, и другое для создания хорошей системы клиент / сервер: gRPC будет вашим кодом клиент / сервер, а protobuf - вашим протоколом данных.

PS: Я написал этот документ, чтобы показать, как можно шаг за шагом построить клиент / сервер с gRPC и protobuf с помощью Go.


3
Спасибо, это помогает мне реализовать образец.
lony

7

grpc - это фреймворк, созданный Google, и он используется в производственных проектах самого Google, а #HyperledgerFabric построен с использованием grpc, есть много приложений с открытым исходным кодом, созданных с помощью grpc

protobuff - это представление данных, такое как json, это также Google, на самом деле у них есть несколько тысяч прото-файлов, созданных в их производственных проектах

grpc

  • gRPC - это фреймворк с открытым исходным кодом, разработанный Google.
  • Это позволяет нам создавать запросы и ответы для RPC и обрабатывать остальное с помощью фреймворка.
  • REST ориентирован на CRUD, но grpc ориентирован на API (без ограничений)
  • Создавайте поверх HTTP / 2
  • Обеспечивает >>>>> аутентификацию, балансировку нагрузки, мониторинг, ведение журнала
  • [HTTP / 2]
    • HTTP1.1 был выпущен в 1997 году очень давно.
    • HTTP1 открывает новое TCP-соединение с сервером при каждом запросе
    • Не сжимает заголовки
    • НЕТ сервера, он просто работает с Req, Res
    • HTTP2 выпущен в 2015 году (SPDY)
    • Поддерживает мультиплексирование
    • клиент и сервер могут отправлять сообщения параллельно через одно и то же TCP-соединение
    • Значительно снижает задержку
    • HTTP2 поддерживает сжатие заголовков
    • HTTP2 является двоичным
      • proto buff является двоичным, поэтому он отлично подходит для HTTP2
  • [ТИПЫ]
    • Унарный
    • клиентская потоковая передача
    • потоковая передача на сервер
    • Двунаправленная потоковая передача
    • Серверы grpc по умолчанию являются асинхронными
    • клиенты grpc могут быть синхронизированными или асинхронными

протобафф

  • Буферы протокола не зависят от языка
  • Буферы протокола синтаксического анализа (двоичный формат) менее загружают процессор
  • [Именование]
    • Используйте верблюжий регистр для имен сообщений
    • underscore_seperated для полей
    • Используйте Camelcase для перечислений и CAPITAL_WITH_UNDERSCORE для имен значений
  • [Комментарии]
    • Поддержка //
    • Поддержка /* */
  • [Преимущества]
    • Данные полностью типизированы
    • Данные полностью сжаты (меньшее использование полосы пропускания)
    • Схема (сообщение) нужна для генерации кода и чтения кода
    • Документация может быть встроена в схему
    • Данные можно читать на любом языке
    • Схема может безопасно развиваться в любое время
    • быстрее, чем XML
    • код генерируется для вас автоматически
    • Google изобрел protobuf, они используют 48000 сообщений protobuf и 12000.proto файлов.
    • Многие структуры RPC, включая grpc, используют буферы протокола для обмена данными.

3
Сжатие НЕ снижает загрузку ЦП. Вы должны сжимать и распаковывать его, чтобы отправить или использовать данные в сериализации, что сжигает ЦП. ДЕЙСТВИЕ . Сжатие делает для вас уменьшение сериализованного следа, уменьшения потенциальной нагрузки на память, использования диска, если используется для сериализации на диск, или более провод сигнальный.
Svartalf

@Svartalf отредактировал, чтобы исправить это. Спасибо, что указали на это!
swrobel
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.