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

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

Интерфейс

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

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

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

Исходя из определения интерфейса в файле .proto, gRPC предоставляет плагины Protocol Compiler, которые генерируют клиентские и серверные 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. Это позволяет осуществлять тонкое управление памятью, используемой для буферизации сообщений в полете.