Мне было интересно, есть ли "плавный путь" перераспределения Java WAR на производственный сервер (без кластера, без OSGi)?
Все, что я могу придумать, это остановить сервер, файл обновления, перезапустить сервер. И за 10 минут до этого мне нужно отобразить предупреждение о техническом обслуживании на сайте.
Какой ваш подход?
Во-первых, hot-deploy не всегда работает. Мы потратили столько времени, чтобы убедиться, что каждый новый модуль загружен и решил, что это не стоит проблем. Поэтому то, что вы делаете, может показаться плохим, но это самый надежный способ развертывания новой WAR.
Наш текущий подход заключается в использовании коммутатора с балансировщиком нагрузки перед всеми серверами. Мы запускаем как минимум 2 экземпляра серверов приложений. Когда мы завершаем работу одного сервера для обслуживания, трафик автоматически переходит к другому.
Некоторые из переключателей действительно недороги. Если у вас недостаточно нагрузки, чтобы оправдать новое поле, и ваши 2 экземпляра могут работать в одном окне.
В некоторых случаях коммутаторы могут фактически сэкономить деньги. Например, у нас есть страница SSL, которая использовала 6 ящиков, и теперь она отлично работает на двух ящиках с ускорением SSL в коммутаторе.
Вы можете взглянуть на JRebel, хотя я бы не использовал его в процессе производства. В производстве мы делаем в основном то же самое, хотя наш босс продолжает мечтать о горячей передислокации. К сожалению, они поддерживаются в основном на бумаге - в самых сложных приложениях что-то всегда идет не так с горячим перераспределением. То же самое еще более верно для инкрементных горячих перераспределений...
Некоторые серверы приложений поддерживают перераспределение без прерывания обслуживания. Это, по крайней мере, верно для WebLogic, см. Использование перепрофилирования для обновления приложений. Обратите внимание, что это не горячее развертывание (и я бы никогда не использовал горячее развертывание с рабочими серверами).
Без поддержки сервера приложений, боюсь, вы не сможете выполнять реальные "плавные" перераспределения. Если вы хотите минимизировать время простоя, один подход заключается в параллельном развертывании нового приложения (на том же сервере или другом) и изменении правил маршрутизации по завершении. Но клиенты потеряют свою сессию.
Обычно возможно оптимизировать время запуска. Наше веб-приложение начинается с Jetty через 5-7 секунд. Другие веб-серверы Java хуже, потому что они начинаются очень медленно.
Кроме того, поскольку я знаю (не я сделал это), интерфейсный веб-сервер (такой как apache, мы используем lighttpd) может быть настроен на то, чтобы удерживать запрос в течение некоторого периода времени (до 30 секунд на нашем) в то время как Jetty не готов. Таким образом, мы просто перезагружаем Jetty при развертывании, а пользователи просто задерживают несколько секунд в худшем случае, что обычно выглядит как глюк интернет-соединения.
Обычно, mv old.war new.war и пусть AS берет его оттуда, хотя с очень занятыми услугами 24/7, я полагаю, что это не вариант.
Поскольку ZZ Coder уже упомянул балансировку нагрузки, это хорошее решение, особенно для крупных развертываний. Для моего собственного проекта я использую функцию back-back-proxy для веб-сервера nginx. Он перенаправляет все http-пакеты из определенного веб-контекста (видимого из Интернета) на сервер внутри моей сети. Конфигурация очень проста:
location /best-app-ever/ {
proxy_pass host-address:8080/some-app-1.1
root /home/www/some-app-1.1
}
Переключающая версия также должна быть гладкой. Предполагая, что вы уже развернули новую версию приложения, просто измените конфигурационный файл nginx и примените изменения:
location /best-app-ever/ {
proxy_pass host-address:8080/some-app-1.2
root /home/www/some-app-1.2
}
sudo nginx -t sudo service nginx restart
Следует предупредить, что в случае, если ваше веб-приложение является работоспособным и/или содержит некоторые запущенные или запланированные процессы, развертывание и развертывание могут быть не такими гладкими.