gRPC
быстрее REST за счёт бинарной сериализации HTTP/2
RPC
RPC (remote procedure call) — это форма взаимодействия клиент-сервер, в которой используется удаленный вызов функции, а не обычный вызов HTTP. Идея в том, что мы можем вызвать и выполнить функцию где-то на удаленной системе, как если бы это была локальная функция.
Клиент отправляет запрос процессу на сервере, который постоянно прослушивает удаленные вызовы. В запросе есть вызываемая серверная функция и все передаваемые параметры. Процесс ловит запрос и выполняет его. Взаимодействие между клиентом и сервером происходит так, как если бы клиентский API-запрос был локальной операцией или запрос — внутренним кодом сервера.
RPC использует IDL (Interface Definition Language - язык описания интерфейса) как форму контракта на вызываемые функции и тип данных.
gRPC
gRPC (Google Remote Procedure Calling) — система удаленного вызова процедур, разработанная компанией Google.
Архитектура gRPC
HTTP/2
HTTP/1.1 долгое время оставался актуальным, затем в 2015 году, появился HTTP/2, который дополнил HTTP/1.1. Так, HTTP/2 стал самым популярным транспортный протоколом в Интернете.
HTTP/2 — одна из важных причин, почему gRPC может работать так хорошо.
Расширение работы HTTP/2 включает:
способы двоичного кадрирования информации (HTTP 1.1 работает с текстовыми данными)
обеспечение полного для распараллеливания запросов
возможность работы в полнодуплексном режиме с одновременной отправкой запросов клиента и получением ответов от сервера
механизмы потоковой передачи наборов данных как со стороны клиента, так и от сервера
приоритизацию сообщений
сжатие заголовков передаваемых пакетов данных, уменьшающее траффик в сети
Все это возможно благодаря бинарной природе протокола HTTP/2 и позволяет микросервисам эффективно обмениваться информацией как в различных симплексных (однонаправленных) режимах, так и используя полноценное дуплексное (двунаправленное) соединение с одновременными приемом и передачей сообщений.
Посмотреть разницу в производительности между HTTP2 и HTTP1.1 можно по ссылке.
Protocol Buffer (Protobuf)
Protobuf — буферный протокол сериализации (бинарного преобразования) структурированных данных (аналог JSON или XML). Это наиболее часто используемый IDL для gRPC. Здесь вы храните свои данные и функциональные контракты в виде так называемого прото-файла.
Преобразование данных в двоичный формат не зависит от программной платформы, что позволяет объединять микросервисы, реализованные на разных языках программирования. В отличие от структурированных данных текстовых форматов, таких как 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.
Примеры использования
Коммуникация микросервисов: gRPC широко используется в архитектурах микросервисов для обеспечения бесперебойной связи между различными сервисами. Его эффективный формат двоичной сериализации (буферы протокола) и поддержка потоковой передачи делают его идеальным для обработки больших объемов данных и связи в реальном времени.
Приложения реального времени. Благодаря поддержке двунаправленной потоковой передачи и отправки данных на сервер gRPC хорошо подходит для создания приложений реального времени, таких как чат-приложения, аналитика в реальном времени и системы отслеживания в реальном времени.
Источники:
Last updated
