Преимущества, недостатки и типовое использование¶
Рассмотрим, для чего лучше использовать 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
-
Статья на тему сравнения gRPC с другими протоколами от Microsoft ↩
-
Очевидно, речь идёт о шаблоне “API-шлюз” ↩
Дата создания : 6 апреля 2023 г.