gRPC — прокладывая путь к клиент-серверной коммуникации будущего

Сетевые технологии постоянно прогрессируют. Для удовлетворения растущих потребностей распределенных компьютерных систем была разработана новая система под названием gRPC для удаленных вызовов процедур. Буква «g» означает Google, которая сыграла важную роль в разработке gRPC. Мы объясним, что такое gRPC, как он работает и где используется.

Что такое gRPC?

gRPC — это современная система удаленного вызова процедур, которая чрезвычайно эффективно обрабатывает коммуникации в распределенных архитектурах клиент-сервер, используя инновационные методы. Как и ее предшественница RPC, она работает на уровне процессов. Ключевой особенностью межпроцессного взаимодействия с помощью gRPC является принцип прозрачности: Удаленные экземпляры взаимодействуют настолько тесно и гладко, даже на больших расстояниях, что их общение кажется идентичным локальному общению между внутренними процессами машины.

Изначально gRPC был разработан компанией Google в 2015 году. Сегодня за распространение и развитие коммуникационной технологии отвечает Cloud Native Computing Foundation. gRPC имеет открытый исходный код, то есть исходный код находится в открытом доступе. Сторонним разработчикам разрешается и поощряется вносить изменения и улучшения в код.

По умолчанию gRPC использует HTTP/2 для передачи потоков данных между удаленными компьютерами. Для обработки данных используются буферы протоколов, разработанные Google. Буферы протоколов сохраняются в виде простых текстовых файлов с расширением .proto.

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

Как работает gRPC: многоязычность и эффективность благодаря буферам протокола и HTTP/2

Буферы протоколов (Protobuf) выполняют несколько функций в системе gRPC. Они служат в качестве языка определения интерфейса (IDL) и описывают интерфейс независимым от языка способом. Это означает, что они не привязаны к конкретному языку программирования (например, Java или C). Они также определяют используемые сервисы и предоставляемые функции. Для каждой функции можно указать параметры, которые передаются вместе с запросом, и тип возвращаемого значения, которое можно ожидать.

С удаленной точки зрения буферы протокола служат базовым форматом обмена сообщениями, определяющим структуры, типы и объекты сообщений. Они гарантируют, что клиент и сервер «понимают» друг друга и работают как оптимально эффективная функциональная единица на больших расстояниях.

Последовательность вызова gRPC для запроса к базе данных (например, «Поиск товаров в инвентаре») выглядит следующим образом:

  • Сначала необходимо подготовиться к выполнению поиска. На стороне сервера на основе буферов протокола реализуется служба и сервер gRPC. Запрашивающий клиент генерирует подходящую заглушку. Если заглушка доступна, клиентское приложение вызывает соответствующую функцию («Поиск предметов в инвентаре») в заглушке.
  • Затем запрос отправляется на сервер по сети. После получения запроса через соответствующий сервисный интерфейс сервер gRPC начинает фактический поиск товара в базе данных.
  • Затем сервер отправляет ответ в заглушку клиента, которая передает возвращаемое значение исходному экземпляру запроса (например, «Количество найденных товаров»).

Клиентские и серверные приложения иногда написаны на разных языках программирования. gRPC преодолевает эти ограничения с помощью специальных интерфейсов и механизмов перевода.

Для передачи потоков данных туда и обратно между машинами (Proto Request и Proto Response) HTTP/2 встроен в специальные сетевые протоколы, такие как TCP/IP или UDP/IP. Потоки передают компактные двоичные данные, созданные в процессе сериализации (marshalling), стандартного процесса в удаленных вызовах процедур. Передаваемые данные также десериализуются (unmarshalling), чтобы полностью абстрактные структуры данных могли быть обработаны клиентом и сервером на последующих этапах.

Рабочий процесс gRPC и первые шаги через буферы протокола

Типичный рабочий процесс gRPC делится на четыре этапа:

  1. Определение сервисного контракта для межпроцессного взаимодействия: Определяются сервисы, которые должны быть установлены, а также основные параметры и типы возврата, которые могут быть вызваны удаленно.
  2. Генерация кода gRPC из файла .proto: Специальные компиляторы (инструменты командной строки под названием «protoc») генерируют оперативный код из сохраненных .proto файлов с соответствующими классами для желаемого целевого языка (например, C++ или Java).
  3. Реализация сервера на выбранном языке.
  4. Создание клиентской заглушки, которая вызывает сервис. Затем запрос(ы) обрабатывается(ются) сервером и клиентом(ами).

