> For the complete documentation index, see [llms.txt](https://docs.system-analyst-base.ru/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.system-analyst-base.ru/hard-skills/integracii/vidy-integracii/asinkhronnoe-vzaimodeistvie/grpc.md). # gRPC ## RPC {% hint style="info" %} **RPC (**remote procedure call**)** — это форма взаимодействия клиент-сервер, в которой используется удаленный вызов функции, а не обычный вызов HTTP. Идея в том, что мы можем вызвать и выполнить функцию где-то на удаленной системе, как если бы это была локальная функция. {% endhint %} Клиент отправляет запрос процессу на сервере, который постоянно прослушивает удаленные вызовы. В запросе есть вызываемая серверная функция и все передаваемые параметры. Процесс ловит запрос и выполняет его. Взаимодействие между клиентом и сервером происходит так, как если бы клиентский API-запрос был локальной операцией или запрос — внутренним кодом сервера. RPC использует IDL (Interface Definition Language - язык описания интерфейса) как форму контракта на вызываемые функции и тип данных. ## gRPC {% hint style="info" %} **gRPC (Google Remote Procedure Calling)** — система удаленного вызова процедур, разработанная компанией Google. {% endhint %}
📎 Расшифровка "g" в gRPC Google как расшифровка литеры G — лишь одно из возможных значений. В зависимости от версии GRPC разработчики перебирают разные варианты расшифровок. Например, good для версии 1.1, generous для 1.8, game для 1.25 (с примером перечня можно ознакомиться на [ресурсе](https://grpc.github.io/grpc/core/md_doc_g_stands_for.html)). Перебор вариантов не несет особой смысловой нагрузки и является одной из пасхалок, которые так любит компания.
## Архитектура gRPC

Запрос-ответ gRPC

### HTTP/2 HTTP/1.1 долгое время оставался актуальным, затем в 2015 году, появился HTTP/2, который дополнил HTTP/1.1. Так, HTTP/2 стал самым популярным транспортный протоколом в Интернете. HTTP/2 — одна из важных причин, почему gRPC может работать так хорошо. Расширение работы HTTP/2 включает: * способы двоичного кадрирования информации (HTTP 1.1 работает с текстовыми данными) * обеспечение полного [мультиплексирования ](#user-content-fn-1)[^1]для распараллеливания запросов * возможность работы в полнодуплексном режиме с одновременной отправкой запросов клиента и получением ответов от сервера * механизмы потоковой передачи наборов данных как со стороны клиента, так и от сервера * приоритизацию сообщений * сжатие заголовков передаваемых пакетов данных, уменьшающее траффик в сети Все это возможно благодаря бинарной природе протокола HTTP/2 и позволяет микросервисам эффективно обмениваться информацией как в различных симплексных (однонаправленных) режимах, так и используя полноценное дуплексное (двунаправленное) соединение с одновременными приемом и передачей сообщений. Посмотреть разницу в производительности между HTTP2 и HTTP1.1 можно по [ссылке](https://imagekit.io/demo/http2-vs-http1). ### Protocol Buffer (Protobuf) {% hint style="info" %} **Protobuf** — буферный протокол сериализации (бинарного преобразования) структурированных данных (аналог JSON или XML). Это наиболее часто используемый IDL для gRPC. Здесь вы храните свои данные и функциональные контракты в виде так называемого прото-файла. {% endhint %}
JSON vs Protobuf gRPC по умолчанию использует ProtoBuf из-за его высокой производительности и эффективности. Однако, gRPC также поддерживает JSON и другие форматы, что делает его гибким для различных сценариев использования. Подробнее про сравнение протоколов сериализации: [Protobuf vs JSON](/hard-skills/integracii/vidy-integracii/asinkhronnoe-vzaimodeistvie/grpc/protobuf-vs-json.md)
Преобразование данных в двоичный формат не зависит от программной платформы, что позволяет объединять микросервисы, реализованные на разных языках программирования. В отличие от структурированных данных текстовых форматов, таких как XML или JSON, бинарный формат позволяет эффективно сжимать пакеты сообщений при наличии ограничений на размер пакета (например, в каналах связи с невысокой пропускной способностью). ### Режимы взаимодействия API gRPC GRPC предусматривает четыре возможных режима взаимодействия сервера и клиента: * **Однонаправленный (Unary gRPC)**, когда после каждого запроса клиент ждет ответа от сервера. * **Потоковая передача сервера (Server streaming gRPC)**, когда в ответ на запрос клиента сервер предоставляет поток сообщений. Для завершения передачи сервер посылает сообщение о состоянии. * **Потоковая передача клиента (Client streaming GRPC)**, когда сервер принимает поток сообщений от клиента и отвечает одним подтверждающим сообщением. * **Двунаправленный обмен (Bidirectional streaming GRPC)** с разделением каналов передачи сервера и клиента. В этом случае потоки сообщений одновременно передаются в обоих направлениях. ### Преимущества * **Высокопроизводительные удаленные вызовы процедур** Используя Protobuf и HTTP/2, сервисы gRPC обеспечивают в 10 раз более высокую производительность и защиту API по сравнению с взаимодействием REST+JSON. Благодаря использованию подталкивания сервера, мультиплексирования и сжатия заголовков, HTTP/2 обеспечивает высокопроизводительное ранжирование сервисов gRPC. Мультиплексирование позволяет устранить задержку в головной части линии, а server push дает возможность HTTP/2 передавать материал с сервера на клиент до того, как он потребуется. При использовании HTTP/2 сообщения сжимаются более эффективно, что приводит к более быстрой загрузке сервисов gRPC. * **Потоковая передача** Описание услуг для потоковых сервисов gRPC уже включает в себя принципы потокового вещания на стороне клиента или сервера. В результате создание клиентов gRPC и потоковых сервисов значительно упрощается. * **Генерация кода** Генерация кода для gRPC клиентских и gRPC серверных программ является ключевым компонентом gRPC веб-подхода. Для генерации кода из файла .proto модули gRPC используют компилятор .protoc. Формат Protobuf контролируется через генерацию кода в gRPC, который используется для определения форматов данных и конечных точек приложения. Он может создавать сетевые заглушки на стороне клиента и скелеты на стороне сервера, что сокращает время на разработку программ с различными сервисами в gRPC services. * **Интероперабельность** Многочисленные системы и языки программирования, такие как Java, Ruby, Go, C# и другие, поддерживаются ресурсами и библиотеками gRPC. Используя эти языки программирования, разработчики могут создавать производительные приложения, используя полную кросс-платформенную совместимость с gRPC. Это достигается благодаря бинарной форме подключения Protobuf и эффективной генерации кода практически для всех систем. * **Безопасность** Безопасность API обеспечивается в gRPC с помощью HTTP/2 через сквозную зашифрованную сессию TLS. gRPC способствует внедрению SSL/TLS для шифрования данных и аутентификации между сервером и клиентом gRPC. * **Производительность и удобство использования** Поскольку gRPC является полной альтернативой RPC, он работает без проблем на широком спектре систем и языков. gRPC также обладает отличным инструментарием, при этом многие необходимые шаблоны кода генерируются вручную. Инженеры теперь могут больше сосредоточиться на основной функциональности благодаря значительной экономии времени при использовании gRPC. ### Недостатки * **Недостаточная зрелость** Развитие технологии может быть существенным барьером для ее принятия. Это также очевидно при использовании gRPC. GraphQL Один из аналогов gRPC имеет более 14k запросов на StackOverflow, в то время как на gRPC на данный момент только чуть меньше 4k. Сообществу gRPC не хватает знаний о лучших практиках, решениях и успехах, потому что за пределами Google не так много программистов для HTTP/2, а также буферов протокола. Однако, по мере расширения сообщества gRPC и привлечения новых разработчиков, эта ситуация со временем изменится. * **Ограниченная поддержка браузеров** Поскольку ни один из существующих браузеров gRPC не может обрабатывать фреймы HTTP/2, вы не можете эффективно вызывать сервис gRPC из браузера, так как gRPC Web в основном зависит от HTTP/2. В результате вы должны использовать прокси-сервер с gRPC, что имеет ряд недостатков. * **Нечитаемость человеком** В отличие от XML и JSON, файлы Protobuf не читаются человеком, поскольку данные сжимаются до двоичного формата. Разработчики должны использовать дополнительные инструменты, такие как протокол отражения сервера и командная строка gRPC для оценки полезной нагрузки, устранения неполадок и создания ручных запросов. * **Крутая кривая обучения** В отличие от REST и GraphQL, которые в основном используют JSON, потребуется некоторое время, чтобы познакомиться с буферами протокола и открыть для себя методы борьбы с трениями HTTP/2. ## Примеры использования 1. **Коммуникация микросервисов:** gRPC широко используется в архитектурах микросервисов для обеспечения бесперебойной связи между различными сервисами. Его эффективный формат двоичной сериализации (буферы протокола) и поддержка потоковой передачи делают его идеальным для обработки больших объемов данных и связи в реальном времени. 2. **Приложения реального времени.** Благодаря поддержке двунаправленной потоковой передачи и отправки данных на сервер gRPC хорошо подходит для создания приложений реального времени, таких как чат-приложения, аналитика в реальном времени и системы отслеживания в реальном времени. Источники: * * * * * * [^1]: потоковая передача, которая позволяет выполнять несколько процессов (запрос/ответ) в рамках одного соединения