Как лазурные сайты с EF-миграциями обеспечивают целостность при обновлении
Сценарий прост: с использованием первых миграций кода EF, с несколькими экземплярами веб-сайта Azure, приличным размером базы данных, такой как 100 ГБ (при условии Azure SQL), множеством активных одновременно работающих пользователей... скажем, 20 тыс. За это.
Цель: выпустить обновление, с активными пользователями, сохранить целостность при обновлении.
Я просмотрел все документы, которые смог найти. Однако основные детали, кажется, отсутствуют, или я явно упускаю их из виду. Когда Azure получает запрос на обновление через FTP/git/tfs, как он обрабатывает обновление? Что это делает с активными пользователями? Например, блокирует ли он поступающие запросы ко всем экземплярам, позволяет ли уже обработанным элементам завершиться, обновляет / заменяет каждый экземпляр, позволяет процессу миграции EF, а затем разрешает повторный запуск трафика? Если он обновляет / обновляет все экземпляры одновременно, как он обеспечивает миграцию EF только один раз? Если он обновляет экземпляры, находящиеся в процессе непрерывного обновления (обновление 1 за один раз без замораживания входящего трафика), как он может обеспечить целостность, поскольку экземпляры в более старом состоянии могут / могут потенциально сломаться?
Главный вопрос, каков реальный процесс после получения запроса на обновление? Каковы рекомендации по обновлению живого сайта?
3 ответа
Проще говоря, это не так.
EF Migrations и Azure - два совершенно разных зверя. Развертывание Azure предоставляет несколько вариантов, включая обновление и промежуточные слоты, которые вы, вероятно, видели
Разверните веб-приложение в службе приложений Azure, для других читателей это хорошая отправная точка.
В общем, модель развертывания Azure касается активных подключений к стеку IIS/ веб-сайта, в целом обновление обеспечивает бесперебойный доступ пользователей, выводя развертываемый экземпляр из пула балансировщика нагрузки и перенаправляя трафик на другие экземпляры. Затем он циклически обновляет экземпляры один за другим.
Это означает, что в любой момент времени при развертывании обновлений одновременно будет работать несколько версий вашего кода.
Если ваша модель EF не изменилась между версиями кода, то развертывание Azure работает как чудо, пользователи даже не узнают, что это происходит. Но если вам нужно применить миграцию как часть миграции, ВНИМАНИЕ!
В общем случае EF загружает модель только в том случае, если версии кода и БД совпадают. Очень сложно использовать EF Migrations и поддерживать несколько версий кода модели одновременно.
Миграции EF в значительной степени контролируются инициализатором базы данных. См. Обновление базы данных с использованием миграций для получения подробной информации.
Как разработчик, вы можете выбрать, как и когда будет обновляться база данных, но знаете, что, если вы используете Mirgrations и обновления развертывания:
- Новый код не будет легко работать со старой схемой данных.
- Если старый код / приложение перезапускается, многие стратегии инициализации по умолчанию попытаются откатить схему назад, если это произойдет, обратитесь к пункту 1.;)
- Если вы обойдете модель EF, загружающуюся против неправильной версии схемы, вы столкнетесь с исключениями и общими сбоями, когда код попытается использовать элементы схемы, которых там нет.
Простейший способ управления миграцией EF на работающем сайте - отключить все экземпляры сайта для развертываний, включающих миграцию EF. Вы можете использовать страницу обслуживания или перенаправление, которое вам решать.
Если вы столкнетесь с этой проблемой, то, вероятно, лучше применить обновление БД вручную, а затем, если это не удастся, вы можете легко прервать развертывание, потому что оно еще не началось!
В противном случае разверните обновление, и первый экземпляр, который будет ускоряться, запустит миграцию, если инициализатор настроен для этого...
Если вам абсолютно необходимо непрерывное развертывание обновлений как кода / контента сайта, так и обновлений модели, то миграции EF, возможно, не лучший инструмент для начала работы, поскольку вы найдете это очень ограниченным OOTB для этого сценария.
Я смотрел курс "Основы" по Pluralsight, и это было затронуто. Если у вас есть 3 сайта, Azure отключит один и обновит его, а затем, когда будет готов, перезапустите его. В этот момент другие 2 экземпляра отключаются, и запускается ваш обновленный insance, что приводит к изменению схемы.
Когда эти 2 вернутся, миграция EF уже будет запущена, поэтому ваши сайты вернутся.
Теоретически, все это звучит так, как будто должно работать, хотя в зависимости от того, сколько нужно выполнить миграций EF, запросы могут быть отложены.
Тем не менее, комментарий автора состоял в том, что в этом сценарии (т. Е. При внесении изменений в схему) вы должны учитывать, может ли ваш сайт работать в этой ситуации. Предполагается, что вы должны либо заставить свой код работать как со старой, так и новой схемами, либо показать "страницу поддержки системы".
В итоге получается, что в зависимости от того, что вы на самом деле обновляете, это повлияет на ваш выбор и метод развертывания.
Вообще говоря, если вы хотите поддерживать активные обновления, вам необходимо поддерживать несколько версий приложения одновременно. Это действительно единственный способ надежно оставаться активным во время миграции / обновления. Также обратите внимание на переключатели функций, чтобы увеличить конверсию контролируемым образом.