Стратегия развертывания AWS для кэшированной страницы / приложения
У нас есть одностраничное приложение с включенным рендерингом на стороне сервера. Мы разместились на AWS ELB.
Ресурсы приложения (файлы js , css ) имеют хэш в имени файла, чтобы управлять кешированием на стороне клиента / прокси и быть в состоянии убедиться, что, поскольку новая сборка прибыла, каждый наш покупатель получит новую версию.
Чтобы все работало хорошо, мы решили кэшировать весь документ с заголовком, телом и нижним колонтитулом. Это своего рода предварительно обработанный (со всеми компонентами) результат, который хранится в кеше. Работает неплохо, но есть проблема.
Независимо от того, какую стратегию развертывания мы используем, мы все время сталкиваемся с этим. У нас есть два экземпляра, и поскольку мы развертываем новую сборку в одном из экземпляров с помощью метода Rolling (который рекомендуется AWS), мы аннулируем Memcache , но проблема в том, что экземпляр, который не был обновлен пока (предыдущая сборка), работает (обрабатывает запросы). То есть если старый экземпляр получит запрос быстрее, чем новый (что бывает иногда), то мы получим в кеше старую версию документа,
1. начните использовать простое имя файла для активов (избегайте хешей)
2. не используйте memcache , пока не будут обновлены все экземпляры
оба они не соответствуют нашим требованиям.
Есть ли другие решения?
Вы можете использовать сине-зеленые развертывания с устойчивой балансировкой нагрузки, но мне интересно, будет ли это достаточно надежным. Теоретически процент вашего трафика будет идти на новый сервер, включая запросы на статические ресурсы.
Другой вариант - развернуть статические ресурсы на всех серверах, а затем выполнить скользящее развертывание кода. Я бы не стал использовать здесь методы очистки кеша, я бы использовал имена файлов для обозначения версий ресурсов. Это означает, что вы можете кэшировать статические ресурсы в течение длительного времени, но при этом легко переходить к новым версиям при развертывании.
Другой вариант может заключаться в обслуживании всего трафика с одной машины, обновлении другой машины и затем выполнении переключения / переключения. 1255] Это действительно зависит от вашего приложения, вашей нагрузки и ваших предпочтений. Возможно, одна из приведенных выше идей подойдет вам или, по крайней мере, даст вам несколько вариантов для рассмотрения.