gRPC — Введение

Краткое введение в gRPC

Введение

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

Поскольку gRPC поддерживает несколько языков программирования и платформ, клиент, написанный на одном языке (например, Java), может беспрепятственно взаимодействовать с сервером, написанным на другом языке (например, Go). Такое поведение позволяет нескольким службам взаимодействовать друг с другом без каких-либо дополнительных усилий, что делает его хорошим кандидатом на архитектуру в стиле микросервисов.

В этой статье попробуем разобраться в gRPC на высоком уровне.

Целевая аудитория

Эта статья предназначена для тех, кто относительно плохо знаком с gRPC. Если вы уже знакомы с gRPC, не стесняйтесь просмотреть. Вы можете найти что-то интересное. :-)

Разное

Вы знаете, что означает gRPC? gRPC Rэмоции Pпроцедура Cвсех. Да, вы правильно прочитали. :-)

Типы RPC

gRPC поддерживает следующие типы RPC.

Унарные RPC

В этом сценарии клиент отправляет один запрос на сервер, а сервер отвечает одним ответом. Это похоже на обычные вызовы функций.

Серверные потоковые RPC

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

Клиентские потоковые RPC

Здесь клиент пишет последовательность сообщений и отправляет их на сервер, используя поток. После завершения написания сообщений клиент ждет, пока сервер прочитает сообщения и вернет ответ.

Двунаправленные потоковые RPC

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

На следующей диаграмме показано, как обычно взаимодействуют сервер gRPC и клиенты.

Языковая поддержка

gRPC поддерживает широкий спектр языков, таких как C/C++, C#, Dart, Go, Java, Node.js, Objective-C, PHP, Python и Ruby. Это помогает разработчикам выбирать правильный язык в зависимости от их вариантов использования.

Принципы дизайна

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

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

Подробнее о принципах проектирования см. здесь.

Сервис

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

Используя протокольные буферы, мы можем определить интерфейс службы, а также структуру сообщения полезной нагрузки. (gRPC также можно настроить для использования других форматов сообщений, таких как JSON, XML и Thrift. Но из соображений производительности лучше использовать протокольные буферы.)

Буферы протокола

Прежде чем двигаться дальше, давайте кратко рассмотрим буферы протоколов.

Буферы протоколов, также известные как protobuf, представляют собой механизмы сериализации структурированных данных. Он намного меньше и быстрее по сравнению с XML и JSON. Структуру данных можно определить один раз; чтение и запись данных в различные потоки данных и из них могут выполняться последовательно. Он также поддерживает множество языков программирования и платформ.

Структура данных определяется в файле .proto путем указания обязательных (и необязательных полей) вместе с их типами данных. Затем с помощью компилятора Protocol Buffer (известного как protoc) можно создать дополнительные вспомогательные файлы. Эти файлы предоставляют функции, необходимые для установки/получения полей, сериализации сообщения в выходной поток и разбора сообщения из входного потока. Например, если мы выберем Go в качестве языка, компилятор protoc создаст дополнительные файлы с расширением .pb.go. (Мы увидим больше этого в действии, когда попытаемся создать пример программы.)

Чтобы узнать больше о протокольном буфере, обратитесь здесь.

Жизненный цикл

Теперь давайте рассмотрим жизненный цикл вызова gRPC на высоком уровне.

Унарный RPC

Когда клиент вызывает метод-заглушку, сервер уведомляется о вызове RPC. Метаданные клиента для вызова вместе с именем метода также являются общими.
Сервер может отправить обратно свои метаданные или дождаться получения сообщения запроса клиента.
Как только сервер получает запрос клиента, он выполняет необходимые действия на стороне сервера.
После завершения обработки сервер возвращает ответ вместе с кодом состояния. Если статус ответа OK, клиент получает ответ и завершает вызов на стороне клиента.

Серверная потоковая передача RPC

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

Клиентская потоковая передача RPC

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

Двунаправленный потоковый RPC

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

Другие варианты

Хотя gRPC подходит для многих случаев использования, как упоминалось выше, он определенно не является универсальным решением. Давайте попробуем кратко взглянуть на два других популярных варианта, которые находятся в том же пространстве. (Обратите внимание, что это не сравнение яблок с яблоками в основном из-за разного характера выбора. Кроме того, подробное сравнение требует отдельной специальной статьи. Цель здесь состоит в том, чтобы просто указать наличие других вариантов. .)

ОТДЫХ

REST (Representational State Transfer) — это архитектурный стиль, в котором для работы используются стандартные методы HTTP, такие как GET, POST, PUT и DELETE. Ресурсы представлены в виде URI, которые могут использоваться клиентским приложением для выполнения операций чтения, записи и удаления. Хотя он поддерживает различные форматы данных, JSON является наиболее распространенным форматом.

Чтобы узнать больше, проверьте здесь.

ГрафQL

GraphQL — это язык запросов для API, который обычно обслуживается через HTTP через единую конечную точку. Данные представлены в виде графика, а не столбцов и строк. GraphQL позволяет вызывающей стороне явно структурировать возвращаемые данные в самом запросе. Как правило, для обмена данными используется формат JSON.