Comments 11
Немного о вертикальном масштабировании:
Tomcat. Он медленный. Вместе со Spring-ом разница от самых производительных решений может быть в 20 раз.
Undertow. Он побыстрее. Но Spring всё равно всё испортит.
Netty. Он очень производительный. Хорошо дружит с Vert.x-ом.
Информация взята с Web Framework Benchmark - a тут тестируют все веб фреймворки на всех языках программирования, штук 400. Spring выступает как-то крайне неубедительно. Раньше там был и Spring Webflux, плёлся в хвосте, но потом он куда-то пропал, видимо, чтобы не дискредитировать Spring.
Не делайте таких выводов по Web Framework Benchmarks. Там сетап всех приложений абсолютно разный, поддерживается самими комьюнити. Хотя все и участвуют в одном рейтинге, за идентичностью никто не следит.
Бенчмарки дело такое, нужно очень чётко посмотреть исходник, понять что именно измеряется и о чем говорят результаты, а потом признать, что все таки не понял, и ещё раз смотреть, и так раз 10.
В общем, пока используем Spring Cloud Gateway. Потому что с Vert.x Gateway наверняка будут проблемы с функциональностью. А там через 10 лет посмотрим, в какую сторону пойдут микросервисы и шаблоны проектирования микросервисов. Как лучше всего проектировать кластер. Нужна ли Kafka или лучше без неё. Пока единого стандарта нет. Ну кроме стандарта делай всё на Spring-e и не парь людям мозги. :-D
Почему не использовать для маршрутизации средства самого OpenShift?
не рассматривали маршрутизацию с помощью OpenShift Service Mesh?
По опыту, наблюдая проекты в которых API Gateway запилен на базе java-фреймворков, пришел для себя к предположению, что выбор решения был за чуваками, шарящими в java, но не шарящими чуть в сторону.
Это не хорошо, не плохо. Просто наблюдение. Нельзя шарить везде и во всем. А других шарящих чуваков в команде не оказалось.
В требованиях только вот это "Гейтвей должен маршрутизировать запросы в сервисы разных версий в зависимости от версии клиентского приложения" относительно нетривиально. Остальное штатным готовым API Gateway'ем решается.
Использовал Netty + Reactor на своем проекте. Производительность, удобство, я был в восторге, пока дело не дошло до слоя БД. Сначала использовали блокирующий Hibernate - все приложение от точки входа до БД было неблокирующим и БД стала узким горлышком, т.к. обычный Hibernate не поддерживает неблокирующие транзакции. Я перевел проект на Hibernate Reactive, и тут началось. Проблем и багов было много и они были критические. В итоге так и не получилось перевести эту связку на реактивщину.
Если не использовать Hibernate или вообще не иметь бд в микро, однозначно на mvc я больше не вернусь.
Да упаси Господи использовать этот Hibernate в реактивных проектах. Hibernate это просто тормознутый генератор уродливых SQL запросов, который упрощает работу программисту на типичных бизнес проектах и усложняет на проектах высоких нагрузок. Нужно смотреть на реактивные драйвера для БД вместо JDBC - R2DBC.
Посмотрите доклад Антона Котова, если еще не смотрели, про R2DBC. Я на нем как раз присутствовал в роли эксперта.
Итоги на самом деле говорят вовсе не в пользу R2DBC.
Да и честно говоря, слабо представляю как поженить честную БД транзакционность относительно сложного приложения и реактивность. Концепции друг другу прямо противоположные, прямо скажем. Безотносительно с Hb или без
Не буду настаивать на счёт R2DBC, в Web Framework Benchmark-е он занял 104 место ну и JDBC 110. На 5-ом месте у Eclipse Vert.x там какой-то свой супер оптимизированный реактивный драйвер на netty для PostgreSQL. Там в git-e можно код для всех решений глянуть. В целом, сделать решение полностью без блокировок потоков крайне тяжело и я не особо верю в Spring. За всё удобство, красоту и аннотации приходится платить производительностью. Там в Visual VM Sampler-e нужно смотреть, какой код в очередной раз съел все ресурсы процессора. На всём коде будет тормозить, абсолютно на всём.
1. Индивидуальные запросы, как таковые, в Hibernate нормальные, можете включить дебаг и проверить. Проблема в том как Hibernate ими пользуется, и его весь остальной функционал. Hibernate (и JPA в целом) ужасная реализация ORM.
2. Вместо них, советую посмотреть Ebean ORM, выглядит намного лучше.
3. В любом случае, почти любой ORM нормально справится с подтяжкой ManyToOne графа, и это удобно. Все что сложнее, есть наивные запросы, что не значит, что не нужно использовать ORM для простых случаев. Вот только JPA не очень здесь способствует, и в частности не любит дружить с графами объектов, которые были сформированы извне, руками разработчика (что обычно происходит в случае ручного маппинга результатов нативного сложного запроса). Ebean опять же здесь смотрится лучше.
4. По поводу реактивных драйверов. Известная статья HikariCP по поводу размеров connection пула к базе даёт понять, что не так уж и много одновременных запросов мы можем себе позволить, а значит и подключений (потоков) тоже. Тогда в целом реактивность, которая в теории даёт кучу подключений за дёшево, особо и не вперлась. А если же все таки ваша база способна выдержать сотни запросов, то это уже стоит вам столько, что наверняка можно себе позволить пару сотен потоков на бекенд приложении. В том числе, бекенды обычно в кластере, и возможности базы распределяются между ними всеми, так что пул каждого пропорциально нужно будет уменьшить.
5. R2DBC фу, ни ORM ни то ни сё. Слишком мало может.
6. Ждём продакшен Loom.
Spring Cloud Gateway. Единая точка входа или отказа: путь к non-blocking API gateway