Comments 99
Насчет OSGi… OSGi фигня какая та, и да, JVM плохо пока справляется с Hot Swapping'ом.
Если ставить вопрос: JVM круче чем Docker? Ответ однозначно, да. Но… мы тут сравниваем яблоки с апельсинами.
Я нарочно здесь пел хвалебные песни. Но я ведь отметил, что недостатков хватает. О них расскажут другие.
На мой взгляд, в современных реалиях Ява может найти применение именно в виде легковесных лямбд, целиком грузить процессы слишком накладно. Причём для легких функций больше подойдут именно EJB, Spring в данном случае проигрывает как монолит и его уже вытесняют Quarcus и аналоги.
Это опять же смотря где. В GlassFish плагинами являются по сути сами приложения, если я ничего не путаю. И они устанавливаются при каждом деплое.
Можно пруфчик про боль?
*пикосервисы. Официально бандлы называются пико-, а не микросервисами. И, как мне кажется, не просто так:
Проблема с OSGi в том, что с точки зрения масштабирования, эффективно это монолит. То есть никакого горизонтального масштабирования сервисов(по крайней мере, я не встречал такой возможности), только вертикальное.
Ещё одна проблема — нестабильность и ошибочные состояния. По моим внутренним ощущениям, вероятность, что при установке нового бандла ничего не сломается — 99%. При обновлении старого — 99.9%. Но если что-то сломается — последствия могут быть самыми разными.
Я встречал:
- "застрявшую" установку(лечится перезагрузкой)
- бандл включён, но не работает(лечится удалением и установкой)
- бандл написал, что переустановился, но на самом деле этого не сделал(удаление и установка, в лучшем случае ап версии)
- "osgi пошёл в разнос"(перезагрузка)
- всё приложение упало
- бандл не установился и его не возможно установить(перезагрузка)
- бандл сломал другой бандл из-за того, что по невнимательности у них оказалось одинаковое название (удалить ошибочный бандл после недель отладки).
Это то, что я вспомнил "прямщас" из своего опыта работы с Atlassian Confluence. Бандлы не зависели друг от друга, только от системных.
Конечно, при разработке десктопных приложений это не проблема, но если делать что-то с высокими требованиями к устойчивости и доступности (или, не дай бог, SLA 99.999), то OSGi(на мой скромный взгляд) представляет собой ужасное решение. Что бы они сами там не говорили.
Это в смысле кластер что-ли? Я вам скажу, что это не только встречается, но и весьма просто. Скажем, karaf + cellar = профит. Вариантов посложнее вообще куча.
Что до всего остального, то я не понимаю, как вам удается такие результаты получать. Никогда за много лет такого не видел, ни на карафе, ни на эклипсе. Может, проблема в самом конфлюенсе все же?
Хм. Благодарю. Похоже, у меня сложилось ошибочное мнение о масштабировании osgi-приложений.
Не удивлюсь, если описанные косяки — действительно проблемы конфы. Ну, или феликса, на котором построена конфа.
Хотя, у у меня появилось ощущение, что я понял, почему одни ругают, а другие славят OSGi.
Те, кому OSGi зашёл, писали на нём свои приложения.
Те, кому он не зашёл, пытались писать плагины под уже существующие гигантские легаси-комбайны, на которых проявились все технические проблемы и накопившиеся архитектурные косяки.
Ну или это проблема тулинга, возможно. Скажем, вот это:
>бандл сломал другой бандл из-за того, что по невнимательности у них оказалось одинаковое название
Ну, вообще говоря, одинаковое название — это вполне штатно. При разной версии. Понятно что если ваших бандлов сотни — то выявить это может оказаться не так просто, но в карафе я бы это обнаружил скорее всего почти сразу. Там у конфлюенса вообще консоль есть, где можно было бы список бандлов посмотреть?
И самое забавное что все это было еще со времен Java 6.
Но приколы с патентами от Oracle, куча платных библиотек которые сегодня есть а завтра уже история и распространяются только в уже скомпиленном виде без возможности модификации, лагающий Eclipse на основе которого +100500 IDE. Сложность всего этого добра для освоения ( я еще студентом бросил Java в web после того как попытался понять web.xml от tomcat ) превращаются в лютый Ынтенпрайз от которого стынет кровь в жилах. Про JavaEE "hello world" только ленивый не шутил.
Сейчас времена поменялись — есть Idea которая шикарна и позволяет компилироваться только ту часть байт-кода которая поменялась а не ждать 10 часов из за изменений в 2-х строчках, есть Android. OpenESB и Apachee Talend тоже шикарные вещи которые использовал. Для запуска одиночного сервиса не нужно долго подымать JavaEE сервер — достаточно упаковать его в тот-же docker.
Только время уже упущено и на все это смотрят как на жуткое legacy а Oracle все еще пугает патентами. Тот-же Google вынужден платить, терпеть и пилить матерясь про себя свою Fuchsia.
Меня всегда интересовало, почему разработчики яваее жалуются на долгий деплой. Если у вас приложение не монолит, а цивилизованно побито на небольшие модули, как то: еджби и вареники, то проблем с инкрементальной сборкой и даже деплоем не будет. Один небольшой EJB деплоится в считанные секунды. Это быстрее и удобнее, чем любые микросервисы.
Ясно понятно, что под завязку нагруженный сервер стартует довольно долго. Но его не надо стартовать часто. Раз в неделю вполне достаточно. Вы же не разворачиваете кластер Кубера каждые полчаса?
Дело в правильном планировании и организации работ.
с PHP, где долгоживущие сервисы писать было больно
Да и сейчас больно. Но и смысла в долго живущих сервисах не так много. Сервисы с api где достать данные и выдать в определенном формате и возможно закешировать — проще простого.
Если нужно обработать поток данных то RabbitMq или Kafka + php тоже все ок.
Так что остается только стримы аудио и видео — там да постоянно открытый сокет и постоянно живущий сервис. Вот только с этим и голый nginx справляется на отлично.
Если же нужна еще и модификация этого контента на лету — тогда да тут и подключаются go/java/python/etc...
В этом-то и разница на мой взгляд, что я (если приспичит) легко (ну, или не очень) напишу кафку на Java, а вам придется взять готовую. Т.е. по сути, если долгоживущие сервисы писать больно — то вы их либо не пишете, либо используете написанные на других языках. Отсюда никак не следует, что они не нужны как таковые. Любая СУБД — это долгоживущий сервис. В них тоже нет смысла? :)
Эмм и часто приходиться писать свои базы данных ?
K8s просто так не развернешь, для этого требуется целая орава админов. И это своеобразное препятствие разворачиванию проекта целиком. В итоге никто не знает, как работает весь стек.
Либо прогресс за 3 года скакнул выше головы, либо мы имеем в виду разные вещи. Если 3 года назад требовалось 40 админов, чтобы поднять приличное приватное облако на кубере. Откуда вы взяли 1 человеко-день. Что в итоге сможет его облако? Да его на подготовку металло-базы не хватит в размере больше 10 нод. Я же не про миникуб говорю, а настоящую систему.
Ну, во-первых, меня до сих пор интересует зачем вообще делать деплой, если мы не на продакшне. Это бесполезная операция. Функция public static void main(String… args) до сих пор не deprecated, а весь функционал сервера приложений доступен ввиде библиотек или фреймворков.
Во-вторых, если это хеллоу ворлд, то да, все быстро. Однако обычно бизнес приложение тащит за собой еще стопицот сторонних джарников, поэтому развертывание такого приложения на сервере будет не слишком быстрым, ибо львиная доля тратится на резольвинг классов. И ждать после каждого изменения, когда все классы заново отрезольвятся и передеплоятся — это то, почему в свое время люди свалили из джавы на более легковесные решения. А если ваш суперсервер не может деплоить прямо из workspace, то добавьте сюда еще рудиментарную запаковку-распаковку.
Хорошее решение сделано в Spring Boot Devtools: там разделены контексты класслоадеров на статические — которые грузят из джаров (которые в свою очередь редко меняются) и динамические — которые грузят из .class вокрспейса. При изменении в файле класса спринг перезагружает контекст, при этом оставляя статические класслоадеры, которые уже отрезольвили все необходимые зависимости. В итоге приложение апдейтится за секунду.
Так это вы про Спринг, который монолит. Java EE не пробовали использовать?
Монолит — слово-вирус, придуманное и разрекламированное PR-менеджерами для продвижения клауд решений. Поэтому не стоит бездумно изпользовать его везде как штамп. Не существует ни монолитов ни микросервисов. Существует приложение и функциональные модули, и особняком стоит архитектура решения как способ взаимодействия модулей. И спринг как бы здесь ни при чем.
Я поневоле использую JavaEE с 2005 с открытыми и коммерческими серверами вкупе с кучей проприетарного барахла, которое шло поверх. Причем, сколько использую, столько плююсь — платформа реально мешает выполнять задачу, ограничивает и усложняет многие вещи, которые без нее сделать в разы проще.
Спринг является монолитным независимо ни от каких слов-вирусов, поскольку разбить его на модули в рантайме нельзя. Проблемы будут уже при попытке запуска второго контекста. И всё потому что Спринг изначально отдал предпочтение простоте, разменяв на нефункциональные возможности ПО.
В целом, как замена пхп он работал, поэтому и снискал популярность в студенческой среде. Но итог эволюции был предсказуем и никакие костыли, пытающиеся превратить Спринг то в наносервисы, то наоборот в интегрированное решение наподобие Java EE, уже не помогут.
Спринг является монолитным независимо ни от каких слов-вирусов, поскольку разбить его на модули в рантайме нельзя.
Один вопрос — нафига? Модуль — логическая единица, а не физическая. В одном процессе и контексте могут сожительствовать сколь угодно много модулей. Сделать инъекцию бина и локальный вызов метода гораздо проще, чем городить API, усложнять архитектуру и искать себе проблемы там, где их нет. Какие конкретно насущные задачи решит разбивка на разные deployable units?
пытающиеся превратить Спринг то в наносервисы, то наоборот в интегрированное решение наподобие Java EE, уже не помогут
Это все-равно что превращать трамвай в паровоз. Spring стал популярным именно как замена JEE, сначала предоставляя более простой слой интеграции с ней, а затем как независимое решение. И уже JEE в надежде удержать юзеров стал таскать идеи из спринга, например CDI.
Для запуска одиночного сервиса не нужно долго подымать JavaEE сервер — достаточно упаковать его в тот-же docker
превращаются в лютый Ынтенпрайз от которого стынет кровь в жилахЛюбой профессионал хотя бы должен знать о существовании термина "нефункциональные требования к ПО". Но если вдруг не знаете, то вот и вот минимум. Физическое разбиение на микросервисы потому и появилось, что при разработке в Спринге невозможно логический модуль независимо развернуть. Да, девтулс частично и не всегда стабильно решает эту проблему. Его проблема ещё и в том, что нужно по мере разработки сдвигать границу между статической и динамической логикой. И всё равно динамическая часть как правило довольно большая и её перезагрузка тоже требует немалого времени.
Я не отрицаю что у Java EE до 6 версии были серьёзные проблемы со сложностью разработки. Помнится, я сам, когда тоже будучи студентом пытался разобраться, как работают EJB. И меня тоже несколько смутила необходимость понять структуру их вызовов, написания нескольких требуемых интерфейсов и ещё пары -тройки классов к ним. Но если бы у меня была тогда возможность, думаю, что я разобрался бы. Ведь мои однокурсники вполне себе сносно работали с тогдашними энтерпрайз-системами и не жаловались.
Но следующий мой опыт был уже с вышедшей к тому времени JavaEE 6. И удивляясь тому, насколько все упростилось, я за пару недель накидал вполне себе работоспособный проект на стеке JavaEE 6, со всеми его преимуществами.
Теперь проиллюстрирую на реальном примере, не очень большом проекте, в котором без EJB я бы большую часть рабочего времени медитировал.
Было простое веб-приложение, которое доставало из базы сущности, процессило их и сохраняло назад. Сложность в том, что сущности надо было нетривиальным образом в базе найти, а логика зачастую зависела от данных. Т.е. смотришь на то, какие есть данные — пишешь логику их обработки. Так вот, загруженные данные сохранялись в веб-контексте, который на JSF. Логика поначалу была вынесена в локальный то ли е-бин, то ли именной бин. Проект собирался на месте (компиляция при сохранении включена), но JRebel я не использовал, и при изменении чего-то большего, чем тело метода, происходил полный передеплой (тоже автоматом кстати). В моём случае это само по себе не было большой проблемой, т.к. в проекте всего несколько бинов. Но вот веб-контекст при этом сбрасывался и надо было его начинать заново. Обидно было. Скоростная разработка страдала.
И тут на помощь как раз пришли remote версии EJB. Выносим логику в отдельный физический модуль — тип соответсвенно EJB. И собираем и деплоим этот модуль отдельно. Веб-часть с её контекстом остаётся нетронутой (кто бы что не думал по этому поводу). Даже транзакция к базе нормально предсказуемо работала. То есть имеем кэшированный контекст, который вызывает меняющуюся постоянно логику (меняется только внешний EJB-бин). И всё работает! Размер модуля EJB — десятки килобайт, который деплоится за 200 мс, поскольку все веб-либы и прочий хлам вынесены отдельно и прогреты с кэшем.
Вот зачем нужно разделение на модули в физическом смысле.
А по поводу CDI — это во многом повторение EJB 3 версии, без их преимуществ. Попробуйте в CDI организовать транзакцию.
Чтобы разделить business и web tier не нужен JEE сервер — для джавы есть 100500 легких технологий ремоутинга. Помнится мы в свое время (лет 15 назад) использовали RMI. Сейчас это модно делать при помощи Rest API. Запускаются локально два процесса: business и web, по мере необходимости рестартится любой из них.
Теперь по поводу вашего проекта. Вангую:
- Функционал проекта не выходит за рамки базы данных и веба
- Вы единственный разработчик
- У вас нет ни одного автоматического теста
- Конфигурация сервера и ресурсов лежит отдельно от кода
- Вы используете Eclipse и ваш проект сильно завязан на его тулинг, отсутствуют средства автоматического деплоя
- Вы используете какой-нибудь opensource сервер, типа Glassfish или TomEE
- Отсутствует более чем полностью параметризация приложения
- Не используется CI/CD
А по поводу CDI — это во многом повторение EJB 3 версии, без их преимуществ. Попробуйте в CDI организовать транзакцию.
Скорей без их рудиментов. С JEE7 бины умеют транзакцию.
Заметил, что на хабре переиначивают лексику. Вообще, ванговать — значить предсказывать, прогнозировать (с иронией), от прорицательницы Ванги. А проект этот из прошлого.
Да, вы правы во многом, проект делался мной одним и никаких наворотов поверх него не делалось, поскольку это по сути была временная утилита, которая разрабатывалась прям на лету. Она сделала своё дело за 2-3 дня разработки и всё. Поэтому:
- Функционал всего проекта выходить мог далеко. Но конкретно для этой тулзы нужно было подкорректировать/рапарсить данные в БД.
- Да, единственный и неповторимый
- Тесты, конечно, были на начальном этапе, модульные, 2-3 штуки.
- Поскольку это JEE сервер, конфиг для всех подпроектов я записал один раз на этот сервер — датасорс, после чего он используется всеми причастными веб-приложениями. И не надо его копировать по нескольку раз.
- Я использовал Netbeans, потому что в нем как раз лучшая интеграция с сервером. Именно из-за того что проект завязан на тулинг только в плане интегрированной разработки на сервере, разработка происходит моментально, с мгновенным фидбэком. Код компилируется и деплоится, не успеешь ещё кнопку сохранить нажать — каждые несколько секунд. Если сложный случай — сигнатуры методов поменялись — то автоматический редеплой прям на месте, почти незаметно (2-3 секунды). Шаблоны JSF подхватываются как статика. Сам проект да, это нетбинс, т.е. скрипты анта. Но никто не мешает рядом положить хоть мавен, хоть грэдл.
- Это был эталонный Glassfish. Скорость работы, деплоя и абсолютная интеграция с ИДЕ не заставляли смотреть на аналоги.
- Конкретно для этого одноразового приложения параметризация была не нужна. Хотя её несложно настроить в сервере. И какое это имеет отношение к обсуждаемому? Параметризованный каркас не мешает перезагружать бины с чистой логикой. Логика, конечно по конкретным данным работала из контекста.
- Здесь CI/CD попросту не нужен был, интегрироваться не с чем, результат работы — новая версия БД. Хотя потратить время, сделать — вполне возможно было.
мы в свое время (лет 15 назад) использовали RMI. Сейчас это модно делать при помощи Rest API
EJB как раз на RMI в одном из вариантов. Все другие коннекты не прокидывают контексты и транзакцию. Вы подцепитесь по Rest, а управление ошибками и транзакциями потом будете делать вручную, изобретать велосипед. И так в каждом проекте на Спринге.
Собственно все как я и предполагал. А теперь почему я никогда НЕ выберу JEE для своего проекта.
- Каждый девелопер в команде должен пройти дебильную ручную процедуру установки и конфигурации сервера локально на своей тачке. То же самое нужно сделать для каждого environment, сервера CI/CD, etc. Конфиги сервера всегда хранятся отдельно от проекта бог знает где и нередко недоступны ввиде файлов. Поэтому правильно делают те, кто пакуют сервер с приложением в докер.
- Вам повезло, что ваш сервер OpenSource. Коммерческие решения как правило не так приветливы к программеру (по секрету скажу, что вендорам насрать на девелоперов: их целевая аудитория — шефы) и как правило не умеют пускаться и деплоиться локально из IDE. Поэтому прощай нормальный дебаг и IDE и здравствуй коммандная строка и System.out.println().
- Все JEE решения сильно завязаны на тулинг (коммерческие IDE, плагины, коннекторы). Через пару лет тулзы апдейтнутся, и ваш проект тупо перестанет собираться или запускаться. Так у меня было практически с любым JEE проектом — через пару лет так просто поправить плевый баг или фичу без геморроя уже не удастся.
- JEE вообще не предназначен для юнит-тестирования. Когда он задумывался, еще даже не было такого модного слова. Во-первых в общем случае JEE не умеет пускаться из IDE локально в embedded режиме и цеплять приложение из workspace (в случае с Glassfish для вас это делает умный плагин к IDE). Во-вторых, не позволяет управлять сборкой контекста: то есть тупо нельзя динамически указать какие бины для теста нужно задеплоить, а какие нет, ведь весь bean-дискавери завязан на текущий classpath. Евангелисты JEE предлагали иметь на каждый тест свой maven-профайл, где указывается свой classpath с ресурсами, специфичными для теста, и пускать тесты вручную из мавена. В-третьих, нельзя программно установить конфигурацию сервера для конкретного теста, например когда ваш тестовый сервис должен послать месседж в тестовую очередь или законнектиться к другой базе данных. Особо продвинутые умудряются отделить всю логику от ресурсов сервера, обвешаться со всех сторон моками и тестировать локально без контейнера. Что конкретно они при этом тестируют — они не понимают сами. Конечно есть технологии типа TomEE и Arquillian, но это велосипеды, призванные криво обойти одно из важнейших ограничений JEE.
- Application-specific parameters вообще отсутствует как таковой. То есть тупо указать вебсервису, что тут на данной машине он должен вызывать этот URL, а на другой тот, будет связано с глубоким копанием JAX-WS и велосипедами ввиде отдельно лежащего файла .properties, достижимого по абсолютному путю, либо environment variables. С другой стороны, конфигурация приложения — это то, что из коробки предоставляет вообще любой фреймворк.
- Конкретно что такое дает ваш JEE, чего нет в библиотеках и фреймворках? Правильный ответ — JTA. Это то единственное, ради чего его используют в энтерпрайзе. Однако JTA — это один большой закамуфлированный архитектурный антипаттерн, который вы никогда не поймете до конца и никода не сможете настроить нормально. Все остальное делается проще, лучше и изящнее, нежели в JEE.
- Про кофиги это вообще отдельная история. Помнится, когда делали проект на Спринге, его настройки паковались под каждый профиль отдельно. Причём для продакшена и препрода эти настройки были пустые по понятным причинам безопасности в банке. Поэтому настройки прописывал админ, который деплоил наше приложение на банковский джбосс. И делал это перепаковкой архивов с приложением, рискуя ошибиться и сломать к черту всё приложение. И он ругался и плевался, поэтому я специально сделал запрос конфигов в Спринге из jndi контекста и боль пропала. Локально при разработке можно было продолжать пользоваться пропертями, но я этого не делал, потому что настроить сервер проще и логичнее.
По поводу сервера на каждого разраба: извините, если разработчик не может даже сервер настроить на основе имеющейся конфы, то что тогда он вообще может.
Отсутствие конфига сервера в проекте — это сугубо ваша личная боль. Если в проекте бардак, то сервер тут ни при чём. Для глассФиша можно конфиг отправлять онлайн прямо при деплое или заблаговременно. Но в целом, что в глассФише, что в джбоссе, что в Веб-сфере конфиг можно просто подложить целиком — самый простой способ.
На самом деле, когда у вас несколько конфигураций, то прописывать их вручную всё равно придётся, в лучшем случае через указание путей в среде окружения. Сервера приложений в этом смысле удобнее ещё и тем, что можно на одном инстансе запустить все сервера на каждый конфиг, и деплоить потом туда, куда требуется. Не нужно останавливать один сервер, чтобы запустить хотя бы один другой — память расходуется экономнее и, если руки прямые, конфликта по портам нет, как обычно бывает со спрингом. - Про коммерческие: если придерживаться стандартов, можно разрабатывать и на бесплатном. Хотя я описанные вами проблемы не встречал ни в джбоссе, ни в Веб-сфере. Есть свои особенности, но они преодолимы. В сфере логи можно настраивать и смотреть из панели управления.
- Апдейты — да, есть неудобства при переходе на новый мажорный релиз, коих всего то было три штуки за 10 лет. Но это меньшая боль, чем мажорный апгрейд Спринга или тем более смена его на нечто другое. Сфера сносно управляется мавен-плагином. А отладка так это вообще свойство JVM, а не сервера, её всегда можно включить и цепляться вручную, даже на удалёнке
- Мне кажется, вы путаете модульные и интеграционные тесты. Модульные — на классы и методы. Интеграция — с бинами.
Никакого волшебного плагина к иде я не знаю. Если хочется интеграции, то надо пускать встроенную версию глассФиша или джбосса вручную, т.е. программно (ну или с помощью плагина для junit). При этом можно нормально конфиг в контекст передать, не видел в этом проблем, когда редко это требовалось. - Про урл не понял, это клиентский что ли? Если серверный, то обычно он от контекста зависит, корень которого вполне задаётся. Если у вас параметры для приложения задаются извне, то это не параметры приложения, а параметры среды, и логично тогда параметры среды задавать в среде, т.е. на сервере.
- Я не видел нормальных альтернатив JTA. Кроме того, как я говорил, сама концепция — ты приносишь логику, инфраструктуру готовит заказчик — подходит для многих приложений. Даже для облака. Плюс не надо тратить ресурс в виде встроенных серверов и кучи зависимостей. Приложения лёгкие, они несут только логику самого приложения. Возможность запуска нескольких компонент независимо, но на общей базе экономит память и время запуска.
А коммерческие решения ещё и предоставляют масштабирование, балансировку и отказоустойчивость с меньшим геммороем, чем тот же кубернетос или редшифт, который средние компании вообще не потянут в приватной версии.
Э… вообще-то web.xml это примерно три вещи: сервлеты (просто список), фильтры (просто список), и маппинг URL на те и другие. Т.е. по сути — маршрутизация запросов в приложении. Пусть она сто раз кривая и неудобная — но это просто. Или вы шутите (я видел смайл, если чо), или ваша квалификация и выводы как бы вызывает некоторые сомнения.
Ну или точнее — это было так, как вы рассказываете, примерно до 2010 года, до JavaEE 6 версии и EJB 3-ей. С тех пор все изменилось.
Но даже и тогда, в 2010, никакого деплоя часами просто так не было. Да, у меня было приложение, которое деплоилось минутами. Из них несколько секунд — старт томката, остальное время — зачитывание в кеш (которым оно по сути и являлось) кучи данных, и их подготовка. Ну т.е. сам контейнер стартовал практически мгновенно (и это еще был старый томкат, до JavaEE 6). А уж как медленно могут стартовать ваши приложения — это вам решать, и больше никому.
Ну так после 2010 я пересел на стек с php, видел что да на GlassFish все действительно стартует быстро но мне уже на это было как-то пофиг. Поле 2018 пересел на node.js.
Далее по плану нормально изучить Ceph + k8s а после уже думаю развиваться в сторону go/rust/python.
На java за это время — написал только один сервис допилил — добавил в него провайдер который берет сертификат X.509 с хитрыми алгоритмами ГОСТ и подписывает XML. И то это так — считай ничего и не написал.
Ну, если это чисто ваше мнение, с учетом вашего давнего опыта — то может так оно и было. Только не очень понятно, какие выводы нужно сделать с учетом того, что за последние 10 лет очень многое изменилось? Ну т.е. вот реально — вы уже два или три раза стек сменили, а мне ни разу не пришлось — при этом я четырежды менял направления, оставаясь в рамках JVM. Какой из этих путей правильный? Вполне возможно оба — для каждого свой.
Скорее не сменил а расширил. Был только backend теперь fullstack.
Постоянно делать одно и тоже на одном и том же стеке оно конечно и удобно и даже прибыльно. Но вот поковырять и другие технологии тоже полезно и интересно. Да java тоже доберусь постепенно.
Ну т.е. можно было бы написать ОС, в основе которой была бы JVM на голом железе. Но это из оперы если бы да кабы.
В JavaEE и других фреймворках вполне хватает средств кластеризации. Только там немного другая гранулярность. В качестве инстанса выступает джвм с Веб-сферой, к примеру. Инстансы организуются в кластер и другие объединения.
Что касается ОС: у Оракла была такая система, JRocketVM. Это тоже не Линукс, конечно, но из него выдраны многие лишние компоненты. Лёгкая версия, скажем так. И позиционировалась для запуска на металле.
Для самой jvm по большому счёту, не нужна ОС, достаточно ядра. Причём я даже рассматривал варианты запуска в реальном режиме по причинам, описанным в статье.
Конечно хватает. Но это не делает из них ОС по умолчанию. И потом, берем тот же хадуп, и что мы там видим? Вместо AD — FreeIPA (не Java вообще), у Hive в качестве среды хранения метаданных — обычная СУБД (хотя можно в теории прикрутить скажем Derby, но никто этого не делает никогда. И много-много других компонент, которые взяты из линукса.
Кроме того, попробуйте из JavaEE приложения порулить тем, как ваши EJB распределятся по кластеру? Насколько я помню, такого API никогда и не было. А для кубера это чуть ли не основное. Ну в общем я согласен с тем, что JVM могла бы во многих случаях заменить многие другие инструменты (в случае того же докера — у меня вот не было ни одной реальной потребности его применять, опять же потому что JVM), но все-таки JVM и ОС не равны друг другу в сегодняшней реальной жизни. Похожи — но не равны.
Кстати, я тоже не помню что-то в обычном Кубере средств нестандартного распределения контейнеров. По-моему, там как и в кластере ява-сервера, только равномерное распределение нагрузки, ничего хитрого.
Насчёт Андроид, да, там ява больше для гуи оболочки использовалась. Примерно как иксы или винда 3 версии. В принципе, с некоторой натяжкой можно и её считать отдельной ОС.
Вообще я перечислил признаки ОС в Ява-машине.
Можно ещё уточнить, что Линукс — не ОС, это ядро ОС. А ОС чаще всего гну. Андроид не гну ос. И обратно, гну ос может работать на ядре Хёрд.
Не надо путать ОС и платформу.
Можно ещё уточнить, что Линукс — не ОС, это ядро ОС.
Как раз Линукс — это ОС, состоящее из ядра и приложений.
А ОС чаще всего гну.
ОС в первую очередь — ядро (и его стандарты, например POSIX), а затем уже остальные вещи, которые теоретически можно заменить, и Линукс не перестанет быть Линуксом, он перестанет быть GNU линуксом.
Андроид не гну ос
Потому что это ОС на базе Линукс-ядра.
И обратно, гну ос может работать на ядре Хёрд.
Это будет GNU Хёрд ОС
Я как раз и говорю про "функции, на которых строился GUI софта". Это и называется графической оболочкой, часто одной из главных частей ОС.
Графическая подсистема и стандарт для gui приложений может быть и не связан с GUI оболочкой. Например, в Windows есть GUI проводник, но он не является графической подсистемой, на базе которой другие приложения что-то строят.
Оболочка (shell) это интерфейс для пользователя, а не для программ.
Вы путаете теплое с мягким.
Прежде чем утверждать, что я путаю ОС с чем-то, определитесь с тем, что такое ОС. По мнению Википедии, например, графическая оболочка входит в ОС как важный третий компонент. А в Гну/Линукс ОС можно включать оболочку Гном.
Далее. В win 3.x оболочка и апи были практически неотделимы. Поскольку апи – это библиотеки, оболочка в их случае была всего лишь диспетчер задач на основе этих апи, как и проводник впоследствии. Поэтому в случае вин, имеются в виду именно библиотеки примитивов, аналогично гному или кутэ. В винНт, насколько я знаю, такой подсистемой является гди вкупе с директИкс.
Я не вижу смысла называть приложения типа проводника оболочками в статье, посвященной системным вещам. Оболочка здесь в архитектурном смысле.
Что касается Андроид: здесь именно далвик выполняет функции графической подсистемы, плюс обёртка над нативными апи Андроид.
Апи это АпиAPI это вообще абстрактное понятие, набор соглашений, контракт. А вот его реализация уже может быть в чём-то конкретном. В библиотеке, в адресах вызова в ядре, в номерах прерываний, rest или qraphql эндпойнтах.
Поэтому API не может быть с чем-то монолитом, оно может в чём-то реализоваться.
Например, в Вин 3.1, если библиотека реализует АПИ ГДИ32, то через этот АПИ, большинство приложений, подключая эту библиотеку, рисуют ГУЙ. Где тогда оболочка? Ответ: оболочка в библиотеке и доступна через АПИ этой библиотеки. И эта библиотека была частью ОС Вин со времён динозавров.
Оболочка — это программа для взаимодействия Пользователя и Операционной системы.
Не для взаимодействия программы и программы, или программы или системы. Это именно то, где пользователь может что-то набрать, написать, кликнуть и увидеть или запустить программу/скопировать файл и так далее.
Со времен динозавров оболочка и API для отрисовки чего-либо (графические API, прерывания, телетайпы) эти термины не менялись.
Ну, в случае скажем хадупа — вполне перемещает. И балансировка там есть, и планировщик тоже.
Ну только это не JVM, разумеется, а большое такое приложение, пусть и написанное на Java. Ну т.е. это я к чему — что написать ОС на базе JVM в принципе было бы можно. Но на сегодня никто не будет.
Поскольку Ява почти ОС, то Ява и есть нода. Если вылетит, то целиком. Но она не вылетит. И нода большая, иначе смысла запускать Яву вообще нет. Т.е. одна Явная нода. И вылет по явовскому ООМ случится тогда, когда кончатся ресурсы, и это безопаснее, чем пресловутая молчаливая смерть от нативного ООМ.
Как я уже описал, в специализированных серверах есть балансировка, это значит, что да, нагрузка перемещается по кластеру, на то он и кластер.
Если под л вы подразумеваете левел сети, то ejb/RMI – прикладной уровень. Да, я не спорю, что может быть уровень тисипи эффективнее. Но это нивелируется работой с джсоном по хттп между сервисами в большинстве случаев.
И кстати, я не делал вывод, что Ява может заменить Кубер. Я лишь оцениваю недавнюю историю развития Явы и как платформа профукала свой рынок. И показываю как должна работать Ява. Что т.н. кровавый ынтырпрайз по мнению некоторых был неудачным тяжеловесным решением и надо срочно сделать монолитный Спринг.
История показала, кто был прав и какие технологии продуманны и обкатаны, а какие сделаны на коленке. И показываю, что еджби в ентерпрайз-кластерах, по сути то же, что докеры в кубере. А заголовок — это для привлечения внимания.
А вот по теме статьи как раз, лучше сравнить Erlang(Elixir) на OTP — вот уж точно замена докеру с кубером, мало того что там управление ресурсами есть между потоками и взаимодействие при помощи сообщений, так еще можно прозрачно процессы между нодами перекидывать + встроенный supervisord. Отлажено уже всё это 10-ти летиями. ;)
Ну до ОС, как уже правильно написали выше, JVM конечно не дотягивает и не пытается. ОС это все-таки про работу с железом, с сетью, про лимиты по ресурсам, файловые системы и все прочее. Кубернетис он про то как управлять несколькими серверами, чего JVM не делает.
У JVM собственный мир, во много устаревший. И все эти OSGI, уже упомянутый web.xml и прочие spring-и, излишне сильно раздутое и переусложненная модель которая делает простые вещи. Никогда не понимал зачем нужны всякие web.xml и прочие spring.xml если можно тот же маппинг url-ов написать прям на Java. Библиотечный подход он все-таки попроще и попонятнее, ненадо ещё разбираться с вымышленным языком всех этих xml-ей.
Времена статичных сайтов и shared хотингов прошли, и все как-то более переместилось в сторону виртуализации, контейнеров и вот этого всего. Потому что внезапно оказалось что интернет совсем не дружелюбная среда, какой она была на заре становления. Нужно ограничивать ресурсы, процессор, память, место на диске, сетевое взаимодействие. А разделяемые сервера этого не умеют.
Как же не умеют. Есть джеластик Ява как раз про это всё.
JVM не умеет, зато доменный контроллер, запущенный на ней, вполне умеет (в современной терминологии контрол-плэйн).
XML нужен не тогда, когда у вас 1 экземпляр, а когда надо 15 настроенных релизов выкатить на 20 клиентов с очень разным но тем не менее схожим составом блинов в логике и разным расположением ендпойнтов на корп. портале.
JVM не умеет, зато доменный контроллер, запущенный на ней, вполне умеет (в современной терминологии контрол-плэйн).
И что прямо приоритеты потоков, пропускную способность сети, количество выделяемой памяти, количество открытых сокетов может ограничить? Незнаю что такое доменный контроллер, но что-то сомневаюсь.
а когда надо 15 настроенных релизов выкатить на 20 клиентов с очень разным но тем не менее схожим составом блинов в логике и разным расположением ендпойнтов на корп. портале.
Когда 20 клиентов на корп. портале — это не настоящие 20 клиентов, это просто 20 приложений в конторе, их более менее можно контролировать административно.
А вот времена 20 настоящих незнакомых клиентов на одном аппликейшн сервере прошли, сейчас каждый из 20 клиентов либо на своей отдельной виртуалке, либо вообще платит за вызовы API и колиество загруженных мегабайт в БД.
Имелись в виду 20 сторонних клиентов с 20-ю порталами.
Доменный контроллер глассФиша умеет управлять серверами. И Флай тоже.
Правда управлять в смысле определять лимиты, кол-во копий бинов и т.п. Это оценка ресурсов в штуках, а не в мб, как в Амазон ЕЦС.
А вот jelastic cloud как раз метрики собирает и как-то хитро калибрует память.
А вот jelastic cloud как раз метрики собирает и как-то хитро калибрует память.
Так jelastic-то как раз работает на контейнерах, просто один из вариантов контейнера это JVM + Tomcat. Jelastic это как раз антипример, это пример жуткой неэффективности и того как делать ненадо. Tomcat эффективен когда запускает 20 приложений в одном Tomcat-е и в одной JVM. А когда 20 приложений запускаются в 20 контейнерах, в каждом из которых своя JVM и свой Tomcat — это ужас, это насколько лишний разход ресурсов. Тут как раз лучше запускать встроенный в приложение сервер на Java (javalin или прости господи spring boot), и лучше даже со встроенной JVM, скомпилировать в native-image от GraalVM, например.
На контейнерах они стали работать, чтобы следовать моде. Изначально у них был чисто явовый паас.
Я бы только добавил, что в этом же смысле и докер тоже не ОС, потому что полную изоляцию и безопасность тоже не обеспечивает. Ей и полноценные-то ОС не всегда могут обеспечить.
Вот насчёт защиты JVM вы зря. Апплеты вполне себе независимо работали. И обычный инстанс если запустить с секурити, вы мало что сможете вне контекста сделать. Например рефлексируя в OSGI, получите по рукам.
И сервера приложений слабо, но защищены даже по умолчанию. Рми сильно ограничен. И можно ужесточить защиту.
Зря не зря, а мой скромный опыт работы с JVM мне такое подсказывает.
Вы все верно говорите, только вы не про ту защиту. Покажете мне, где лимит на число создаваемых threads, на потребление памяти и процессора? Это все может и есть — но не на уровне JVM. Поэтому один из компонентов, будь то EJB, WAR, или там бандл — вполне может выжрать все ресурсы вообще, доступные JVM в целом, и не оставить остальным ничего. На защищенную систему для деплоя приложений, которые друг другу не доверяют, это вовсе не похоже.
Попробуйте в EJB сделать бесконечный цикл — потом расскажите мне, как повел себя контейнер, хорошо ли отреагировал.
Ограничение на потоки делается имеющимися средствами в пару строк кода: https://stackoverflow.com/a/31039987
В принципе, управление ресурсами можно реализовать при желании. Всеми, кроме памяти. Что и делает тот же желастик. Для меня всегда было загадкой только как они управляют объемом памяти. Это единственная вещь, которую я считал если не невозможной, то очень трудной.
В ответ на ваш пример: сделать административный Бин или коннектор для сервера, который прибьет зависший поток — плёвое дело. Часто это делают через JMX.
А поскольку вы не знаете ответа, то я продолжаю думать, что ответ отрицательный.
Я рекомендую вам внимательнее читать и код, и документацию, прежде чем писать комментарии.
Более того, там явно написано в конце:
We get an exception in our Test class when we try to create the new thread:
И это не то, о чем я спрашивал. Так что эта, сначала сами поучитесь читать, что у вас спрашивали, прежде чем отвечать.
Я полагал, что опытному программисту со стажем не составит труда представить, какие минимальные изменения нужно сделать, чтобы получить желаемый результат.
Готовое решение — это продукт, а я пока не решился на написание кода, только идеи есть.
Так что минимальными изменениями вы скорее всего не отделаетесь. В этом собственно и разница между готовым решением (которого не просто нет из коробки, а нет по факту ни в одном известном мне контейнере), и поделкой на коленке, которая в лучшем случае позволяет в рамках JavaEE просто запретить потоки (и там это логично, ибо есть managed пулы, которыми и следует пользоваться). Но в общем случае — нет.
При проверке от лица системы всегда можно подняться вверх по стеку и проверить, кто вызвал привилегированную операцию. В стандартном Privileged Action по-моему так и делается. И хорошо, что Ява управляемая – позволяет сделать это без риска все закрэшить. Т.е. если есть некий определенный соглашениями контекст, то проверить его свойства вполне можно, в т.ч. число оставшихся потоков и даже потреблённую память (но это уже задание со звёздочкой)
Да почему же на одном то. У вас 20 сборок, которые деплоят в 20 разных конторах в 20 местах планеты на 20 разных языках вот такой кейс.
Вот честно, когда такое пишут про OSGI, у меня всегда создается впечатление, что люди вообще никогда с этим реально не работали. У OSGI снаружи простая модель, которая делает простые вещи. Ну т.е. элементарно — бандл это просто jar, который умеет экспортировать наружу избранные packages (а не все подряд классы), и импортировать чужие, у которого есть простейший жизненный цикл (что есть вообще у всех систем, состоящих из компонентов), и еще он может экспортировать наружу произвольные методы, которые может найти и вызвать кто угодно извне. Все. Все остальное (его немало) — это лишь бантики, не более.
Вы слышали когда-нибудь о вирусах на Яве?
Лет 15 назад каждый второй вирус распространялся через JVM Browser Plugin, хотя аплеты вроде как работают в изолированной песочнице. Из-за чего юзеры начали массовый выпил джавы со своих компов.
Итак Ява-машина — это ОС. Даже круче чем ОС местами.
Нет, это именно виртуальная машина, не более. А вот была попытка написания настоящей ОС на 100% джаве: https://www.jnode.org/
Потому что, как я уже сказал, она позволяет создавать множество независимых изолированных контекстов
Она не может создавать изолированные контексты памяти (разные кучи) внутри одной JVM. Поэтому любой тред легко может навернуть всю JVM с OutOfMemory. Плюс все контроли за ресурсами устанавливаются на уровне процесса, а не контекста, поэтому никто не запретит треду открыть миллион файлов или создать еще миллион тредов.
Можно подумать, что яваскрипт в браузере безопаснее. Выпил из браузера происходил, потому что Гугл объявил войну Ораклу и Яве в целом.
ОС на Яве есть несколько.
Контроль над контекстом памяти я подразумевал в смысле непосредственного доступа. А контроль над ресурсами это вполне реализуемая вещь зачастую средствами самой машины, о чём я писал в статье и в комментариях диалога с sshikov обсуждал.
Опять же, если не применять лимиты на ресурсы на уровне процессов, то и нативный процесс закрэшит систему. Причём в отличие от Явы, последствия будут серьёзнее: например один процесс может выжрать всю память ОС и тогда Линукс либо тупо застынет, либо будут прибиты случайные процессы. Так что даже здесь сравнение не в пользу натива.
Мне кажется, чем что-то доказывать уговорами, проще сделать и показать.
Тем не менее: на уровне памяти изоляция есть хотя бы потому, что ни у кого в принципе нет доступа к памяти.
Почему JVM —это ОС и больше чем Кубер