изящное обновление веб-сайта

Question

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

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

Answer 1

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

Вы предоставили мало подробностей и задаете расплывчатый, но важный вопрос случайным людям в Интернете.Это наводит меня на мысль, что "корректное обновление" было сделано в последнюю минуту (как и 23 минуты назад).

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

Answer 2

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

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

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

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

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

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

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

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

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

Answer 3

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

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

Answer 4

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

Грубая процедура состояла бы в том, чтобы:

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

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

Answer 5

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

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

Answer 6

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

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

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

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

Answer 7

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

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