В чем преимущества gRPC по сравнению с REST
Что проверяют
Понимаете ли вы, откуда берутся преимущества gRPC и чего они стоят, или просто повторяете «он быстрее». Следом обычно спрашивают, почему gRPC плохо балансируется в Kubernetes и как с ним работать из браузера.
Как отвечать
Сначала оговорка: REST это архитектурный стиль поверх HTTP, gRPC это RPC-фреймворк с конкретным протоколом. Сравнивают обычно REST с JSON и gRPC с Protobuf. Преимущества gRPC:
- компактная сериализация: Protobuf бинарный, сообщения меньше JSON, а разбор быстрее и дешевле по CPU;
- HTTP/2: много одновременных вызовов мультиплексируются в одном TCP-соединении, заголовки сжимаются HPACK;
- контракт первым: сервис описан в
.proto, из негоprotocчерез плагин Maven или Gradle генерирует стабы для Java и клиенты для других языков. Расхождение клиента и сервера ловится на компиляции; - стриминг: четыре вида вызовов, unary, серверный, клиентский и двунаправленный стриминг;
- дедлайны и отмена:
stub.withDeadlineAfter(2, TimeUnit.SECONDS), дедлайн передаётся по цепочке сервисов, а отмена на клиенте доходит до сервера.
В Java это grpc-java на Netty, с блокирующими, асинхронными и future-стабами. Для Spring есть официальный проект Spring gRPC и популярные сторонние стартеры.
Цена: браузер не вызывает gRPC напрямую, нужен gRPC-Web с прокси вроде Envoy. Бинарный трафик не прочитать глазами, отлаживают через grpcurl и server reflection. HTTP-кэширование и привычный curl не работают. Отсюда типичное разделение: gRPC для внутренних вызовов между сервисами, REST для публичного API.
Где спотыкаются
Не знают про балансировку. HTTP/2-соединение долгоживущее, и L4-балансировщик вроде обычного Service в Kubernetes отправит все вызовы клиента в один под. Нужна клиентская балансировка или L7-прокси, например service mesh.
Объясняют обратную совместимость «строгой типизацией». Её дают номера полей: поле можно добавить, номер удалённого поля помечают reserved, а переиспользовать его или менять тип нельзя.
Говорят, что gRPC безопаснее, потому что использует TLS. REST поверх HTTPS защищён тем же TLS, разницы в шифровании нет.