Для запроса к базе данных, который ищет продукт в инвентаре, первые шаги в текущем синтаксисе буфера протокола (версия proto3) выглядят следующим образом:

syntax = "proto3";
package gRPC_service;
import "google/protobuf/wrappers.proto";
service InventoryService {
	rpc getItemByName(google.protobuf.StringValue) returns (Items);
	rpc getItemByID(google.protobuf.StringValue) returns (Item);
	 rpc addItem(Item) returns (google.protobuf.BoolValue);
}
 
message Items {
  string itemDesc = 1;
  repeated Item items = 2;
}
 
message Item {
	string id = 1;
	string name = 2;
	string description = 3;
}

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

На следующей схеме показано, как определение службы (inventory.proto) управляет запросом базы данных в архитектуре клиент-сервер:

HTTP/2: высокопроизводительная потоковая передача данных

HTTP/2 играет центральную роль в gRPC, поскольку позволяет передавать компактные двоичные данные в дополнение к высокоэффективному обмену сообщениями и данными. Сетевой протокол предоставляет четыре метода для удаленного вызова процедур:

1. Унарные RPC — самый простой метод gRPC. Клиент посылает индивидуальный запрос на сервер. Как и при обычном вызове функции, клиент получает в ответ индивидуальный ответ.

Пример: rpc SayHello (HelloRequest) возвращает (HelloResponse).

2. При использовании серверных потоковых RPC возможен более сложный обмен сообщениями в рамках одного вызова RPC. Сначала клиент посылает запрос на сервер. Затем он получает от сервера поток с более обширной последовательностью сообщений (эффективное упорядочивание сообщений в рамках отдельного вызова RPC). Затем клиент читает из этого потока, пока не останется ни одного сообщения.

Пример: rpc LotsOfReplies (запрос HelloRequest) возвращает (поток HelloResponse).

3. Клиентский потоковый RPC обращает этот процесс вспять: Клиент пишет серию сообщений, а затем передает их серверу. После того, как клиент написал сообщения, он ждет, пока сервер прочитает их и вернет ответ. И снова упорядочивание сообщений происходит в рамках отдельного вызова RPC.

Пример: rpc LotsOfGreetings (поток HelloRequest) returns (HelloResponse)

4. Двунаправленные потоковые RPC — это наиболее сложная форма коммуникации, в которой обе стороны посылают последовательность сообщений. Оба потока данных работают независимо, позволяя клиенту и серверу читать и писать в любом порядке. Например, сервер может ждать получения всех сообщений клиента, прежде чем писать свои ответы. Или он может попеременно читать сообщение, а затем писать сообщение. Возможны и другие комбинации чтения и записи.

Пример: rpc BidiHello (поток HelloRequest) возвращает (поток HelloResponse).

Методы 2-4 используют вложенные запросы для создания высокоэффективного мультиплексирования, когда несколько сигналов могут быть объединены в рамках одного TCP-соединения и передаваться по сети одновременно. Мощный протокол HTTP/2 устраняет блокировку трафика данных.

Плюсы и минусы gRPC

У gRPC есть много преимуществ. Фреймворк относительно прост в реализации, поскольку использует простую и довольно легкую в освоении IDL для создания файлов .proto. Таким образом, вы можете легко модернизировать старые программы с помощью мощного интерфейса gRPC, чтобы передавать большие файлы намного быстрее.

Кроме того, gRPC был широко протестирован и обладает высокой масштабируемостью, что означает, что вы можете использовать его для еще более сложных и обширных коммуникаций, например, в глобально связанных архитектурах клиент-сервер. В то же время HTTP/2 повышает эффективность не только за счет мультиплексирования и двунаправленного потока. Он также позволяет сжимать заголовки, что значительно сокращает объем данных запросов и ответов в сети.

