Обзор концепций gRPC

Удаленные процедурные вызовы (RPC) предоставляют полезное абстрактное представление для создания распределенных приложений и услуг. Библиотеки в этом репозитории предоставляют конкретную реализацию протокола gRPC, основанную на HTTP/2. Эти библиотеки обеспечивают коммуникацию между клиентами и серверами с использованием любых комбинаций поддерживаемых языков.

Интерфейс

Разработчики, использующие gRPC, начинают с языкового независимого описания RPC-сервиса (коллекции методов). На основе этого описания gRPC генерирует клиентские и серверные интерфейсы в любом из поддерживаемых языков. Сервер реализует сервисный интерфейс, который может быть удаленными вызовами клиентского интерфейса.

По умолчанию gRPC использует Protocol Buffers в качестве языка описания интерфейса (IDL) для описания как сервисного интерфейса, так и структуры сообщений-посылок. В случае необходимости можно использовать другие альтернативы.

Вызов и обработка удаленных вызовов

Начиная с описания интерфейса в файле .proto, gRPC предоставляет плагины компилятора протоколов, которые генерируют API для клиентов и серверов. Пользователи gRPC вызывают эти API на стороне клиента и реализуют соответствующие API на стороне сервера.#### Синхронные и асинхронные вызовы Синхронные RPC-вызовы, которые блокируются до получения ответа от сервера, являются наиболее близким приближением к абстракции процедурного вызова, к которой стремится RPC.

С другой стороны, сети по своей природе асинхронны, и в многих сценариях желательно иметь возможность начать RPC-вызовы без блокировки текущего потока.

Поверхность программирования gRPC на большинстве языках представлена как синхронные и асинхронные варианты.

Стриминг

gRPC поддерживает семантику стриминга, где либо клиент, либо сервер (или оба) отправляют поток сообщений на одном RPC-вызове. Самый общий случай — двунаправленный стриминг, где один gRPC-вызов устанавливает поток, в котором как клиент, так и сервер могут отправлять поток сообщений друг другу. Отправленные сообщения доставляются в том же порядке, в котором они были отправлены.

ПротоколПротокол gRPC определяет абстрактные требования для коммуникации между

клиентами и серверами. Конкретная реализация на основе HTTP/2 завершает картину, предоставляя подробности каждого из требуемых операций.

Абстрактный протокол gRPC

gRPC-вызов состоит из двунаправленного потока сообщений, инициированного клиентом. В направлении клиент-сервер этот поток начинается с обязательного заголовка Call Header, за которым следуют опциональные Initial-Metadata, а затем ноль или более Payload Messages. Клиент сигнализирует о завершении своего потока сообщений с помощью нижнего уровня протокола. В направлении сервер-клиент содержится опциональное Initial-Metadata, за которым следуют ноль или более Payload Messages, завершающиеся обязательным Status и опциональными Status-Metadata (также известными как Trailing-Metadata).## Реализация через HTTP/2 Абстрактный протокол, определённый выше, реализуется через HTTP/2. Двунаправленные потоки gRPC отображаются на HTTP/2 потоки. Содержимое Call Header и Initial Metadata отправляется в виде HTTP/2 заголовков и подвергается сжатию HPACK. Payload Messages сериализуются в байтовый поток, состоящий из фреймов gRPC с префиксом длины, которые затем фрагментируются в HTTP/2 фреймы на стороне отправителя и собираются обратно на стороне получателя. Status и Trailing-Metadata отправляются в виде HTTP/2 завершающих заголовков (также известных как trailers). Клиент сигнализирует о завершении своего потока сообщений, устанавливая флаг END_STREAM на последнем фрейме DATA.

Для подробного описания см. doc/PROTOCOL-HTTP2.md.

Управление потоком

gRPC использует механизм управления потоком из HTTP/2. Это позволяет осуществлять тонкий контроль за использованием памяти для буферизации сообщений, находящихся в пути.