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

Ответ 1

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

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

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

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

Ответ 2

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

Ответ 3

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

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

Ответ 4

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

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

Ответ 5

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

Ответ 6

Поскольку 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

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