Многоуровневый и высокостандартизированный дизайн фреймворка gRPC снижает трудоемкость программирования. Таким образом, разработчики могут сосредоточиться в первую очередь на реализации методов. Если фреймворк требует модификации, программисты и разработчики систем получают преимущества от свободно доступного исходного кода.

Кроме того, Protocol Buffers и соответствующие компиляторы Protobuf обеспечивают кросс-платформенное взаимодействие: Различные операционные системы, разрозненные компоненты в архитектурах клиент-сервер и разные языки программирования больше не являются препятствием. Например, программное обеспечение, написанное на языке C, может взаимодействовать с программным обеспечением Java. Компиляторы Protobuf теперь доступны для многих других языков, таких как C#, C++, Go, Objective-C, Java, Python, Node.js, Android Java, Swift, Ruby и PHP.

Гибкость — еще одно преимущество gRPC. Например, вы можете использовать его для обмена данными между микросервисами или он может использоваться мобильными приложениями, которые обмениваются данными с серверами. Еще одно преимущество: Протокол позволяет реализовать новейшие технологии безопасности. gRPC имеет встроенную аутентификацию и способствует использованию SSL/TLS для аутентификации и шифрования связи.

Слабые стороны gRPC: Тестирование интерфейсов gRPC на данном этапе развития неадекватно. Сообщения gRPC, закодированные с помощью protobuf, не являются человекочитаемыми. При анализе трафика, и особенно при отладке, приходится использовать дополнительные экземпляры, чтобы преобразовать код в понятную форму и найти источники ошибок. Дополнительные недостатки возникают при подключении распределенных клиент-серверных архитектур. gRPC связывает удаленные компьютеры и поэтому более уязвим, чем локальные системы. gRPC требует стабильной и мощной сети. Сеть, трафик данных, протоколы передачи, а также клиент и сервер никогда не должны быть слабыми местами, которые хакеры могут использовать для атак. Еще одним недостатком является то, что gRPC не поддерживает многоадресную рассылку.

Сравнение gRPC и REST

Благодаря своим положительным характеристикам, gRPC является жизнеспособной альтернативой REST (Representational State Transfer). REST отлично подходит для простых служб, в то время как gRPC — для более сложных интерфейсов (API) и служб. REST обычно использует формат данных JSON для обмена данными между приложениями. JSON основан на тексте и нагружает сетевые ресурсы.

В отличие от него, gRPC может организовать гораздо более компактный поток, используя буферы протокола и HTTP/2. По сравнению с JSON, gRPC снижает требования к памяти почти на 70 процентов за счет двоичной сериализации данных. Кроме того, двунаправленный поток, который работает без блокировки обмена данными, обеспечивает значительные преимущества в производительности и скорости по сравнению с REST.

В настоящее время совместимость с веб-приложениями недостаточна, поскольку эти приложения часто не оптимизированы для использования буферов протоколов, «контрактно-первого подхода» gRPC и контрактно-первого API фреймворка gRPC. Недостатком работы с веб-приложениями является то, что на данный момент ни одна служба gRPC не может быть доступна непосредственно из браузера. Это не является проблемой для REST, поскольку обычный протокол HTTP поддерживается всеми браузерами, в отличие от более современного HTTP/2. Однако этот недостаток относительно легко преодолеть, чтобы один и тот же сервис можно было использовать для веб-приложения и мобильного приложения. Одним из вариантов для веб-приложений является gRPC-Web. Разработчики gRPC все еще работают над другими решениями, чтобы максимально упростить совместную работу gRPC и веб-инструментов.

Где используется gRPC?

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

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

Кроме того, мощная потоковая передача данных через HTTP/2 делает gRPC идеальным средством связи в режиме реального времени «точка-точка». Интернет вещей (технологии «умного дома») выигрывает от этой дружественной к ресурсам системы, которая все чаще используется для регулирования связи между клиентами с низким уровнем ресурсов. Благодаря преимуществам в производительности и простоте разработки, эта коммуникационная технология может сыграть ключевую роль в будущих облачных приложениях и уменьшить доминирование REST. gRPC также в настоящее время рекламируется как альтернатива XML (Extensible Markup Language).

Примечание

XML — это широко используемый формат для обмена данными и структурированного хранения информации.

Оцените статью
cdelat.ru
Добавить комментарий