场景很简单：使用EF代码进行首次迁移，使用多个azure网站实例，大小合适的DB（如100GB）（假设是azure SQL），大量活跃的并发用户......对于它来说是20k。
目标：推出更新，与活跃用户一起，在升级时保持完整性。
我已经筛选了我能找到的所有文档。然而，核心细节似乎缺失或我公然忽略它们。当Azure通过FTP / git / tfs收到更新请求时，它如何处理更新？它对活跃用户有什么作用？例如，它是否冻结对所有实例的传入请求，让已处理的项目完成，升级/替换每个实例，让EF迁移过程，然后让流量再次开始？如果它同时升级/刷新所有实例，它如何确保EF迁移只运行一次？如果它在滚动升级过程中刷新实例（一次升级1而没有入站流量冻结），那么它如何确保完整性，因为较旧状态的实例会/可能会中断？
主要问题是，收到更新请求后的实际流程是什么？更新实时网站有哪些建议？
答案 0 :(得分：2)
简单地说，它没有。
EF迁移和Azure部署是两种非常不同的野兽。 Azure部署为您提供了许多选项，包括更新和暂存插槽，您可能已经看到过 Deploy a web app in Azure App Service，对于其他读者来说，这是一个很好的起点。
一般而言，Azure部署模型关注与IIS /网站堆栈的活动连接，通常更新通过将实例部署到负载平衡器池之外并将流量重定向到其他实例来确保不间断的用户访问。然后逐个循环更新实例。
这意味着在任何时间点，在更新部署期间，代码都会同时运行 多个 版本。
如果您的EF模型在代码版本之间没有变化，那么Azure部署就像魅力一样，用户甚至不知道它正在发生。但是，如果您需要在迁移过程中应用迁移 BEWARE
一般情况下，EF只会在代码和数据库版本匹配时加载模型。使用EF迁移并同时支持该模型的多个代码版本非常难
EF迁移主要由数据库初始化程序控制。 有关详细信息，请参阅Upgrade the database using migrations。
作为开发人员，您可以选择升级数据库的方式和时间，但要知道如果您正在使用Mirgrations和部署更新：
在实际站点上管理EF迁移的最简单方法是关闭包含EF迁移的部署的所有站点实例 - 您可以使用维护页面或重定向，这取决于您。
如果您遇到此问题，最好手动应用数据库更新，如果失败则可以轻松中止部署，因为它还没有启动！
否则，如果初始化程序已配置为执行此操作，则部署更新并启动第一个实例将运行迁移...
如果绝对必须持续部署站点代码/内容和模型更新，那么EF迁移可能不是开始使用的最佳工具，因为您会发现此方案的OOTB非常严格。
答案 1 :(得分：0)
我正在观看Pluralsight的“Fundamentals”课程，这一点被触及了。 如果您有3个站点，Azure将使一个站点脱机并升级，然后在准备好时重新启动它。此时，其他2个实例将脱机，您的升级后的内容将启动，从而运行架构更改。
当那些2回来时，EF迁移已经运行，因此您的站点又回来了。
从理论上讲，它听起来应该可行，但是根据需要运行的EF迁移量，请求可能会延迟。
但是，作者的评论是在这种情况下（即进行架构更改），您应该考虑您的网站是否可以在这种情况下运行。建议您要么使代码使用旧模式和新模式，要么显示“维护系统下页”。
摘要似乎取决于您实际升级的内容，这将影响并影响您的选择和部署方法。
答案 2 :(得分：0)
一般来说，如果您想支持有效升级，则需要同时支持多个版本的应用程序。这是在迁移/升级时可靠地保持活动状态的唯一方法。还可以考虑使用功能开关以受控方式扩展转换。