protobuf против gRPC

Я пытаюсь понять 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
• Возможна синхронная и асинхронная связь

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

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

• Вы определяете свои структуры данных в его 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. Да, ты можешь

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

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

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

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

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

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

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, используют буферы протокола для обмена данными.