Добрый день, уважаемое сообщество экспертов.
Вопрос выбора инструментария для микросервисной архитектуры проекта, привел меня к вопросу: Что лучше для построения приложения на микросервисной архиектуре Spring Cloud или gRPC?
Буду рад не только рукам «за и против», но и аргументированным и построенным на опыте мнениям.
Если я и гульгуль что-то упустили и есть развернутые статьи на эту тему, прошу Вас быть щедрыми на ссылки.
Спасибо за ваше время и мнения :)
Spring Cloud — это набор инструментов для построения приложений в облаке, а gRPC — это RPC решение, не совсем корректно ставить вопрос «одно или другое». На самом деле, их вполне можно использовать вместе. Например, внутри Netflix используют Spring Cloud + gRPC.
Сложно говорить без понимания Вашего юзкейса, но мне видится логичным начинать построение ваших облачных решений со Spring Cloud и, по необходимости, добавить gRPC.
Всё, как всегда, зависит от юзкейсов и прочих ограничений.
Чета вы теплое с мягким сравниваете. gRPC — фреймворк для клиент-серверного взаимодействия. Вполне хорошо миксуется со Spring-ом. По сути, если gRPC со Spring вместе работают, то вместо REST-а используется gRPC. При этом gRPC все так же прекрасно может работать с вашим сервис дискавери (той же Eureka-ой, например).
gRPC это HTTP2 , REST — HTTP. Так что gRPC будет намного быстрее, но с чуть более сложным дебагом, т.к. просто подергать методы каким-нить Postman-ом уже не выйдет.
Ну и так gRPC предоставляет очень много фич, которые не всякому проекту нужны. Нужен ли вам streaming или Bi-directional streaming? Нужен ли back pressure? и тп. Ответьте на вопросы, какие фичи нужны, и тогда будет проще выбрать
Добрый день.
Вы ставите классический вопрос: суп или борщ ? Не предоставляя контекста. Но, так или иначе у Вас есть такие варианты:
Игорь, спасибо Ваше за мнение.
Фактически — да, это глобальный вопрос: какую из двух технологий выбрать при разработке продукта с нуля?
Мне интересено мнение тех, кто уже пробовал и то и другое и может описать плюсы и минусы этих технологий.
Например, как Вы:
"
попытки решить стандартные проблеммы с distributed tracebility, circuit breaker, protocol metrics and monitoring, service registry/discovery быстро укажут правильную дорогу в сторону Spring Boot & Spring Cloud
"
Можно об этом опыте подробнее? Эти проблемы не решаемы в gRPC?
Насколько просто их устранить в Spring Cloud?
Александр, ведь продукт не абстрактный, а конкретный. К нему наверное есть требования, возможно одно и них и определит использование той или иной технологии.
Но если хочется абстракции, то скорее всего Вам просто прогуглить java microservice framework и получить что-то типа cdelmas.github.io/...oservices-Frameworks.html. Думаю имеет смысл выписать в табличку требования для фреймворка и посмотреть, что подходит. А gRPC просто организация клиент- серверного взаимодействия, но не как не фреймворк для микросервисов и находится он на одном уровне с Apache thrift, corba (не к ночи будет упамянута), REST и SOAP.
И в добавок — все проблемы решаемы, в том числе и для gRPC, но зачем тратить время на решение если можно сосредоточится на бизнес задаче? Так например, если вам необходимо управлять конфигурацией десятка микросервисов, то gRPC Вам ничем не поможет.
Из опыта могу сказать, что Spring boot/cloud, Vertx работают отлично. Play в топку.
Игорь, спасибо за совет. Приму к сведению.
Якщо вже використовуєте Spring, то я думаю краще Spring Cloud. На проекті робили перехід на Spring Boot і вже на Cloud. Були задоволені, але й були різні недоліки, але всі можна виправити.
Якщо ж не використовуєте Spring, то можливо краще gRPC( сам не використовував, нічого сказати про нього не можу)
Спасибо, за мнение Игорь.
На проекте использую Spring Boot с gRPC — все отлично сочетается.
Вот и задался вопросом, Spring Cloud будет лучше сочетаться или нет?
Якщо все ок, то навіщо щось вигадувати?)
Преждевременная оптимизация — корень всех зол.
Для текущего проекта технология уже выбрана — gRPC.
А вот для следующего нового проекта можно выбрать и другую технологию.
Alex Borysov
Vasya Pupking
Igor Azarny
Igor Azarny
Ihor Kryvenko
Ihor Kryvenko
10 коментарів
Додати коментар Підписатись на коментаріВідписатись від коментарів