LINUX.ORG.RU

Стек для Java-приложения в 21 веке

 , ,


0

4

Я застрял в прошлом. Пишу веб-приложения на сервлетах (ну т.е. сверху там и Spring MVC может быть и Wicket и JSP, но снизу сервлеты), пакую их в .war, пускаю в томкате. Приложений около десятка, все работают с двумя базами (ну т.е. баз две, какие-то работают с одной, какие-то со второй, какие-то с обоими).

Что я имею:

  1. Унифицированный конфиг. Все значения определяю в server.xml в глобальном JNDI, к которому линкую приложения. Общий пул соединений с базой.
  2. Унифицированные логи. Хотя раньше делал логгирование в каждом приложении отдельно, удобней пользоваться великим и ужасным java.util.logging-ом.
  3. Parallel deployments. Очень крутая фича. Выкатываешь новую версию, ждёшь, пока на старой сессии не истекут, убираешь старую, никто ничего не заметил. Ну если надо, можно сразу старую убрать, тогда вроде сессия вылетит, надо перезайти. Наверное можно и без перезахода это всё сделать.
  4. Можно на венде одним движением руки создать сервис. На линуксе тоже актуально, если хочется запускаться от рута и потом сбрасывать привилегии (например для биндинга на 80-й порт).
  5. Всё в одном месте, порты там указать, ключи из keystore подгрузить для https, всё уже в конфигах, всё написано.
  6. На всё про всё одна JVM, за все накладные расходы платишь один раз.

Но по сути это всё несколько устарело. Java EE сдохла, все пишут на спринге. Но как реплицировать подобное окружение, я не совсем понимаю.

Вроде как нынче пишут всё в толстых жарах, куда засовывают HTTP-сервер (тот же томкат).

Получается, что мне нужно запускать десять JVM-ов? Не очень хорошо с точки зрения потребления ресурсов. Тем более, что Java не отдаёт память.

Будет десять тред-пулов? Опять же не очень хорошо. Сейчас тред пул один (в смысле два), видно, сколько коннектов надо. Оцениваешь все приложения в сумме. А так придётся каждое приложение исследовать и давать огромный запас, чтобы потом в СУБД разрешить столько соединений. Вроде тоже не очень хорошо с точки зрения потребления ресурсов. Тем более, что коннект к базе данных порой по 10 секунд висит, пока соединит.

В каждом приложении свои настройки логов будут. Получается нужен ещё какой-то сервис, куда сваливать все логи, чтобы хотя бы error-ы в одном месте видеть.

Всякие сервисы надо будет делать самому, причём для каждого приложения отдельно. Гемор.

Придётся ставить реверсивный прокси перед приложениями. Кстати какой? Чтобы позволял деплоить без даунтайма.

И причём не понятно, зачем всё это. Собственно тред про это - посоветуйте, как это всё нынче делают и зачем это всё делают? А то вроде томкат старый, но чем его заменять - не понимаю.

Пожалуй единственный существенный плюс: баг в одном приложении не повлияет на другие. Например если начнёт течь память, достаточно перезапустить одно приложение. Ну и при обновлении нет риска того, что старое приложение останется висеть из-за какой-нибудь ссылки (хотя это маловероятно, если аккуратно всё писать).

★★★★★

Можно на венде одним движением руки создать сервис. На линуксе тоже актуально, если хочется запускаться от рута и потом сбрасывать привилегии (например для биндинга на 80-й порт).

Стоп-стоп, что мешает из линукса движением одной руки делать также (на не 80 порту, разумеется)?

Получается, что мне нужно запускать десять JVM-ов? Не очень хорошо с точки зрения потребления ресурсов.

На разных машинах кластера, разумеется. :-)

Придётся ставить реверсивный прокси перед приложениями. Кстати какой? Чтобы позволял деплоить без даунтайма.

haproxy?

Собственно тред про это - посоветуйте, как это всё нынче делают и зачем это всё делают?

Сейчас что-то вот такое «стильно, модно, молодёжно» (книжку не читал)

https://www.amazon.co.uk/Microservice-Patterns-examples-Chris-Richardson/dp/1617294543

