Скорость отклика важна для всех интерактивных приложений, где установленные десктопными приложениями тридцать лет назад стандарты — отклик менее 300 мс — уже давно являются привычными, а значит необходимыми для того, чтобы пользователь от вас не свалил.
Откуда вы вообще взяли это смелое утверждение. В микросервисной архитектуре всё как раз наоборот – с ростом количества отдельных компонент экспоненциально растёт сложность целой системы, и такими же темпами растёт вероятность отказов и сбоев. Особенно это касается межпроцессного и тем более сетевого взаимодействия, где ошибки соединения это вообще в порядке вещей. Именно поэтому сейчас часто на всяких сайтах можно наблюдать 500-е ошибки, вызванные разрывом связи между фронтовым нджинксом и бэком. Раньше таких ситуаций почти не было, я не помню ни одной.
Либо прогресс за 3 года скакнул выше головы, либо мы имеем в виду разные вещи. Если 3 года назад требовалось 40 админов, чтобы поднять приличное приватное облако на кубере. Откуда вы взяли 1 человеко-день. Что в итоге сможет его облако? Да его на подготовку металло-базы не хватит в размере больше 10 нод. Я же не про миникуб говорю, а настоящую систему.
Про кофиги это вообще отдельная история. Помнится, когда делали проект на Спринге, его настройки паковались под каждый профиль отдельно. Причём для продакшена и препрода эти настройки были пустые по понятным причинам безопасности в банке. Поэтому настройки прописывал админ, который деплоил наше приложение на банковский джбосс. И делал это перепаковкой архивов с приложением, рискуя ошибиться и сломать к черту всё приложение. И он ругался и плевался, поэтому я специально сделал запрос конфигов в Спринге из jndi контекста и боль пропала. Локально при разработке можно было продолжать пользоваться пропертями, но я этого не делал, потому что настроить сервер проще и логичнее.
По поводу сервера на каждого разраба: извините, если разработчик не может даже сервер настроить на основе имеющейся конфы, то что тогда он вообще может.
Отсутствие конфига сервера в проекте — это сугубо ваша личная боль. Если в проекте бардак, то сервер тут ни при чём. Для глассФиша можно конфиг отправлять онлайн прямо при деплое или заблаговременно. Но в целом, что в глассФише, что в джбоссе, что в Веб-сфере конфиг можно просто подложить целиком — самый простой способ.
На самом деле, когда у вас несколько конфигураций, то прописывать их вручную всё равно придётся, в лучшем случае через указание путей в среде окружения. Сервера приложений в этом смысле удобнее ещё и тем, что можно на одном инстансе запустить все сервера на каждый конфиг, и деплоить потом туда, куда требуется. Не нужно останавливать один сервер, чтобы запустить хотя бы один другой — память расходуется экономнее и, если руки прямые, конфликта по портам нет, как обычно бывает со спрингом.
Про коммерческие: если придерживаться стандартов, можно разрабатывать и на бесплатном. Хотя я описанные вами проблемы не встречал ни в джбоссе, ни в Веб-сфере. Есть свои особенности, но они преодолимы. В сфере логи можно настраивать и смотреть из панели управления.
Апдейты — да, есть неудобства при переходе на новый мажорный релиз, коих всего то было три штуки за 10 лет. Но это меньшая боль, чем мажорный апгрейд Спринга или тем более смена его на нечто другое. Сфера сносно управляется мавен-плагином. А отладка так это вообще свойство JVM, а не сервера, её всегда можно включить и цепляться вручную, даже на удалёнке
Мне кажется, вы путаете модульные и интеграционные тесты. Модульные — на классы и методы. Интеграция — с бинами.
Никакого волшебного плагина к иде я не знаю. Если хочется интеграции, то надо пускать встроенную версию глассФиша или джбосса вручную, т.е. программно (ну или с помощью плагина для junit). При этом можно нормально конфиг в контекст передать, не видел в этом проблем, когда редко это требовалось.
Про урл не понял, это клиентский что ли? Если серверный, то обычно он от контекста зависит, корень которого вполне задаётся. Если у вас параметры для приложения задаются извне, то это не параметры приложения, а параметры среды, и логично тогда параметры среды задавать в среде, т.е. на сервере.
Я не видел нормальных альтернатив JTA. Кроме того, как я говорил, сама концепция — ты приносишь логику, инфраструктуру готовит заказчик — подходит для многих приложений. Даже для облака. Плюс не надо тратить ресурс в виде встроенных серверов и кучи зависимостей. Приложения лёгкие, они несут только логику самого приложения. Возможность запуска нескольких компонент независимо, но на общей базе экономит память и время запуска.
А коммерческие решения ещё и предоставляют масштабирование, балансировку и отказоустойчивость с меньшим геммороем, чем тот же кубернетос или редшифт, который средние компании вообще не потянут в приватной версии.
Заметил, что на хабре переиначивают лексику. Вообще, ванговать — значить предсказывать, прогнозировать (с иронией), от прорицательницы Ванги. А проект этот из прошлого.
Да, вы правы во многом, проект делался мной одним и никаких наворотов поверх него не делалось, поскольку это по сути была временная утилита, которая разрабатывалась прям на лету. Она сделала своё дело за 2-3 дня разработки и всё. Поэтому:
Функционал всего проекта выходить мог далеко. Но конкретно для этой тулзы нужно было подкорректировать/рапарсить данные в БД.
Да, единственный и неповторимый
Тесты, конечно, были на начальном этапе, модульные, 2-3 штуки.
Поскольку это JEE сервер, конфиг для всех подпроектов я записал один раз на этот сервер — датасорс, после чего он используется всеми причастными веб-приложениями. И не надо его копировать по нескольку раз.
Я использовал Netbeans, потому что в нем как раз лучшая интеграция с сервером. Именно из-за того что проект завязан на тулинг только в плане интегрированной разработки на сервере, разработка происходит моментально, с мгновенным фидбэком. Код компилируется и деплоится, не успеешь ещё кнопку сохранить нажать — каждые несколько секунд. Если сложный случай — сигнатуры методов поменялись — то автоматический редеплой прям на месте, почти незаметно (2-3 секунды). Шаблоны JSF подхватываются как статика. Сам проект да, это нетбинс, т.е. скрипты анта. Но никто не мешает рядом положить хоть мавен, хоть грэдл.
Это был эталонный Glassfish. Скорость работы, деплоя и абсолютная интеграция с ИДЕ не заставляли смотреть на аналоги.
Конкретно для этого одноразового приложения параметризация была не нужна. Хотя её несложно настроить в сервере. И какое это имеет отношение к обсуждаемому? Параметризованный каркас не мешает перезагружать бины с чистой логикой. Логика, конечно по конкретным данным работала из контекста.
Здесь CI/CD попросту не нужен был, интегрироваться не с чем, результат работы — новая версия БД. Хотя потратить время, сделать — вполне возможно было.
мы в свое время (лет 15 назад) использовали RMI. Сейчас это модно делать при помощи Rest API
EJB как раз на RMI в одном из вариантов. Все другие коннекты не прокидывают контексты и транзакцию. Вы подцепитесь по Rest, а управление ошибками и транзакциями потом будете делать вручную, изобретать велосипед. И так в каждом проекте на Спринге.
Я не знаю, в курсе вы или нет, но именно тенденция вырождения в администрирование прослеживается сейчас везде. Всё потому что все программы уже написаны в десятках вариаций. Теперь задача состоит в эффективной их компоновке.
Ха, я бы не сказал, что эти языки — эпилог.
Я буквально недавно использовал сви-пролог для написания поиска словоформ. Перед этим пытался сделать то же на стримах Java с не очень впечатляющими результатами. Да ещё и намучился. Всё-таки работать с большим количеством вариантов и их комбинаций на логическом языке проще.
Кстати после оптимизаций пролог-версия стала работать быстрее императивной. Это во вполне себе современном swi-prolog. А ведь есть ещё новый многообещающий Mercury, который по некоторым утверждениям вообще летать будет.
Что касается именно задач ИИ, то конечно логическое программирование относится к отыгравшему поколению, не оправдав заявленных ожиданий. Но своя ниша у него безусловно есть.
Мне кажется, чем что-то доказывать уговорами, проще сделать и показать.
Тем не менее: на уровне памяти изоляция есть хотя бы потому, что ни у кого в принципе нет доступа к памяти.
API это вообще абстрактное понятие, набор соглашений, контракт. А вот его реализация уже может быть в чём-то конкретном. В библиотеке, в адресах вызова в ядре, в номерах прерываний, rest или qraphql эндпойнтах.
Поэтому API не может быть с чем-то монолитом, оно может в чём-то реализоваться.
Например, в Вин 3.1, если библиотека реализует АПИ ГДИ32, то через этот АПИ, большинство приложений, подключая эту библиотеку, рисуют ГУЙ. Где тогда оболочка? Ответ: оболочка в библиотеке и доступна через АПИ этой библиотеки. И эта библиотека была частью ОС Вин со времён динозавров.
Так ведь речь не об обновлении, а о переходе назад-вперёд. По идее нужно ожидать то же состояние страницы, что было до, включая все динамически построенные элементы. А то привыкли все к тому, что андроид-активити нагружают сеть при каждом восстановлении вью, что совсем не является верхом эргономичности.
Нафига? Чтобы не было вот таких перлов от начинающих разработчиков:
Для запуска одиночного сервиса не нужно долго подымать JavaEE сервер — достаточно упаковать его в тот-же docker
превращаются в лютый Ынтенпрайз от которого стынет кровь в жилах
Любой профессионал хотя бы должен знать о существовании термина "нефункциональные требования к ПО". Но если вдруг не знаете, то вот и вот минимум. Физическое разбиение на микросервисы потому и появилось, что при разработке в Спринге невозможно логический модуль независимо развернуть. Да, девтулс частично и не всегда стабильно решает эту проблему. Его проблема ещё и в том, что нужно по мере разработки сдвигать границу между статической и динамической логикой. И всё равно динамическая часть как правило довольно большая и её перезагрузка тоже требует немалого времени.
Я не отрицаю что у Java EE до 6 версии были серьёзные проблемы со сложностью разработки. Помнится, я сам, когда тоже будучи студентом пытался разобраться, как работают EJB. И меня тоже несколько смутила необходимость понять структуру их вызовов, написания нескольких требуемых интерфейсов и ещё пары -тройки классов к ним. Но если бы у меня была тогда возможность, думаю, что я разобрался бы. Ведь мои однокурсники вполне себе сносно работали с тогдашними энтерпрайз-системами и не жаловались.
Но следующий мой опыт был уже с вышедшей к тому времени JavaEE 6. И удивляясь тому, насколько все упростилось, я за пару недель накидал вполне себе работоспособный проект на стеке JavaEE 6, со всеми его преимуществами.
Теперь проиллюстрирую на реальном примере, не очень большом проекте, в котором без EJB я бы большую часть рабочего времени медитировал.
Было простое веб-приложение, которое доставало из базы сущности, процессило их и сохраняло назад. Сложность в том, что сущности надо было нетривиальным образом в базе найти, а логика зачастую зависела от данных. Т.е. смотришь на то, какие есть данные — пишешь логику их обработки. Так вот, загруженные данные сохранялись в веб-контексте, который на JSF. Логика поначалу была вынесена в локальный то ли е-бин, то ли именной бин. Проект собирался на месте (компиляция при сохранении включена), но JRebel я не использовал, и при изменении чего-то большего, чем тело метода, происходил полный передеплой (тоже автоматом кстати). В моём случае это само по себе не было большой проблемой, т.к. в проекте всего несколько бинов. Но вот веб-контекст при этом сбрасывался и надо было его начинать заново. Обидно было. Скоростная разработка страдала.
И тут на помощь как раз пришли remote версии EJB. Выносим логику в отдельный физический модуль — тип соответсвенно EJB. И собираем и деплоим этот модуль отдельно. Веб-часть с её контекстом остаётся нетронутой (кто бы что не думал по этому поводу). Даже транзакция к базе нормально предсказуемо работала. То есть имеем кэшированный контекст, который вызывает меняющуюся постоянно логику (меняется только внешний EJB-бин). И всё работает! Размер модуля EJB — десятки килобайт, который деплоится за 200 мс, поскольку все веб-либы и прочий хлам вынесены отдельно и прогреты с кэшем.
Вот зачем нужно разделение на модули в физическом смысле.
А по поводу CDI — это во многом повторение EJB 3 версии, без их преимуществ. Попробуйте в CDI организовать транзакцию.
Спринг является монолитным независимо ни от каких слов-вирусов, поскольку разбить его на модули в рантайме нельзя. Проблемы будут уже при попытке запуска второго контекста. И всё потому что Спринг изначально отдал предпочтение простоте, разменяв на нефункциональные возможности ПО.
В целом, как замена пхп он работал, поэтому и снискал популярность в студенческой среде. Но итог эволюции был предсказуем и никакие костыли, пытающиеся превратить Спринг то в наносервисы, то наоборот в интегрированное решение наподобие Java EE, уже не помогут.
Можно подумать, что яваскрипт в браузере безопаснее. Выпил из браузера происходил, потому что Гугл объявил войну Ораклу и Яве в целом.
ОС на Яве есть несколько.
Контроль над контекстом памяти я подразумевал в смысле непосредственного доступа. А контроль над ресурсами это вполне реализуемая вещь зачастую средствами самой машины, о чём я писал в статье и в комментариях диалога с sshikov обсуждал.
Опять же, если не применять лимиты на ресурсы на уровне процессов, то и нативный процесс закрэшит систему. Причём в отличие от Явы, последствия будут серьёзнее: например один процесс может выжрать всю память ОС и тогда Линукс либо тупо застынет, либо будут прибиты случайные процессы. Так что даже здесь сравнение не в пользу натива.
Скорость отклика важна для всех интерактивных приложений, где установленные десктопными приложениями тридцать лет назад стандарты — отклик менее 300 мс — уже давно являются привычными, а значит необходимыми для того, чтобы пользователь от вас не свалил.
Откуда вы вообще взяли это смелое утверждение. В микросервисной архитектуре всё как раз наоборот – с ростом количества отдельных компонент экспоненциально растёт сложность целой системы, и такими же темпами растёт вероятность отказов и сбоев. Особенно это касается межпроцессного и тем более сетевого взаимодействия, где ошибки соединения это вообще в порядке вещей. Именно поэтому сейчас часто на всяких сайтах можно наблюдать 500-е ошибки, вызванные разрывом связи между фронтовым нджинксом и бэком. Раньше таких ситуаций почти не было, я не помню ни одной.
Либо прогресс за 3 года скакнул выше головы, либо мы имеем в виду разные вещи. Если 3 года назад требовалось 40 админов, чтобы поднять приличное приватное облако на кубере. Откуда вы взяли 1 человеко-день. Что в итоге сможет его облако? Да его на подготовку металло-базы не хватит в размере больше 10 нод. Я же не про миникуб говорю, а настоящую систему.
По поводу сервера на каждого разраба: извините, если разработчик не может даже сервер настроить на основе имеющейся конфы, то что тогда он вообще может.
Отсутствие конфига сервера в проекте — это сугубо ваша личная боль. Если в проекте бардак, то сервер тут ни при чём. Для глассФиша можно конфиг отправлять онлайн прямо при деплое или заблаговременно. Но в целом, что в глассФише, что в джбоссе, что в Веб-сфере конфиг можно просто подложить целиком — самый простой способ.
На самом деле, когда у вас несколько конфигураций, то прописывать их вручную всё равно придётся, в лучшем случае через указание путей в среде окружения. Сервера приложений в этом смысле удобнее ещё и тем, что можно на одном инстансе запустить все сервера на каждый конфиг, и деплоить потом туда, куда требуется. Не нужно останавливать один сервер, чтобы запустить хотя бы один другой — память расходуется экономнее и, если руки прямые, конфликта по портам нет, как обычно бывает со спрингом.
Никакого волшебного плагина к иде я не знаю. Если хочется интеграции, то надо пускать встроенную версию глассФиша или джбосса вручную, т.е. программно (ну или с помощью плагина для junit). При этом можно нормально конфиг в контекст передать, не видел в этом проблем, когда редко это требовалось.
А коммерческие решения ещё и предоставляют масштабирование, балансировку и отказоустойчивость с меньшим геммороем, чем тот же кубернетос или редшифт, который средние компании вообще не потянут в приватной версии.
Заметил, что на хабре переиначивают лексику. Вообще, ванговать — значить предсказывать, прогнозировать (с иронией), от прорицательницы Ванги. А проект этот из прошлого.
Да, вы правы во многом, проект делался мной одним и никаких наворотов поверх него не делалось, поскольку это по сути была временная утилита, которая разрабатывалась прям на лету. Она сделала своё дело за 2-3 дня разработки и всё. Поэтому:
EJB как раз на RMI в одном из вариантов. Все другие коннекты не прокидывают контексты и транзакцию. Вы подцепитесь по Rest, а управление ошибками и транзакциями потом будете делать вручную, изобретать велосипед. И так в каждом проекте на Спринге.
Пролога несколько разновидностей.
Mercury, Oz?
Я не знаю, в курсе вы или нет, но именно тенденция вырождения в администрирование прослеживается сейчас везде. Всё потому что все программы уже написаны в десятках вариаций. Теперь задача состоит в эффективной их компоновке.
Ха, я бы не сказал, что эти языки — эпилог.
Я буквально недавно использовал сви-пролог для написания поиска словоформ. Перед этим пытался сделать то же на стримах Java с не очень впечатляющими результатами. Да ещё и намучился. Всё-таки работать с большим количеством вариантов и их комбинаций на логическом языке проще.
Кстати после оптимизаций пролог-версия стала работать быстрее императивной. Это во вполне себе современном swi-prolog. А ведь есть ещё новый многообещающий Mercury, который по некоторым утверждениям вообще летать будет.
Что касается именно задач ИИ, то конечно логическое программирование относится к отыгравшему поколению, не оправдав заявленных ожиданий. Но своя ниша у него безусловно есть.
Речь не идёт об ОС, это пока не актуально. А вот в качестве оркестратора вполне можно попробовать.
Мне кажется, чем что-то доказывать уговорами, проще сделать и показать.
Тем не менее: на уровне памяти изоляция есть хотя бы потому, что ни у кого в принципе нет доступа к памяти.
Поэтому API не может быть с чем-то монолитом, оно может в чём-то реализоваться.
Например, в Вин 3.1, если библиотека реализует АПИ ГДИ32, то через этот АПИ, большинство приложений, подключая эту библиотеку, рисуют ГУЙ. Где тогда оболочка? Ответ: оболочка в библиотеке и доступна через АПИ этой библиотеки. И эта библиотека была частью ОС Вин со времён динозавров.
Любой профессионал хотя бы должен знать о существовании термина "нефункциональные требования к ПО". Но если вдруг не знаете, то вот и вот минимум. Физическое разбиение на микросервисы потому и появилось, что при разработке в Спринге невозможно логический модуль независимо развернуть. Да, девтулс частично и не всегда стабильно решает эту проблему. Его проблема ещё и в том, что нужно по мере разработки сдвигать границу между статической и динамической логикой. И всё равно динамическая часть как правило довольно большая и её перезагрузка тоже требует немалого времени.
Я не отрицаю что у Java EE до 6 версии были серьёзные проблемы со сложностью разработки. Помнится, я сам, когда тоже будучи студентом пытался разобраться, как работают EJB. И меня тоже несколько смутила необходимость понять структуру их вызовов, написания нескольких требуемых интерфейсов и ещё пары -тройки классов к ним. Но если бы у меня была тогда возможность, думаю, что я разобрался бы. Ведь мои однокурсники вполне себе сносно работали с тогдашними энтерпрайз-системами и не жаловались.
Но следующий мой опыт был уже с вышедшей к тому времени JavaEE 6. И удивляясь тому, насколько все упростилось, я за пару недель накидал вполне себе работоспособный проект на стеке JavaEE 6, со всеми его преимуществами.
Теперь проиллюстрирую на реальном примере, не очень большом проекте, в котором без EJB я бы большую часть рабочего времени медитировал.
Было простое веб-приложение, которое доставало из базы сущности, процессило их и сохраняло назад. Сложность в том, что сущности надо было нетривиальным образом в базе найти, а логика зачастую зависела от данных. Т.е. смотришь на то, какие есть данные — пишешь логику их обработки. Так вот, загруженные данные сохранялись в веб-контексте, который на JSF. Логика поначалу была вынесена в локальный то ли е-бин, то ли именной бин. Проект собирался на месте (компиляция при сохранении включена), но JRebel я не использовал, и при изменении чего-то большего, чем тело метода, происходил полный передеплой (тоже автоматом кстати). В моём случае это само по себе не было большой проблемой, т.к. в проекте всего несколько бинов. Но вот веб-контекст при этом сбрасывался и надо было его начинать заново. Обидно было. Скоростная разработка страдала.
И тут на помощь как раз пришли remote версии EJB. Выносим логику в отдельный физический модуль — тип соответсвенно EJB. И собираем и деплоим этот модуль отдельно. Веб-часть с её контекстом остаётся нетронутой (кто бы что не думал по этому поводу). Даже транзакция к базе нормально предсказуемо работала. То есть имеем кэшированный контекст, который вызывает меняющуюся постоянно логику (меняется только внешний EJB-бин). И всё работает! Размер модуля EJB — десятки килобайт, который деплоится за 200 мс, поскольку все веб-либы и прочий хлам вынесены отдельно и прогреты с кэшем.
Вот зачем нужно разделение на модули в физическом смысле.
А по поводу CDI — это во многом повторение EJB 3 версии, без их преимуществ. Попробуйте в CDI организовать транзакцию.
Спринг является монолитным независимо ни от каких слов-вирусов, поскольку разбить его на модули в рантайме нельзя. Проблемы будут уже при попытке запуска второго контекста. И всё потому что Спринг изначально отдал предпочтение простоте, разменяв на нефункциональные возможности ПО.
В целом, как замена пхп он работал, поэтому и снискал популярность в студенческой среде. Но итог эволюции был предсказуем и никакие костыли, пытающиеся превратить Спринг то в наносервисы, то наоборот в интегрированное решение наподобие Java EE, уже не помогут.
Можно подумать, что яваскрипт в браузере безопаснее. Выпил из браузера происходил, потому что Гугл объявил войну Ораклу и Яве в целом.
ОС на Яве есть несколько.
Контроль над контекстом памяти я подразумевал в смысле непосредственного доступа. А контроль над ресурсами это вполне реализуемая вещь зачастую средствами самой машины, о чём я писал в статье и в комментариях диалога с sshikov обсуждал.
Опять же, если не применять лимиты на ресурсы на уровне процессов, то и нативный процесс закрэшит систему. Причём в отличие от Явы, последствия будут серьёзнее: например один процесс может выжрать всю память ОС и тогда Линукс либо тупо застынет, либо будут прибиты случайные процессы. Так что даже здесь сравнение не в пользу натива.
Так это вы про Спринг, который монолит. Java EE не пробовали использовать?