protobuf проти gRPC

Я намагаюся зрозуміти protobuf та gRPC та те, як я можу використовувати обидва. Не могли б ви допомогти мені зрозуміти наступне:

• Беручи до уваги модель OSI , де де, наприклад, знаходиться Protobuf на рівні 4?
• Думаючи через передачу повідомлень, як відбувається "потік", що gRPC робить те, чого пропускає protobuf?
• Якщо відправник використовує protobuf, чи може сервер використовувати gRPC або gRPC додає щось, що може доставити лише клієнт gRPC?
• Якщо gRPC може зробити синхронний та асинхронний зв’язок можливим, Protobuf призначений лише для маршалінгу, і тому не має нічого спільного із станом - true або false?
• Чи можу я використовувати gRPC у фронтенд-програмі, що спілкується замість REST або GraphQL?

Я вже знаю - або припускаю, що знаю - що:

Протобуф

• Двійковий протокол для обміну даними
• Розроблено Google
• Використовує згенеровану "Структуру", як опис на клієнті та сервері, для повідомлення un - / - marshall

gRPC

• Використовує protobuf (v3)
• Знову від Google
• Рамка для викликів 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 - це 2 абсолютно різні речі. Дозвольте спростити:

• 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 за замовчуванням є Async
  • Клієнти grpc можуть бути синхронізованими або асинхронними

протобуфф

• Буфери протоколів є агностичними для мови
• Розбір буферів протоколів (двійковий формат) є менш інтенсивним процесором
• [Найменування]
  • Для імен повідомлень використовуйте чохол для верблюда
  • підкреслення_відділено для полів
  • Використовуйте верблюд для Enums і CAPITAL_WITH_UNDERSCORE для імен значень
• [Коментарі]
  • Підтримка //
  • Підтримка / * * /
• [Переваги]
  • Дані повністю набрано
  • Дані повністю стискаються (менше використання пропускної здатності)
  • Схема (повідомлення) потрібна для генерації коду та зчитування коду
  • Документація може бути вбудована в схему
  • Дані можна читати будь-якою мовою
  • Схема може розвиватися в будь-який час безпечним чином
  • швидше, ніж XML
  • код генерується для вас автоматично
  • Google винайшов proto buff, вони використовують 48000 повідомлень protobuf та файли 12000.proto
  • Багато RPC-фреймворків, включаючи grpc, використовують буфери протоколів для обміну даними