404 выпуск со статическими активами, CDN и многосерверной средой

Question

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

Предпосылки:

• Мы используем балансировки нагрузки перед двумя интерфейсными серверами.
• Мы используем CDN для доставки статических активов, таких как CSS/JS/images.
• Мы отпечатываем наши файлы JS/CSS с помощью контрольной суммы, используя SquishIt для обеспечения кэширования
• Мы добавляем путь к ресурсу с пулом CDN при запуске приложения. Это также функция SquishIt (.WithOutputBaseHref). Пример: /ui/main_465987ecb75.css будет оказана как рутина развертывания //cdn.host.com/ui/main_465987ecb75.css

:

1. Примите сервер1 от балансировки нагрузки.
2. Внесите развертывание на сервер1.
3. Разогрейте его.
4. Включите сервер 1 в балансировщик нагрузки.
5. Примите server2 от балансировки нагрузки (... и повторите шаги 2-4)

А вот где он не:

между шагом 4 и 5 выше, мы оба сервера в Интернете для короткий период времени. В течение этого времени сервер 1 мог ссылаться на main_46eb48ac968.css, а server2 мог ссылаться на main_987eba4687.css. Это вызовет проблемы в следующем сценарии ...

использования:

1. Пользователь посещает сайт и в конечном итоге на вновь развернут сервер 1.
2. браузер запросит main_46eb48ac968.css от CDN.
3. CDN запрашивает этот файл из loadbalancer, так как он не находится в кеше.
4. Балансировщик нагрузки отправляет запрос CDN на сервер2.
5. Server2 returs 404 страница не найдена ошибка, так как новый файл находится только на сервере 1.
6. Сайт выглядит как дерьмо!

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

Идеи?

Answer 1

Хм, так ваш CDN использует ваш сайт в качестве источника, который я принимаю?

Возможно, вы захотите ознакомиться с this issue.Это делает запись хеша в виде папки в сгенерированном пути. Затем вы можете использовать правила перезаписи IIS для удаления этой папки из URL-адреса на пути. Это было сделано, чтобы предоставить опцию, обеспечивающую надежную защиту кеша опции «хэш в имени файла» без взрыва файлов. Вы можете использовать это, чтобы получить что-то, но в этом случае он оставил бы вам старую версию файла в кеше CDN (так что вам нужно будет аннулировать все после завершения развертывания).

Это будет доступна в следующей версии (0.9.3)

Answer 2

Ответ на @AlexCuse

Да, наш CDN использует сайт как происхождение.

На самом деле я предлагал решение hash-as-virtual-folder :). Мы использовали это решение, пока не были развернуты в среде с несколькими фронт-серверами, где мы обнаружили эту проблему. Это отличный способ распаковки кеша файлов в средах, где у вас нет CDN и нескольких интерфейсных серверов. К сожалению, у нас есть оба.

Если мы используем решение хэш-как-виртуальной папки, старый файл будет обслуживаться с новым URL-адресом в 50% случаев, когда короткое время, когда оба сервера находятся в сети, один сервер со старым кодом и один с новым кодом. Мы действительно смогли бы сбросить CDN после развертывания, но это не поможет клиентам, которые уже загрузили неправильный файл, так как он имеет максимальный возраст 365 дней и не будет обновлен до тех пор, пока клиент не нажмет ctrl + F5. И мы не можем это контролировать. Дерьмо. ;)

Таким образом, наше решение до сих пор является то, что лучше для пользователя, чтобы получить дерьмовый сайт без CSS/JS в течение как одну минуты (если он является первым посетителем и попадают в «неправильный» сервере), чем кеширование неправильного файла, который не будет обновляться до следующего развертывания.

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

В любом случае, это отличная библиотека!