автордың кітабынан сөз тіркестері gRPC: запуск и эксплуатация облачных приложений. Go и Java для Docker и Kubernetes
Маршалинг — процесс преобразования параметров и удаленной функции в пакет, который отправляется по сети. В результате данный пакет преобразуется в вызов метода.
1 Ұнайды
Часто возникает необходимость в хорошо масштабируемой технологии IPC со слабой связанностью, которая была бы более эффективной по сравнению с REST. Именно эту роль берет на себя gRPC — современный стиль межпроцессного взаимодействия для создания распределенных приложений и микросервисов (мы сравним gRPC и REST позже в данной главе). gRPC в основном использует синхронные запросы и ответы, но вместе с тем имеет полностью асинхронный или потоковый режим, доступный после установления соединения.
Когда gRPC-клиент обращается к gRPC-сервису, его gRPC-библиотека выполняет удаленный вызов процедуры по HTTP/2, используя Protocol Buffers и маршалинг. Серверная сторона распаковывает полученный запрос и вызывает соответствующую процедуру с помощью Protocol Buffers. Затем аналогичным образом сервер возвращает ответ клиенту. Для передачи данных gRPC задействует HTTP/2 — высокопроизводительный двоичный протокол обмена сообщениями с поддержкой двунаправленности.
Маршалинг — процесс преобразования параметров и удаленной функции в пакет, который отправляется по сети. В результате данный пакет преобразуется в вызов метода.
для генерации серверного или клиентского кода (а также стандартного кода Protocol Buffers). Для этого в Protocol Buffers предусмотрен компилятор protoc
// ProductInfo.proto
syntax = "proto3";
package ecommerce;
service ProductInfo {
rpc addProduct(Product) returns (ProductID);
rpc getProduct(ProductID) returns (Product);
}
message Product {
string id = 1;
string name = 2;
string description = 3;
}
message ProductID {
string value = 1;
}
Определение сервиса начинается с указания версии Protocol Buffers (proto3), которую мы используем.
Имена пакетов позволяют предотвратить конфликты имен между типами сообщений и также применяются для генерации кода.
Определение интерфейса gRPC-сервиса.
Удаленный метод для добавления товара, который возвращает ID этого товара в качестве ответа.
Удаленный метод для получения товара по его ID.
Определение формата/типа сообщений Product.
Поле (пара «имя — значение»), хранящее ID товара. Обладает уникальным номером, с помощью которого его можно идентифицировать в двоичном формате сообщений.
Пользовательский тип для идентификационного номера товара.
Определение интерфейса сервиса хранится в proto-файле — обычном текстовом файле с расширением .proto. gRPC-сервисы описываются в стандартном формате Protocol Buffers; при этом параметры методов RPC и типы возвращаемых значений указываются в виде сообщений.
В качестве IDL для определения интерфейса сервисов gRPC использует Protocol Buffers (https://oreil.ly/iFi-b) — расширяемый механизм сериализации структурированных данных, который не зависит от языка и платформы
На основе спецификации сервиса можно сгенерировать серверный код (или серверный каркас), который упрощает создание логики на серверной стороне за счет предоставления абстракций для низкоуровневого взаимодействия. Вы также можете сгенерировать клиентский код (или клиентскую заглушку), инкапсулирующий низкоуровневые аспекты коммуникационного протокола в разных языках программирования.
При разработке gRPC-приложения первым делом нужно определить интерфейс сервисов. Данное определение содержит информацию о том, как потребители могут обращаться к вашим сервисам, какие методы можно вызывать удаленно, какие параметры и форматы сообщений следует применять при вызове этих методов и т.д. Язык, который используется в спецификации сервиса, называется языком описания интерфейсов (interface definition language, IDL)