Loading AI tools
Из Википедии, свободной энциклопедии
gRPC (Remote Procedure Calls) — это система удалённого вызова процедур (RPC) с открытым исходным кодом, первоначально разработанная в Google в 2015 году. В качестве транспорта используется HTTP/2, в качестве языка описания интерфейса — Protocol Buffers. gRPC предоставляет такие функции как аутентификация, двунаправленная потоковая передача и управление потоком, блокирующие или неблокирующие привязки, а также отмена и тайм-ауты. Генерирует кроссплатформенные привязки клиента и сервера для многих языков. Чаще всего используется для подключения служб в микросервисном стиле архитектуры и подключения мобильных устройств и браузерных клиентов к серверным службам.
GRPC | |
---|---|
Тип | библиотека функций, открытое программное обеспечение и сетевой протокол[вд] |
Разработчик | |
Написана на | Си[1] |
Последняя версия | |
Репозиторий | github.com/grpc/grpc |
Лицензия | Apache License 2.0[3][4] |
Сайт | grpc.io (англ.) |
Сложное использование HTTP/2 в gRPC делает невозможным реализацию клиента gRPC в браузере — вместо этого требуется прокси.
gRPC поддерживает использование TLS и аутентификации на основе токенов. Подключение к сервисам Google должно использовать TLS. Существует два типа учётных данных: учётные данные канала и учётные данные для вызова.
gRPC использует Protocol Buffers для кодирования данных. В отличие от HTTP API с JSON, они имеют более строгую спецификацию.
В gRPC клиентское приложение может напрямую вызывать метод серверного приложения на другом компьютере, как если бы это был локальный объект, что упрощает создание распределенных приложений и служб. Как и во многих системах RPC, gRPC основан на идее определения службы, определяя методы, которые могут быть вызваны удаленно с их параметрами и типами возвращаемых данных. На стороне сервера сервер реализует этот интерфейс и запускает сервер gRPC для обработки клиентских вызовов. На стороне клиента есть заглушка (называемая на некоторых языках просто клиентом), которая предоставляет те же методы, что и сервер.
Клиенты и серверы gRPC могут работать и взаимодействовать друг с другом в различных средах и могут быть написаны на любом из поддерживаемых языков gRPC.
По умолчанию gRPC использует Protobuf как язык определения интерфейса (IDL) для описания интерфейса службы и структуры сообщений полезной нагрузки. При желании можно использовать другие альтернативы.
gRPC позволяет определить четыре типа методов обслуживания:
Начиная с определения службы в .proto
файле, gRPC предоставляет плагины компилятора Protocol Buffers, которые генерируют клиентский и серверный код. Пользователи gRPC обычно вызывают эти API на стороне клиента и реализуют соответствующий API на стороне сервера.
Синхронные вызовы RPC, которые блокируются до тех пор, пока от сервера не поступит ответ, являются наиболее близким приближением к абстракции вызова процедуры, к которому стремится RPC. С другой стороны, сети по своей сути асинхронны, и во многих сценариях полезно иметь возможность запускать RPC, не блокируя текущий поток.
API программирования gRPC на большинстве языков имеет как синхронную, так и асинхронную разновидности.
Клиент отправляет один запрос и получает один ответ.
RPC с потоковой передачей на сервере похож на унарный RPC, за исключением того, что сервер возвращает поток сообщений в ответ на запрос клиента. После отправки всех сообщений клиенту отправляются сведения о состоянии сервера (код состояния и необязательное сообщение о состоянии) и дополнительные конечные метаданные. На этом обработка на стороне сервера завершена. Клиент завершает работу, когда получает все сообщения сервера.
Клиентский RPC с потоковой передачей похож на унарный RPC, за исключением того, что клиент отправляет на сервер поток сообщений вместо одного сообщения. Сервер отвечает одним сообщением (вместе со сведениями о его статусе и дополнительными конечными метаданными), как правило, но не обязательно после того, как он получил все сообщения клиента.
В RPC с двунаправленной потоковой передачей вызов инициируется клиентом, вызывающим метод, и сервером, получающим метаданные клиента, имя метода и крайний срок. Сервер может выбрать отправку своих исходных метаданных или дождаться, пока клиент начнет потоковую передачу сообщений.
Обработка потока на стороне клиента и на стороне сервера зависит от приложения. Поскольку два потока независимы, клиент и сервер могут читать и писать сообщения в любом порядке. Например, сервер может дождаться, пока он получит все сообщения клиента, прежде чем писать свои сообщения, или сервер и клиент могут играть в «пинг-понг» — сервер получает запрос, затем отправляет ответ, затем клиент отправляет другой запрос, основанный на ответе, и так далее.
gRPC позволяет клиентам указать, как долго они готовы ждать завершения RPC, прежде чем RPC завершится с ошибкой. На стороне сервера сервер может запросить, не истек ли тайм-аут определённого RPC или сколько времени осталось для завершения RPC.
Указание крайнего срока или тайм-аута зависит от языка: некоторые языковые API работают в терминах тайм-аутов (продолжительности времени), а некоторые языковые API работают в терминах крайнего срока (фиксированный момент времени) и могут иметь или не иметь крайний срок по умолчанию.
В gRPC и клиент, и сервер делают независимые и локальные определения успешности вызова, и их выводы могут не совпадать. Это означает, что, например, у вас может быть RPC, который успешно завершается на стороне сервера, но терпит неудачу на стороне клиента. Сервер также может принять решение о завершении до того, как клиент отправит все свои запросы.
Клиент или сервер могут отменить RPC в любое время. Отмена немедленно завершает RPC, поэтому дальнейшая работа не выполняется.
Метаданные — это информация о конкретном вызове RPC (например, сведения об аутентификации) в форме списка пар ключ-значение, где ключи являются строками, а значения обычно являются строками, но могут быть двоичными данными. Метаданные непрозрачны для самого gRPC — они позволяют клиенту предоставлять информацию, связанную с вызовом на сервер, и наоборот.
Доступ к метаданным зависит от языка.
Канал gRPC обеспечивает соединение с сервером gRPC на указанном хосте и порту. Используется при создании клиентской заглушки. Клиенты могут указать аргументы канала для изменения поведения gRPC по умолчанию, например включения или выключения сжатия сообщений.
Как gRPC решает закрыть канал, зависит от языка. Некоторые языки также позволяют запрашивать состояние канала.
Ряд различных организаций приняли gRPC, такие как Square, Netflix, IBM, CoreOS, Docker, CockroachDB, Cisco, Juniper Networks,[5] Spotify,[6] и Dropbox.[7]
В проекте с открытым исходным кодом u-bmc вместо IPMI используется gRPC. 8 января 2019 года Dropbox объявил, что следующая версия Courier, их RPC-фреймворк, лежащий в основе их архитектуры SOA, будет переведен на gRPC, прежде всего потому, что он хорошо согласован с их существующими пользовательскими RPC-фреймворками.
Seamless Wikipedia browsing. On steroids.
Every time you click a link to Wikipedia, Wiktionary or Wikiquote in your browser's search results, it will show the modern Wikiwand interface.
Wikiwand extension is a five stars, simple, with minimum permission required to keep your browsing private, safe and transparent.