Перейти к содержанию

Преимущества, недостатки и типовое использование

Рассмотрим, для чего лучше использовать gRPC, а также основные преимущества и недостатки в сравнении с SOAP и REST.

Преимущества

Тогда как SOAP основывается на XML-сериализации, а REST, чаще всего, на JSON-сериализации, gRPC использует двоичный (бинарный) способ сериализовать данные, что позволяет производить сериализацию и десериализацию более эффективно (требуется меньше памяти, чем в процессе сериализации в JSON и обратно, а также сериализованные данные занимают на 40% меньший объём, чем сериализованные в JSON).
Что касается удобства, REST не позволяет осуществлять двухсторонний стриминг, тогда как gRPC и SOAP (к примеру, WCF) поддерживают такой обмен. Однако gRPC делает это на основе HTTP/2. Отметим, что SOAP (в отличие от REST и gRPC) поддерживает различные виды транспорта, например SMTP или FTP.

Недостатки

В отличие от REST, gRPC несовместим с браузерами из-за HTTP/2, так как HTTP/2 не полностью поддерживается современными браузерами из-за невозможности обработки бинарных данных. Бинарная сериализация также делает невозможным прочтение человеком (например, для поиска ошибок), однако это же делает его более защищённым, так как бинарную сериализацию трудно декодировать без знания схемы. С другой стороны, далее мы рассмотрим gRPC-web, конкретную реализацию gRPC для преодоления несовместимости с браузерами. Этот недостаток совместимости является основным недостатком gRPC.
Наконец, в отличие от REST, gRPC является некэшируемым, также как SOAP. Это явный недостаток gRPC. Однако, вопрос можно решить, если полагаться на кэш в памяти. Microsoft описывает этот подход здесь.
Можно составить сравнительную таблицу1:

gRPC REST SOAP
Поддержка браузеров
Поддержка HTTP/2
Возможность чтения человеком
Формат передачи данных Бинарный JSON/XML XML
Производительность Высокая Средняя Низкая
Возможность кэширования
Двунаправленные потоки

Типовое использование

Исходя из таблицы выше, можно предложить такие типовые сценарии использования gRPC:

  • API к API, часто используется в комплексных архитектурных решениях для связи сервисов друг с другом;
    flowchart LR
    GS1(gRPC сервис 1)
    GS2(gRPC сервис 2)
    GS3(gRPC сервис 3)
    GS1<==>GS2
    GS2<==>GS3
    GS3<==>GS1
  • Монолитное приложение, соединяющееся с сервисами в сервисно-ориентированной архитектуре (SOA);
    flowchart LR
    GS1(gRPC сервис 1)
    GS2(gRPC сервис 2)
    GS3(gRPC сервис 3)
    M("Монолитное
    web-приложение")
    M<==>GS1
    M<==>GS2
    M<==>GS3
  • Фоновые задачи, использующие один или несколько веб-сервисов;
    flowchart LR
    GS1(gRPC сервис)
    BJ{{Фоновая задача}}
    BJ<==>GS1
  • Браузерное веб-приложение, подключающееся к сервису или нескольким микросервисам, используя REST API в качестве прокси2.
    flowchart LR
    GS1(gRPC сервис 1)
    GS2(gRPC сервис 2)
    GS3(gRPC сервис 3)
    W("Браузерное
    веб-приложение")
    RA(REST API)
    W<==>RA
    RA<==>GS1
    RA<==>GS2
    RA<==>GS3

  1. Статья на тему сравнения gRPC с другими протоколами от Microsoft 

  2. Очевидно, речь идёт о шаблоне “API-шлюз” 


Последнее обновление : 8 апреля 2023 г.
Дата создания : 6 апреля 2023 г.

Комментарии

Комментарии