изящно модернизировать сайт

Question

Есть ли предпочтительный метод изящного обновления веб-сайта? У меня есть совершенно новая кодовая база, готовая для перехода на сайт, но ее обновление займет несколько часов. Я не хочу, чтобы сайт не работал все время с обновлением, скоро вернитесь! сообщение, но я также не могу покинуть текущий сайт, пока новый находится на месте.

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

Answer 1

Планирование «изящного обновления вашего сайта» не начинается, когда вы готовы к развертыванию. Это начинается очень рано в дизайне вашего приложения. Это означает, что вам нужно создать приложение, которое можно корректно обновить , а также иметь инфраструктуру для поддержки этого обновления. Вы предоставили немного деталей и задали неопределенный, но важный вопрос случайным людям в Интернете. Это заставляет меня поверить, что «изящное обновление» было проблемой в последнюю минуту (как 23 минуты назад).

Ваш вопрос: "Есть ли предпочтительный метод изящного обновления веб-сайта?" можно ответить только так: «Да, но я делаю это иначе, чем вы».

Answer 2

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

Только не забудьте сделать резервную копию!

Answer 3

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

Возможно, в зависимости от того, как вы выполняете миграцию, это можно сделать с абсолютно нулевым временем простоя.

Чем сложнее ваше приложение / сайт, тем сложнее может быть стратегия миграции, если вы не хотите простоев.

Мы достигли нулевого времени простоя с помощью:

1. Настройка новых серверов с новой версией сайта и базы данных.
   • Изменение балансировки нагрузки для разделения трафика на два пула new-app и old-app.
   • Настройка балансировщиков нагрузки начинает отправку трафика на серверы новых приложений, но сохраняет существующие сеансы на серверах старых приложений
   • Новые сеансы в новом приложении проверяют, были ли перенесены данные клиента, а если нет - быстро это делает.
   • Постепенное отключение серверов «старого приложения» при снижении нагрузки, обновление до нового приложения и добавление в пул балансировки нагрузки нового приложения.
   • По окончании сеансов данные о клиентах переносятся в новую базу данных.
   • Если позволяет загрузка, перенесите неактивные данные о клиентах в новую базу данных.

Конечно, это более сложно - поскольку нам нужно было поддерживать доступ к данным клиентов в двух средах и постепенно переходить.

Это позволяет нам откатить изменения, если будут замечены некоторые проблемы - например, чрезмерное использование ЦП или памяти на одном из серверов новых приложений.

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

Если вы не можете запустить старое приложение и новое приложение из одного и того же хранилища данных (серверные веб-службы, база данных и т. Д.) - тогда ваши приложения должны будут знать, что им потребуется синхронизировать данные между старыми / new - например, при сохранении / обновлении данных о клиентах запись должна происходить в обоих местах.

Answer 4

Это, вероятно, то, что вам нужно, чтобы уже "спроектировать" текущую версию.

Может ли он быть сегментирован так, чтобы некоторые части (например, каталог) были доступны, а другие (например, покупка) были обновлены?

Можно ли создать версию только для чтения с использованием кэша?

Или, конечно, есть времена дня, когда перерыв в обслуживании допустим? Работать в воскресенье вечером? Даже на довольно крупных веб-сайтах есть некоторые окна обслуживания, во время которых части функциональности недоступны.

Answer 5

Звучит так, будто ты хочешь съесть свой торт и съесть его.

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

Answer 6

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

Грубая процедура будет:

1. Арендуйте новый сервер с другим IP-адресом, где вы будете размещать новый сайт. Или, если возможно, создайте на своем сайте тестовый поддомен, недоступный для широкой публики.
2. Разверните свой сайт на новом сервере / поддомене. Сначала выполните все необходимое тестирование на новом сайте, используя IP-адрес или субдомен.
3. Если вы уверены, что все в порядке, сначала выполните перенаправление на новый сервер / поддомен.
4. Перенаправьте DNS на новый IP-адрес или исправьте его таким образом, чтобы ваш основной домен теперь мог указывать на исходное местоположение субдомена.

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

Answer 7

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

Вы также можете арендовать очень дешевый сервер, например, за 20 евро / месяц (кимсуфи или что-то в этом роде), и выполнить обновление.