BattleCoder ★★★★★ ()
Последнее исправление: BattleCoder (всего исправлений: 3)

Сейчас люди используют spring boot и подход микросервисов. А так же облака, docker, kubernetes, zookeeper и прочие умные слова.

P.S.: если не хочешь платить памятью и cpu за рантайм JVM - попробуй Go, там рантайм маленький, по слухам.

TheKnight ★★ ()

Часто вижу, что через JVM реализуют сервисы на основе REST, а вот HTTP и подобное клиентам отдается через другой уровень, реализованный на той же ноде с жабоскриптом, например. В таком случае браузер клиента посылает запрос к ноде, нода чего-то там делает, дергает кучу запросов по REST у сервисов, сервисы что-то отдают, и тогда нода уже формирует HTTP с жабоскриптом и CSS.

В такой схеме томкат с сервлетами особо и не нужны, а сервисы можно реализовывать не только на Java, да и не только на JVM. Деплой - уже отдельная тема, я в ней не разбираюсь.

dave ★★★★★ ()
Ответ на: комментарий от menangen

Всё движется к Kotlin Native.

Для Kotlin’а всё ещё нет фреймворков, подобных Spring’у и Spring Boot’у. Ktor до сих пор выглядит сырым. Мир Java движется в сторону новых фич в новых версиях Java и к GraalVM в котором уже можно попробовать замутить нативное Spring-приложение, без всяких Kotlin Native:

https://github.com/spring-projects-experimental/spring-graal-native

Так что Kotlin’у похоже останется только занять нишу Scala и Android-разработку, ибо в нём шаг влево, шаг вправо всё равно натыкаешься на усы Java «под капотом», а коль так то зачем нужна дополнительная прослойка-сахарок над Spring’ом? Тем более некоторые архитектурные решения вроде all-open-плагина попахивают костылями.

EXL ★★★★★ ()

Вот так и делают, тащат 10500 толстых жарников и обмазавшись спрингом деплоят это всё в докеры. Микросервисы это не про экономию и удобство.

ya-betmen ★★★★★ ()

Я линейный кодер в энетерпрайз - spring-boot + spring-cloud, все вериться в кубрентетс.

Ничего не поменялось. Очень толстые микросервисы, уж точно не микро, просто отдельные монолитики над которыми работают отдельные команды. Раньше эти микросервисы называли инфраструктурными проектами, типа сервер авторизации и т.д.

Получается, что мне нужно запускать десять JVM-ов? Не очень хорошо с точки зрения потребления ресурсов. Тем более, что Java не отдаёт память.

Есть подвижки, ряд GC научился отдавать память системе, только надо еще поискать как этот GC включить и в какой версии JVM нужный GC есть.

Будет десять тред-пулов?

Да.

удобней пользоваться великим и ужасным java.util.logging-ом.

slf4j + logback стал стандартом.

В каждом приложении свои настройки логов будут.

Так и есть, по крайне мере там где я работал.

Получается нужен ещё какой-то сервис, куда сваливать все логи

Для сбора логов используют стек ELK

А то вроде томкат старый, но чем его заменять - не понимаю.

Нет. Он из коробки используется как встроенный сервлет-контейнер в spring-boot, для WebMVC выбор только между tomcat и jetty. Для spring webflux выбор будет больше, т.к. он не привязан к servlet api.

И причём не понятно, зачем всё это. Собственно тред про это - посоветуйте, как это всё нынче делают и зачем это всё делают?

Делают по новому из-за микросервисного подхода. Он позволяет разбить разработку на множество команд, где у каждой команды свой релизный цикл, даже свой стек и другой язык. Другого ничего не дает, если не проектировать high availability сервис самого начала то получается микросервисная архитектура со множеством критических точек, ничем от модульных монолитов не отличающиеся кроме ввода механизмов обмена сообщениями.

Судя по описанию у тебя все очень хорошо, ищи узкие места и смотри что может из современных подходов помочь. В моем мире очень много каргокульта, ощущение что берут что-то и слепо пытаются приспособить даже не задаваясь вопросом, а какую проблему это должно таргетировать.

Aber ★★★ ()
Последнее исправление: Aber (всего исправлений: 2)
Ответ на: комментарий от menangen

