Сравнение служб 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
Полезные данные 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) — транспорты IPC, такие как сокеты домена Unix и именованные каналы, можно использовать с gRPC для обмена данными между приложениями на одном компьютере. Дополнительные сведения см. в статье Межпроцессное взаимодействие с помощью gRPC.

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

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

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

gRPC в ASP.NET Core предлагает два решения, совместимые с браузером:

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

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

  • Перекодирование gRPC JSON позволяет браузерным приложениям вызывать службы gRPC, как обычные REST API с поддержкой формата JSON. Браузерному приложению не нужно создавать клиент gRPC и не нужно ничего знать о gRPC. REST API можно создавать автоматически из служб gRPC, добавляя к файлу .proto метаданные HTTP. Перекодирование позволяет приложению параллельно поддерживать веб-API gRPC и JSON, не дублируя действия по созданию отдельных служб для разных типов интерфейсов.

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

Примечание.

Для перекодирования gRPC JSON требуется .NET 7 или более поздней версии.

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

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

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

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

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

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

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

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