Comments 9
Команда VK Cloud перевела статью с подробным техническим сравнением двух типов API: HTTP и gRPC.
Перевели, молодцы. А кто автор?
gRPC API сложно проектировать и создавать, поэтому gRPC довольно трудно внедрить
Хорошая обзорная статья, но вот этот момент совершенно не раскрыт. Хотелось бы увидеть, как именно реализуется gRPC API, всегда ли необходимо делать собственный gRPC прокси-сервер, который будет транслировать сообщения в спецификации gRPC в несколько запросов к разным другим сервисам (если речь идет о запросе данных из нескольких источников данных), возможно ли добавлять некий "контроллер" gRPC к приложениям-сервисам (отдельным микросервисам) какими-то сравнительно простыми способами по аналогии, как это делается, например, для REST контроллера в Spring приложении? Возможно ли добавление таких контроллеров в приложения, написанные на других стеках? (То есть какова вообще широта поддержки спецификации для множества возможных стеков, на которых пишутся сервисы?)
Пока что я вижу, что помимо унификации спецификации сообщений для обмена между сервисами, требуется масса промежуточных усилий, не меньших, как мне кажется, если просто писать DTO, объединяющие данные из нескольких источников данных с помощью стандартных возможностей обмена между ними. Мне кажется, что gRPC будет полезен, когда будет масса готовых разработанных прокси-серверов и gPRC-контроллеров в отдельных микросервисах, способных работать с источниками данных большинства или всех видов, используемых в кровавом энтерпрайзе. И чтобы конфигурирование прокси-серверов и gPRC-контроллеров выполнялось не сложнее, чем настройка контроллеров Spring приложения. Только тогда это будет эффективным средством для облегчения работы разработчиков, а не усложнением их работы и замедлением скорости разработки. Business first - давайте не будем забывать об этом важном принципе нашей работы. Этот этап уже достигнут сообществом gRPC или вендорами? Хотелось бы, чтобы уже был достигнут.
Если я не прав, прошу дать развернутый ответ в деталях - почему именно. Если нужный этап достигнут, хотелось бы увидеть статью с обзором gRPC прокси-серверов и gRPC-контроллеров для разных стеков, и как их внедрять и настраивать.
По мне немного странный вопрос, это как сравнивать холодное с плоским. С REST API много контроллеров - это хорошо, т.к. мы задаем разные вопросы с разной логикой ответов. С gRPC мы устанавливаем канал связи, и желательно что бы он был только один на сервис. При этом определение логики дальнейших действий вкладываем в сам gRPC пакет (идентификатор). gRPC сервер может не только сам обрабатывать ответы, но и пересылать эти вопросы другим своим клиентам (микросервисам). Несомненный плюс такого подхода, это получение и обработка данных - когда она необходима. Если проводить аналогию с Java, очень похоже на асинхронку в RxJava. Еще один несомненный плюс, это одновременная обработка нескольких пакетов в зависимости от количества ядер процессора и открытие не тысячи сокетов, а создание виртуальных групп сокетов на одном соединении. Очень интересный протокол, за ним будущее. По моему опыту, был написан gRPC сервер и встроены клиенты в приклады. И уже через gRPC связал приклады с инфраструктурой.
Почему не рассмотрен случай, когда HTTP API (REST?) работает по HTTP 2.0?
Почему не рассмотрены другие варианты, например JSON-RPC
В статье постоянно путают HTTP API и REST, что вызывает серьезные сомнения в компетентности как автора, так и переводчиков.
При этом никаких реально важных вещей (документация, версионирование, совместимость с сетевой инфраструктурой) не рассматривают.
А разве не поглотит всех GraphQL API?
На мой взгляд, GraphQL не альтернатива, а один из вариантов подхода к разработке клиент-серверной архитектуры, когда значительная часть информации о структуре данных (а значит и бизнес-логики) уходит на клиента. То есть это фактически не RPC, а, скорее, протокол получения структурированных данных. Серверу при этом достаётся усложнённая (по сравнению с RPC) задача авторизации на доступ к данным.
Честно говоря статья написана или переведена отвратительно (а скорее и то и другое). Не раскрыты полностью все преимущества gPRC (скорость, упаковка, быстрая сериализация, стриминг, генерация под все языки и конечно http2 - и вытекающие из него ). По-моему у gPRC отличные перспективы как у языка межсервисного взаимодействия. Например по следующей схеме: фронт общается со шлюзом через GraphQL (Federation если много данных) а шлюз с микросервисами и они-же между собой посредством gRPC. Таким образом куча микросервисов написанная разными командами на разных языках (в проекте сотни микросервисов на GO, PHP, Java и Node), DTO из proto файлов централизованно генерятся во все используемые языки. Не вдавался как реализованы клиенты для GO, JAVA, PHP но для микросервисов на ноде нет никаких сложностей - все решения и библиотеки вполне зрелые, работают весьма шустро, давно в проде. Есть некоторые сложности связанные с балансировкой микросервисов с gRPC на k8s но это решатся сторонними прокси, тот же Envoy. Так же есть сложности связанные с ошибками в gRPC, но все решаемо (metadata). По сравнению с thrift а тем более с REST гораздо более быстрое и экономное решение.
Что выбрать для очередного API: HTTP или gRPC