Ничего не движется к Kotlin Native, откуда ты это берёшь? .net может компилироваться в нативный бинарник и Java тоже, говорят, может(или сможет в будущем). Так а о чём речь?

anonymous ()

ну на нижнем уровне и спринг работает с сервлетами и контейнером сервлетов иначе он работать не может по дизайну веб-джава приложений. Если честно я вообще не понимаю этого противопоставления, т.к. спринг просто высокоуровневая «нашлепка» на «сервлетную базу», а из шапки темы складывается впечатление что у вас какое-то противоречие. Если да, то нужно просто поизучать требуху спринга чтобы понять что это все еще та же «сервлетная» джава, просто пересыпанная пудрой.

abcq ()
Последнее исправление: abcq (всего исправлений: 1)
Ответ на: комментарий от ya-betmen

Так с любым кодом и технологией, если «прокладка» между креслом и клавиатурой «неумная», то и ждать какой-то экономии и производительности не приходится.

abcq ()
Ответ на: комментарий от anonymous

.net может компилироваться в нативный бинарник и Java тоже, говорят, может

Никогда они не смогут. Максимум - запаковать свой рантайм в нативную обёртку и JIT'иться по-чёрному.

Для жабы был когда-то GCJ, но сдох ввиду отсутствия рефлексии и, как следствие, неработы всех более-менее сложных либ.

anonymous ()
Ответ на: комментарий от abcq

Спринг на какой-нибудь undertow переедет завтра и прекрасно будет работать без сервлетов. А сервлеты уже никуда не переедут. Жава 9 фиг знает когда вышла, а поддержки модулей в Java EE даже на горизонте нет.

Legioner ★★★★★ ()
Ответ на: комментарий от Legioner

Servlet 4.0

Undertow provides support for Servlet 4.0, including support for embedded servlet. It is also possible to mix both Servlets and native undertow non-blocking handlers in the same deployment.

Никуда они не денутся вы зря паникуете, это наоборот хорошо что вы базовую технологию знаете на которой уже строятся всякие спринги и прочая шелупонь.

По поводу девятой джавы и ее EE амплуа, ну скажем так, а на кой черт оно вообще нужно если весь ЕЕ код до сих пор с 6 на 7 перебирается тихой сапой, ЕЕ не та область где любят перемены.

abcq ()
Последнее исправление: abcq (всего исправлений: 6)

И причём не понятно, зачем всё это.

Микросервисы это про распределённые команды и распределённые архитектуры. А самое главное часть можно отдавать на аутсорс. И это гигантский плюс, для больших проектов. В остальном это треш угар и содомия, таково моё мнение.

vtVitus ★★★★★ ()
Ответ на: комментарий от menangen

Часто я сам себя спрашиваю, 20-30 лет для языка программирования или другой технологии это много?
И чтоб ответить себе на вопрос я просто отнимаю сто лет от фактических дат:

  • 1896 появляется java 1.0
  • 1920 java в топе языков

Просуществует ли она до 1940 года? :)

Aber ★★★ ()
Ответ на: комментарий от menangen

Swift/Rust/D

Это тот же самый алгол-70, что и джаба, что и плюсы, только вид сбоку. Ничего из будущего в них нет. Кривое, устаревшее в момент выхода, говно, на которое только хипстеры вроде тебя, с нулевым кругозором, и дрочат.

lovesan ★☆ ()
Ответ на: комментарий от menangen

Эм, а что в этих языках такого?Свифт это яблоко со всем вытекающим, Ди - мертворождённый язык,который то убийца крестов, то betterC, то с ГЦ, то ГЦ выпиливаем, то вводим лайфтаймы. Он уже гораздо хаотичный крестов притом ещё с мертвой инфраструктурой. Раст интересен работой с памятью, не более, как масштабный промышленный язык он вялый до сих пор, хотя времени уже прошло уйма. Что они могут предложить такого, что не дают кресты/C#/java?

anonymous ()
Ответ на: комментарий от lovesan

