Мы ж программист

Раскрытие возможностей gRPC

·

Оригинал: Unleashing the power of gRPC

Перевод для канала Мы ж программист

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

Происхождение gRPC

gRPC, или удаленные вызовы процедур (Remote Procedure Calls), берет свое начало в RPC-фреймворке Stubby, разработанном компанией Google в начале 2000-х годов. Stubby был эффективным и легким фреймворком, использовал JSON для обмена данными и TCP/IP для транспортировки. Однако, в Stubby отсутствовала поддержка таких функций, как потоковая передача и мультиплексирование, что ограничивало его применимость к определенным типам приложений.

В 2015 году Google приступил к реализации проекта по разработке нового фреймворка RPC, который бы устранил ограничения Stubby. Результатом стало создание gRPC, который был впервые анонсирован на конференции Google I/O в мае 2015 года.

Чем gRPC отличается от RPC?

Сначала давайте разберемся, что такое RPC.

Что такое RPC? Удаленный вызов процедур (RPC) – это технология распределенных вычислений, которая позволяет программе выполнить процедуру (подпрограмму) в другом адресном пространстве (обычно на другом компьютере в общей сети), как если бы это был обычный (локальный) вызов процедуры. Это форма взаимодействия клиент-сервер (вызывающая сторона – клиент, исполняющая – сервер), обычно реализуемая через систему передачи сообщений «запрос-ответ».

API RPC использует такой протокол, как HTTP, TCP или UDP, в качестве базового механизма обмена данными.

Итак, чем же лучше gRPC? gRPC реализует традиционный RPC с несколькими оптимизациями.

RPC и gRPC: ключевые различия

– Формат сообщений: RPC обычно использует текстовые форматы, такие как JSON или XML, для сериализации сообщений, в то время как gRPC использует двоичный формат, называемый буферами протокола (Protocol Buffers, protobuf).

Это различие в формате имеет несколько последствий:

  • Производительность: Двоичные форматы обычно более эффективны для передачи по сети по сравнению с текстовыми форматами, что приводит к снижению задержек и повышению производительности.
  • Машиночитаемость: Сообщения Protobuf являются машиночитаемыми, что облегчает инструментам разбор и понимание данных.

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

  • Мультиплексирование: HTTP/2 позволяет мультиплексировать несколько запросов через одно соединение, что снижает накладные расходы и повышает общую производительность.
  • Контроль потока: HTTP/2 предоставляет более совершенные механизмы контроля потока для управления передачей данных между клиентом и сервером, предотвращая перегрузку и улучшая скорость отклика.

– Поддержка потоковой передачи данных: RPC обычно поддерживает только обмен данными в стиле «запрос-ответ», в то время как gRPC поддерживает как запрос-ответ, так и двунаправленную потоковую передачу. Двунаправленная передача позволяет осуществлять непрерывный обмен данными между клиентом и сервером, что делает ее идеальной для приложений реального времени.

– Поддержка языков: RPC поддерживает широкий спектр языков программирования, включая Java, Python, C++ и Go. Однако gRPC имеет более богатую экосистему языковой поддержки, особенно для новых языков, таких как Go и Rust.

– Инструментарий и библиотеки: RPC имеет развитую экосистему инструментов и библиотек, но gRPC предлагает более современный и оптимизированный инструментарий, что упрощает разработку и поддержку приложений на базе gRPC.

– Производительность и масштабируемость: использование в gRPC бинарных сообщений, HTTP/2 и потоковых возможностей обеспечивает значительно более высокую производительность и масштабируемость по сравнению с RPC. Это делает gRPC лучшим выбором для чувствительных к задержкам и высокопроизводительных приложений.

Ключевые компоненты gRPC архитектуры

  1. Protobuf: Protocol Buffers, краеугольный камень gRPC, – это эффективный и независимый от языка формат сериализации данных. Он определяет интерфейсы сервисов и структуры сообщений, обеспечивая согласованное и платформонезависимое взаимодействие между клиентами и серверами.
  2. Заглушки (stubs): Заглушки, определяемые файлами Protobuf, представляют собой прокси-серверы на стороне клиента, которые зеркально отражают интерфейсы сервисов. Они получают клиентские запросы, сериализуют их в сообщения Protobuf и отправляют на сервер.
  3. Каналы: Каналы представляют собой соединения между клиентами и серверами. Они обеспечивают постоянный и мультиплексированный канал связи для отправки и получения сообщений.
  4. Клиентские библиотеки: Клиентские библиотеки, специфичные для каждого языка программирования, обеспечивают взаимодействие между заглушками, каналами и базовым транспортом HTTP/2. Они облегчают вызов удаленных методов, сериализацию и десериализацию сообщений, а также обработку ошибок и таймаутов.
  5. Реализация сервера: Реализация сервера определяет фактическую логику для каждого метода службы. Он получает сообщения Protobuf от клиентской заглушки, декодирует их в структурированные данные, выполняет соответствующий метод и кодирует ответ в сообщение Protobuf.

Рабочий процесс gRPC

Типичный gRPC процесс делится на несколько шагов.

Определение: опишите, что делают ваши службы и как они взаимодействуют (с помощью файла .proto).

Компиляция: преобразуйте файл .proto в код на выбранном вами языке (например, C++, Java).

Создание сервера: Реализуйте логику на стороне сервера, используя сгенерированный код.

Создание клиента: Создайте заглушку клиента, чтобы легко взаимодействовать с сервером.

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

Поток передачи данных gRPC

  1. Запрос клиента: Клиентское приложение инициирует вызов RPC, вызывая метод на объекте-заглушке.
  2. Заглушка -> канал: Заглушка сериализует параметры запроса в сообщения Protobuf и отправляет их по установленному каналу на сервер.
  3. Прием сервером: Сервер получает сообщения Protobuf и декодирует их в структурированные данные.
  4. Выполнение метода: Сервер выполняет соответствующий метод, вызывая бизнес-логику, определенную в реализации сервиса.
  5. Генерация ответа: Сервер кодирует данные ответа в сообщения Protobuf.
  6. Канал -> заглушка: Сервер отправляет сгенерированные Protobuf-сообщения обратно в клиентский заглушку через канал.
  7. Заглушка -> клиент: Заглушка декодирует ответные сообщения и возвращает десериализованные данные ответа клиентскому приложению.

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

Разделы

Свежее