Плавное перераспределение WAR в производство?

Question

Мне было интересно, существует ли «плавный способ» повторного развертывания Java WAR на рабочий сервер (без кластера или OSGi)?

Все, что я могу придумать, это остановить сервер, обновить файл, перезапустить сервер. И за 10 минут мне нужно вывести на сайт предупреждение об обслуживании.

Какой у тебя подход?

Answer 1

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

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

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

В некоторых случаях коммутаторы могут реально сэкономить деньги. Например, у нас есть страница SSL, которая раньше использовала 6 блоков, и теперь она отлично работает на 2 боксах с ускорением SSL в коммутаторе.

Answer 2

Обычно можно оптимизировать время запуска. Наше веб-приложение запускается с Jetty через 5-7 секунд. Другие веб-серверы Java хуже, потому что они запускаются очень медленно.

Кроме того, насколько мне известно (не я это сделал), интерфейсный веб-сервер (например, apache, мы используем lighttpd) можно настроить для удержания запроса некоторое время (до 30 секунд у нас) пока причал не готов. Таким образом, мы просто легко перезапускаем Jetty при развертывании, и в худшем случае пользователи просто задерживаются на несколько секунд, что обычно выглядит как сбой подключения к Интернету.

Answer 3

Некоторые серверы приложений поддерживают повторное развертывание без прерывания обслуживания. По крайней мере, это верно для WebLogic, см. Использование повторного развертывания производства для обновления приложений . Обратите внимание, что это не горячее развертывание (и я бы НИКОГДА не использовал горячее развертывание с производственными серверами).

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

Answer 4

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

Answer 5

Как уже упоминал ZZ Coder, балансировщик нагрузки является хорошим решением, особенно для больших развертываний. Для моего собственного проекта я использую функцию обратного http прокси веб-сервера 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

Имейте в виду, что если ваше веб-приложение с состоянием и / или содержит некоторые запущенные или запланированные процессы, развертывание и отмена развертывания могут быть не такими плавными.

Answer 6

Обычно mv old.war new.war, и пусть AS берет его оттуда, хотя с очень занятыми 24/7 сервисами, я думаю, это не вариант.