Я такие же фекалии здесь читал про Django и про то, что он умер не родившись и т.п. а по факту, всё оказалось наоборот, что и Java многим не сдалась, а те, кто хотят в быстрый старт своих микросервисов, уже давно пишут и даже переписывают на Go

menangen ★★★★★ ()
Ответ на: комментарий от anonymous

Swift - это опенсорс, а не яблоко. Кресты держатся только за счёт инертности разработки, как и java. Написано куча софта уже готового, и взять и выкинуть C++ в пользу Swift только Apple и сможет, другие компании тупо не потянут. Ну, и мелкие конторы. Да и далеко не всем нужен C++, зачастую там, где C++ используют - можно легко обойтись Go

menangen ★★★★★ ()
Ответ на: комментарий от anonymous

А что такого даёт C#/Java? Жирный рантайм и жор памяти на старте в пол гига даже на простых http api? Эти языки - тупо для промышленной разработки в гигантских компаниях, где куча людей, где не считают железо и расходы на него, а на серваках зачастую 80% win server

Любовь к C#/Java/C++ зачастую исходит от того, что это попсовые языки, под которые куча книг, IDE для тупых и всё такое. А как только язык хорош, но инфраструктура вокруг языка не развита - хомячки сливаются, им сложно

menangen ★★★★★ ()
Последнее исправление: menangen (всего исправлений: 1)
Ответ на: комментарий от Aber

В моем мире очень много каргокульта

Можно поподробнее? Это в java api/http? Похожее мнение у пару моих друзей, хотелось бы услышать весёлые истории из жизни 😀

menangen ★★★★★ ()
Последнее исправление: menangen (всего исправлений: 1)
Ответ на: комментарий от menangen

И что, много где за пределами яблока его используют?Много вакансий не для разработки под мобилочки, в что-то другое? Выкинуть кресты в пользу сфивта?Ты прикалываешься или как?С каких это пор Свифт может конкурировать с крестами? В каких областях?

anonymous ()
Ответ на: комментарий от menangen

Дают скорость, надёжность, инфраструктуру, библиотеки, большое количество разоаботчиков.И я не знаю, что ты за классные истории рассказываешь, но шарпе и жабе пишут кто только может, а не только гигантский кровавый тырпрайз.За пару-тройку десятков баксов сервочка тебе хватит на все твои хотелки. Взять в частности сишарп - плохой что ли язык?У него выразительности не сильно меньше, чем у того же Ди. А .net core так вообще вдохнул в него жизнь. Быстрая, удобная платформа, много кушать не просит. И не медленне сфивта, если не быстрей.

anonymous ()

Java не отдаёт память

4.2, все она отдает, нехрен пускать на дефолтном конфиге GC, курить можно здесь предварительно поскипав все про контейнеры - https://developers.redhat.com/blog/2017/04/04/openjdk-and-containers/

Только это конечно не причина пускать 10 JVM - пускай одну.

Грааль+Substrate жутко сырой, работает только на helloworld’ах, никакие библиотеки его не поддержкивают и не будут - втопку, это не жаба получается, без библиотек проще на го/расте писать.

anonymous ()
Ответ на: комментарий от menangen

https://wiki.dlang.org/Programming_in_D_for_CSharp_Programmers Посмотри, твой Ди несильно и отличается от Шарпа. При этом там не последний шарп используют. И язык развивается в сторону лаконичности и удобства. А в какую сторону развивается Ди я думаю никто и не знает. Мало ли, чего они захотят завтра, сколько раз они метались из стороны в сторону.

anonymous ()
Ответ на: комментарий от menangen

И сколько там ещё десятилетий нужно Ди, чтобы на нем начали писать? Сколько времени нужно ещё расту? Про Свифт мы говорить и не будем, такая же штука, как и обжектив Си - вродей он и не только пол яблоось, но никому не нужен был вне загончика.Без библиотек Сфивт (это тормознутое поделие) не нужно. Да и с ними под вопросом нужность.

anonymous ()
Ответ на: комментарий от anonymous

Как swift может тормозить, если он компилируется в натив llvm’ом? И Objectiv-C, и Swift быстрее C#, так как по сути являются обёртками над Си, а у C#/java целая vm с jit, сборщиком и прочей коробкой, да и ещё и не в одном экземпляре. Swift по скорости не сильно от Си отстаёт, так что не убедил. Даже Go заруливает Java и C# по скорости работы кишок и конечного сетевого софта

