🚀 gRPC – краткий обзор

gRPC (Google Remote Procedure Call) – open-source фреймворк для работы с удаленными вызовами процедур. Разработан в 2015 году корпорацией Google на основе парадигмы RPC. Применяется для межсистемной интеграции наряду с REST, SOAP и GraphQL.

Особенности gRPC

Основная фишка gRPC – высокая пропускная способность и снижение нагрузки на сеть. Достигается это благодаря тому, что gRPC использует Protoboof и HTTP/2.

💠 Protobuf (Protocol Buffers) – формат сериализации данных в бинарном формате. Он не является человеко-читаемым, но зато дает высокую производительность и низкую нагрузку на сеть. Поддерживается большинством языков программирования.

💠 HTTP/2 – версия протокола HTTP, который поддерживает двунаправленную потоковую передачу (прямо как веб-сокеты), а также позволяет группировать запросы во фреймы. Это удобно, так как в одном канале может быть замультиплексировано несколько запросов, идущих фреймами Сообщения внутри фреймов можно приоритизировать. Благодаря HTTP/2, не нужно заново устанавливать соединение под каждый запрос, весь обмен данными происходит в одном TCP-соединении

⚙️ Принцип работы gRPC

Коммуникация между клиентом и сервером, для которой используется не HTTP-вызов, а вызов процедуры. Клиент вызывает удаленную процедуру, сериализует параметры и дополнительную информацию в сообщении, после чего шлет сообщение на сервер. Приняв данные, сервер производит их десериализацию, выполняет запрошенную операцию и шлет результат обратно клиенту. Сериализация и десериализация параметров осуществляется специальными объектами: stub сервера и stub клиента

Разработка начинается строго с контракта: необходимо сначала описать proto-файлы и затем преобразовать контракт в заглушки для реализации клиента. Для этого существует множество плагинов кодогенерации, написанных Google.

🧩 GRPC предусматривает четыре возможных режима взаимодействия сервера и клиента:

1️⃣ Однонаправленное (Unary GRPC), когда после каждого запроса клиент ждет ответа от сервера.
2️⃣ Потоковая передача сервера, когда в ответ на запрос клиента сервер предоставляет поток сообщений.
3️⃣ Потоковая передача клиента, когда сервер принимает поток сообщений от клиента и отвечает одним подтверждающим сообщением.
4️⃣ Двунаправленный обмен (дуплексный) с разделением каналов передачи сервера и клиента. В этом случае потоки сообщений одновременно передаются в обоих направлениях.

🚧 Ограничения

1. Высокий порог входа. Требуется больше времени и усилий для настройки и развертывания

2. Vendor lock. Google является основным драйвером и определяет направление развития протокола.

3. Сложности балансировки нагрузки. Так как в gRPC устанавливается постоянное соединение с одним сервисом, то неважно, сколько экземпляров сервиса запущено: запросы не будут перераспределяться между экземплярами сервиса.

4. В gRPC не поддерживается трассировка запросов

5. Сообщения в protoboof нечеловекочитаемы

🛠 Применение

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

В следующем посте сравним REST и gRPC по пунктам.


📑 Материалы
1. Что нужно знать о gRPC системному аналитику
2. Что такое gRPC и как он работает — обзорная статья Highload Today
3. Объяснение буферов протокола, потоковой передачи и архитектуры
4. REST vs SOAP, gRPC и GraphQL: стили межсистемной интеграции по API — Babok School
5. gRPC на практике: особенности, преимущества и недостатки — Хабр

#api #интеграции

➿➿➿➿➿➿➿➿
🧑‍🎓 Больше полезного в базе знаний по системному анализу