Нулевое время простоя для приложений Java

Question

Я пытаюсь создать очень легкое решение для развертывания приложений Java с нулевым временем простоя. Для простоты давайте подумаем, что у нас есть два сервера. Мое решение заключается в использовании:

1. На "фронте" - некоторый балансировщик нагрузки (программное обеспечение) - я думаю о HAProxy здесь.

2. На «спине» - два сервера, на обоих запущен Tomcat с развернутым приложением.

Когда мы собираемся развернуть новую версию

1. Мы отключаем один из серверов с помощью HAProxy, поэтому будет доступен только один сервер (назовем его сервером A, на котором запущена старая версия).

2. Разверните новый выпуск на другом сервере (назовем его сервером B), запустите производственные модульные тесты (если они у нас есть :-) и включите сервер B с HAProxy, одновременно отключив сервер A.

3. Теперь у нас снова только один активный сервер (сервер B с новым выпуском). Разверните новый выпуск на сервере B и включите его снова.

Кто-нибудь посоветует, как улучшить? Как автоматизировать?

Какие-нибудь готовые решения или я должен закончить со своими собственными сценариями?

Спасибо!

Answer 1

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

1. Переключатель A / B: ( Повторное обновление + резервный механизм )

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

минусов: если вам нужно X серверов для запуска приложения, вам понадобится 2X серверов с таким подходом.

2. Ноль времени простоя

При таком подходе мы не храним набор машин; скорее мы задерживаем привязку порта. Получение общего ресурса задерживается до запуска приложения. Порты переключаются после запуска приложения, и старая версия также продолжает работать (без точки доступа) для мгновенного отката в случае необходимости.

3. Параллельное развертывание - Apache Tomcat: (только для веб-приложений)

Apache Tomcat добавил функцию параллельного развертывания в свою версию 7. Они позволяют одновременно запускать две версии приложения и использовать последнюю версию по умолчанию.

4. Задержка привязки порта:

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

5. Расширенная привязка порта:

Разрушив миф: ‘Address already in use’, * старый процесс и новый процесс будут привязаны к одному и тому же порту. Опция SO_REUSEPORT в режиме ON позволяет двум (или более) процессам связываться с одним и тем же портом. Как только новый процесс свяжется с портом, убейте старый процесс.

Опция SO_REUSEPORT решает две проблемы:

1. Небольшой сбой между переключением версии приложения: узел может постоянно обслуживать трафик, что фактически дает нам нулевое время простоя.

2. Улучшено планирование:

В итоге:

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

Answer 2

Скользящее обновление - действительно хорошее решение, если ваш балансировщик нагрузки поддерживает эту опцию (нехватка сервера).Другим решением является использование серверов приложений с поддержкой OSGi для горячей замены частей или всего вашего приложения.

Я бы порекомендовал первый.Консоль контроля SpringSource AMS может отключить кластер tcServer (пользовательский томат на стероидах), а IIRC автоматически обновляет систему (но проверяет документы).

Answer 3

LiveRebel предоставляет функциональные возможности для повторных перезапусков, предоставляет CLI API и плагин Hudson / Jenkins для автоматизации.

Answer 4

Посмотрите на технологию OSGi, если вы можете разместить контейнер OSGi, поскольку он обеспечивает хорошую изоляцию и горячее развертывание для пакетов OSGi. Если вы используете Spring Framework, вы можете использовать Spring OSGi

Answer 5

Существует easy-deploy , который точно так же работает с контейнерами Docker.

Развертывание версии 1

easy-deploy -p 80:80 -v some/path:other/path my-image:1

Для развертывания новой версии просто запустите командуобновленное имя тега

easy-deploy -p 80:80 -v some/path:other/path my-image:2

Раскрытие: я построил этот инструмент.Я построил его именно потому, что не смог найти простого решения этой проблемы.