protobuf vs gRPC

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

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

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

Двоичный протокол обмена данными
Разработанный Google
Использует сгенерированное "Struct", как описание на клиенте и сервере, на сообщение un- / -marshall

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

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

Ответы

Ответ 1

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

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

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

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

В ответ на вопросы:

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

Ответ 2

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

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

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

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

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

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

Ответ 3

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

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

.КПГР

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

protobuff

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