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

Статья
11/06/2024

Примечание.

Это не последняя версия этой статьи. В текущем выпуске см . версию .NET 8 этой статьи.

Предупреждение

Эта версия ASP.NET Core больше не поддерживается. Дополнительные сведения см. в статье о политике поддержки .NET и .NET Core. В текущем выпуске см . версию .NET 8 этой статьи.

Внимание

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

В текущем выпуске см . версию .NET 8 этой статьи.

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

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

Примечание.

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

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

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

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

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

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

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

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

Поделиться через