更新数据库、API 和 Web 应用程序时的版本控制问题答案

【问题标题】：Versioning issue when updating databases, api and web application更新数据库、API 和 Web 应用程序时的版本控制问题
【发布时间】：2016-12-20 15:03:22
【问题描述】：

我有数千个 SQL Server 数据库（每个客户端一个）。当我们决定推进生产时，我们大部分时间都在数据库、Web API 和 Web 应用程序中进行更改。

问题在于部署所有内容（尤其是数据库）所需的时间。我们正在使用最新版本的 Code First 迁移和 MVC .NET 和 SQL Server。它是一个 SaaS。并且代码优先迁移过程能够一个一个地更新数据库。

API 和 Web 应用程序在几秒钟内即可快速部署。但是，数据库在大约 30 分钟内全部更新。在此期间，一些用户遇到错误并且无法使用该软件，因为 API 试图以未更新的数据库为目标。更糟糕的是，如果在数据库更新过程中出现故障并停止，未更新的用户将被卡住，直到我们修复问题并更新其余数据库。

知道如何解决这个问题并让客户满意吗？

PS：Web 应用程序不访问数据库，而只访问 API。

【问题讨论】：

如果您有 1,000 个数据库，那么您确实无能为力。更新所有这些数据库需要时间。您唯一能做的就是在更新过程中使应用程序脱机……无论如何，这确实应该发生。找到一个可以进行系统升级的时间窗口，并确保您的客户了解该窗口。在这段时间内进行更新，没有人应该有任何问题。
我还会考虑逐个更新每个客户端数据库，而不是一次全部更新。

【解决方案1】：

这个问题有点基于意见。维护窗口方法是最简单的。如果您想进行实时更新，另一种方法是：

实现这一点的最可维护的方法可能是拥有至少 3 台服务器：

路由只能在登录时进行，或者您可以做一些更花哨的事情，例如在检测到升级时重定向登录的用户。显然，这些都不涉及在实际升级该客户端的数据库期间发生在该特定客户端上的情况。你仍然需要单独解决这个问题。

【讨论】：

这很好。然而，前端也有很多变化，所以它应该是版本化的，它应该带有一个特定的 API 版本。但是我们正在使用子域来选择客户端，因此在这种情况下是在登录阶段使用的版本。所以我想我们需要某种“登录”网站来重定向到正确的网络服务器。但是我如何才能将“登录”网站透明地路由到正确的前端服务器？所以域将保持不变（我们使用通配符 SSL）。
为什么域保持不变？为什么每台服务器都没有子域？例如，我公司使用的一款 SaaS 产品有一个www.company.com 登录页面和一个ww3.company.com 前端服务器。我假设他们在某处也有 ww1 和 ww2 服务器