Сравнение служб 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

Performance

Сообщения 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 унифицированы между платформами и имплементациями.

Streaming

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

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

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

Дедлайн, тайм-ауты и отмена

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

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

Рекомендуемые сценарии 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 как RESTful API в виде JSON. Браузерному приложению не нужно создавать клиент gRPC и не нужно ничего знать о gRPC. API-интерфейсы RESTful можно автоматически создавать из служб gRPC, аннотируя .proto файл с метаданными HTTP. Транскодирование позволяет приложению поддерживать как gRPC, так и веб-API JSON без дублирования усилий по созданию отдельных служб для обоих.

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

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

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

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

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

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

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

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

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

• Создание клиента и сервера .NET gRPC в ASP.NET Core
• Общие сведения о gRPC на .NET
• Службы gRPC с C#
• Перенос gRPC с C-core на gRPC для .NET