Скажем, у меня есть два производственных веб-сервера (web1 и web2) и статический сервер происхождения актива (origin1), и я хочу развернуть новый код, который ссылается на новые css / js / images.
После обновления web1 и возвращаю его на вращение, и прямо перед тем, как я возьму web2 вне ротации, будет короткое окно, когда балансировщик нагрузки отправит запросы обоим web1 с новым кодом и web2 со старым кодом:
web1 обслуживает html, который запрашивает http://somecdn/images/foo.jpg?v=newhashweb2 обслуживает html, который запрашивает http://somecdn/images/foo.jpg?v=oldhashИтак, в этом коротком окне есть шанс, что somecdn может запросить foo.jpg?v=oldhash, но фактически получает новый образ, который только что был развернут в origin1. Это не хорошо.
Очевидным решением, кажется, является сохранение обеих версий активов:
/2.1/images/foo.jpg и /2.2/images/foo.jpg, что противоречит цели очистки кеша с помощью хэша файла, или/images/foo.oldhash.jpg и /images/foo.newhash.jpg в файловой системе, что оставит кучу старых файлов, которые нужно удалить.Есть ли лучшая стратегия, предполагающая, что я не могу полностью отключить сайт во время развертывания?
(StackExchange использует этот подход хеширования файлов для очистки кеша…)
По сути, вы должны оставить обе версии доступными во время перехода, если вы вообще собираетесь перекрывать версии в производстве. Использование версий в компоненте пути - это то, что мы делаем, поскольку это намного проще для разработчиков. Подход №2 требует гораздо большего количества скриптов в процессе сборки / развертывания - еще одна вещь, которую нужно сломать. Мы используем жесткие ссылки в базовых файловых системах, чтобы одни и те же файлы из / V1 / и / V2 / не занимали слишком много места, а также это очень упрощает сокращение. Наши источники могут справиться с увеличением количества обращений во время переключения (что в любом случае происходит в периоды низкой загрузки).