Сравнение служб gRPC с API-интерфейсами HTTP

Автор: Джеймс Ньютон-Кинг (James Newton-King)

В этой статье объясняется, чем службы gRPC отличаются от API HTTP с JSON (включая веб-API ASP.NET Core). Важно правильно выбрать технологию для предоставления API для вашего приложения, и gRPC предлагает уникальные преимущества по сравнению с API HTTP. В этой статье обсуждаются сильные и слабые стороны gRPC и приводятся рекомендации по использованию gRPC вместо других технологий.

Общее сравнение

В следующей таблице представлено общее сравнение функций gRPC и API HTTP с JSON.

Функция gRPC API HTTP с JSON
Контракт Обязательное значение (.proto) Необязательно (OpenAPI)
Протокол HTTP/2 HTTP
Payload Protobuf (малый, двоичный) JSON (большой, удобочитаемый)
Обязательность Строгая спецификация Нестрого. Допустимы все HTTP-протоколы.
Потоковые операторы Клиент, сервер, оба направления Клиент, сервер
Поддержка браузеров Нет (требуется grpc-web) Да
Безопасность Транспорт (TLS) Транспорт (TLS)
Создание кода клиента Да OpenAPI + сторонние средства

Сильные стороны gRPC

Производительность

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

gRPC предназначен для протокола HTTP/2, основной версии HTTP, которая обеспечивает значительное повышение производительности по сравнению с HTTP 1.x:

  • Двоичное кадрирование и сжатие. Протокол HTTP/2 является компактным и эффективным при отправке и получении.
  • Мультиплексирование нескольких вызовов HTTP/2 через одно TCP-соединение. Мультиплексирование устраняет блокировки очереди.

HTTP/2 поддерживается не только gRPC. Многие типы запросов, включая API HTTP с JSON, могут использовать HTTP/2, чтобы повысить производительность.

Создание кода

Все платформы gRPC предоставляют поддержку первого класса для создания кода. Базовым файлом для разработки gRPC является файл с расширением .proto, который определяет контракт служб и сообщений gRPC. Из этого файла платформы gRPC создают базовый класс службы, сообщения и полный клиент.

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

Строгая спецификация

Формальная спецификация для API HTTP с JSON не существует. Разработчики спорят о лучшем формате URL-адресов, HTTP-команд и кодов ответов.

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

Потоковые операторы

HTTP/2 предоставляет основу для долгосрочных потоков связи в режиме реального времени. gRPC предоставляет поддержку первого класса для потоковой передачи через HTTP/2.

Служба gRPC поддерживает все сочетания потоков:

  • Унарный (нет потоковой передачи)
  • Потоковая передача от сервера к клиенту
  • Потоковая передача от клиента к серверу
  • Двунаправленная потоковая передача

Крайний срок, время ожидания и отмена

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

Распространение крайнего срока и отмены через дочерние вызовы gRPC помогает применять ограничения использования ресурсов.

gRPC хорошо подходит для следующих сценариев:

  • Микрослужбы — gRPC обеспечивает малое время задержки и высокую пропускную способность. gRPC отлично подходит для упрощенных микрослужб, где важна эффективность.
  • Взаимодействие между точками в реальном времени — gRPC полноценно поддерживает двунаправленную потоковую передачу. Службы gRPC могут отправлять сообщения в режиме реального времени без опроса.
  • Среды с разными языками — средства gRPC поддерживают все популярные языки разработки, поэтому gRPC является хорошим выбором для многоязыковых сред.
  • Среды с ограниченными ресурсами сети — сообщения gRPC сериализуются с помощью Protobuf и имеют упрощенный формат. Сообщение gRPC всегда меньше, чем эквивалентное сообщение JSON.
  • Межпроцессное взаимодействие (IPC) . Для взаимодействия приложений на одном компьютере вместе с gRPC можно использовать транспорты IPC, такие как сокеты доменов UNIX и именованные каналы. Дополнительные сведения см. в статье Межпроцессное взаимодействие с помощью gRPC.

Слабые стороны gRPC

Ограниченная поддержка веб-браузера

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

Существует два распространенных подхода внедрения gRPC в приложения, использующие браузер.

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

    .NET Core имеет поддержку для gRPC-Web. Дополнительные сведения см. в статье Использование gRPC в приложениях на основе браузера.

  • Веб-API RESTful JSON можно создавать автоматически из служб gRPC путем добавления метаданных HTTP в файл .proto. Это позволяет приложению поддерживать веб-API gRPC и JSON без выполнения повторяющихся действий по созданию отдельных служб для обоих типов интерфейсов.

    В .NET Core предусмотрена экспериментальная поддержка для создания веб-API JSON из служб gRPC. Дополнительные сведения см. в статье Перекодирование gRPC JSON.

Недоступно для чтения человеком

Запросы API HTTP отправляются в виде текста и могут быть прочитаны и созданы людьми.

По умолчанию сообщения gRPC кодируются с помощью Protobuf. Хотя Protobuf является эффективным методом отправки и получения, его двоичный формат не читается человеком. Для Protobuf требуется описание интерфейса сообщения, указанное в файле .proto для правильной десериализации. Для анализа полезных данных Protobuf на канале передачи и создания запросов вручную требуются дополнительные средства.

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

Альтернативные сценарии платформы

Рекомендуется использовать другие платформы вместо gRPC в следующих сценариях:

  • API, доступные в браузере — gRPC не полностью поддерживаются в браузере. gRPC-Web может предлагать поддержку браузеров, но имеет ограничения и вводит серверный прокси.
  • Широковещательная передача в реальном времени — gRPC поддерживает обмен данными в режиме реального времени через потоковую передачу, но концепция широковещательной рассылки сообщения в зарегистрированные подключения не существует. Например, в сценарии комнаты чатов, где новые сообщения разговора должны отправляться всем клиентам в комнате разговора, каждый вызов gRPC должен отдельно передавать новые сообщения чата клиенту. Для этого сценария хорошо подойдет SignalR. В SignalR есть концепция постоянных подключений и встроенная поддержка широковещательных сообщений.

Дополнительные ресурсы