场景很简单:使用 EF 代码优先迁移、多个 azure 网站实例、100GB 等合适大小的数据库(假设 azure SQL)、大量活跃的并发用户......比如说 20k。
目标:推出更新，拥有活跃用户，升级时保持完整性。
我已经筛选了我能找到的所有文档。然而，核心细节似乎缺失，或者我公然忽视了它们。当Azure通过FTP/git/tfs收到更新请求时，它如何处理更新？它对活跃用户有什么作用？例如，它是否卡住所有实例的传入请求、让已处理的项目完成、升级/替换每个实例、让 EF 迁移处理、然后让流量重新开始？如果同时升级/刷新所有实例，如何确保 EF 迁移仅运行一次？如果它在滚动升级过程中实时刷新实例(一次升级 1 个且没有入站流量卡住)，那么它如何确保完整性，因为旧状态的实例可能会/可能会损坏？
主要问题，它收到更新请求后，真实的流程是怎样的？更新实时网站有哪些建议？
最佳答案
简单来说，事实并非如此。
EF 迁移和 Azure 部署是两个截然不同的领域。 Azure 部署为您提供了许多选项，包括更新和暂存槽，您可能已经见过
Deploy a web app in Azure App Service ，对于其他读者来说，这是一个很好的起点。
一般来说，Azure 部署模型关注与 IIS/网站堆栈的事件连接，一般来说，更新通过将正在部署的实例从负载均衡器池中取出并将流量重定向到其他实例来确保不间断的用户访问。然后它会循环更新一个又一个的实例。
This means that at any point in time, during an update deployment there will be multiple versions of your code running at the same time.
如果您的 EF 模型在代码版本之间没有发生变化，那么 Azure 部署就像一个魅力，用户甚至不会知道它正在发生。但如果您需要在迁移过程中应用迁移请注意
In General, EF will only load the model if the code and DB versions match. It is very hard to use EF Migrations and support multiple code versions of the model at the same time
EF 迁移主要由数据库初始化程序控制。 请参阅Upgrade the database using migrations了解详情。
作为开发人员，您可以选择数据库升级的方式和时间，但要知道，如果您使用的是迁移和部署更新:
- 新代码将无法轻松针对旧数据架构运行。
- 如果旧代码/应用程序重新启动，许多默认初始化策略将尝试回滚架构，如果发生这种情况，请参阅第 1 点。;)
- 如果您绕过 EF 模型加载错误版本的架构，那么当代码尝试使用不存在的架构元素时，您将遇到异常和一般失败
在实时站点上管理 EF 迁移的最简单方法是为包含 EF 迁移的部署关闭该站点的所有实例 - 您可以使用维护页面或重定向，这取决于您。
如果您遇到这个麻烦，最好手动应用数据库更新，然后如果失败，您可以轻松中止部署，因为它尚未开始!
否则，部署更新并且第一个启动的实例将运行迁移(如果初始化程序已配置为这样做)...
如果您绝对必须持续部署站点代码/内容和模型更新，那么 EF 迁移可能不是最好的入门工具，因为您会发现它对于这种情况的 OOTB 非常严格。
关于azure - 具有 EF 迁移的 Azure 网站如何确保更新时的完整性，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/12023803/