menangen ★★★★★ ()
Ответ на: комментарий от anonymous

А где его щас применяют то? Последнее, с чем я сталкивался - это Node.js и V8, больше его нигде и не встретишь в сетевом программировании под Unix/Linux. А остальные области всё-равно не развиты под линукс, что там на винде, все эти прикладные штуки - узкая ниша, железо и прочее - примерно также, а где ещё нужен C++?

menangen ★★★★★ ()
Ответ на: комментарий от anonymous

И я не знаю, что ты за классные истории рассказываешь, но шарпе и жабе пишут кто только может

За последние 8 лет я сталкивался с софтом (который не мной писан) Java/C# только:

  • банки и апи
  • майнкрафт
  • ide
  • пару утилит под винду

Всё

А в моей работе кругом Python, Node.js, Go, Swift - всё в порядке убывания частоты использования

Например, в последнем проекте американской книгопечатной/учётной промышленности - 18 микрослужб, около 3-4 на Go, остальные на питон, веб морда на Vue - вот реалии рынка

menangen ★★★★★ ()
Ответ на: комментарий от anonymous

И сколько там ещё десятилетий нужно Ди, чтобы на нем начали писать?

А на нём уже пишут, но если ты про «чтобы … начали массово писать», то реальность жестока - без крупной поддержки корпорации и вливания бабла и хайпа ни один язык массовым не станет. Не то время. Все хотят на всё готовое придти, а это колоссальная затрата энергии для открытого сообщества, это как Wayland пилят уже хер знает сколько, а так и не перешли - и ещё лет 10 не будут переходить, так как конкуренты винде и мак не нужны в лице сильной/удобной/быстрой/открытой операционки - ведь придётся и свои ос открывать

menangen ★★★★★ ()
Ответ на: комментарий от anonymous

язык развивается в сторону лаконичности и удобства

Это ты про C#? Если бы про F# - то было бы похоже на правду, но микрософт по сути взяли Java и скоммуниздили всё, а уж поверх просто сахар, который начинают растаскивать между всеми платформами: C# копирует Java, затем Java копирует C#, потом они начинают тащиться от асинхронности и вкорячивают асинк в C#, в Java появляется RX, и это калька с Node.js, так как все очканули новичка, затем потащат с Котлина фичи, и так по кругу

menangen ★★★★★ ()
Ответ на: комментарий от menangen

У каждого свой кругозор. Не стоит судит о мире по нему. Я, например, Python, Node.js и Go не видел вообще нигде. Все пишут на Java/C#.

Кстати HTTP-сервер на Java прекрасно вмещается в 16 МБ.

Legioner ★★★★★ ()
Ответ на: комментарий от menangen

За последние 8 лет я сталкивался с софтом (который не мной >писан) >Java/C# только:

банки и апи
майнкрафт
ide
пару утилит под винду
Всё

Ухты назвал 80% нужного софта. Да открой магазин винды, и о чудо 99% написано на .Net(в 90% случаев это C#).

А в моей работе кругом Python, Node.js, Go, Swift - всё в >порядке убывания частоты использования

Ты сажаешь свеклу, и вращаешься среди фермеров свеклы, у вас везде мерещится свекла.

Например, в последнем проекте американской книгопечатной/учётной >промышленности - 18 микрослужб, около 3-4 на Go, остальные на >питон, веб морда на Vue - вот реалии рынка

Для проектов на Java уж извините это уровень Hello, world. И это ваши реалии, а не рынка. Открываем любой агрегатор Вакансий вводим ключевые слова, и реалии рынка показывают, что может быть питон в этих реалиях и присутствует в верху списка, но царствуют Java, C#, C++, PHP.

Smetchik ()

Пока тебе не нужна горизонтальная масштабируемость и отказоусточивость - вполне нормальный подход.

10 тред-пулов

Ты наверно хотел сказать пулов соединений? Чтобы с этим не было проблем перед базой ставят пулер соединений.

maloi ★★★★★ ()