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