不停止更新生产 IIS 网站和 SQL Server 数据库

Question

有一个使用测试数据库的测试服务器。我们在测试服务器上测试网站。如果没问题，我们将网站和数据库模式从测试服务器更新到生产服务器。但是这种方法是非常痛苦和危险的。

首先，我们必须将用户重定向到维护页面，因此网站会暂停一段时间。

其次，如果更新时出现问题，我们必须回到旧网站，因为我们不能让网站长时间处于维护模式。

所以我正在寻找一个可靠的解决方案来更新 IIS 网站和 Sql Server 数据库，而不会丢失数据并使用维护模式。有没有办法做到这一点？大型网站如何在不丢失数据和暂停的情况下做到这一点。

我们考虑过使用发布候选网站。我们计划暂时使用这个 RC 网站。首先，我们更新 RC 站点，然后交换 RC 和生产站点之间的绑定。但是这次数据库有问题。因为我们可以更改数据库架构，而旧的架构不能与新数据库一起使用。因此，如果我们使用带有 temp db 的临时站点，就会有数据丢失。此外，如果临时站点使用旧的生产数据库，则更新后的网站将无法使用旧数据库。所以我需要一个可靠且实用的解决方案来解决这个问题。

Answer 1

这比您想象的要复杂几个数量级。这具体不是关于 HA 也不是关于连续集成。这些都不能满足您的需求，它们只是更复杂的难题的一部分。

根本不可能以对架构更改透明/无视的方式编写代码更改当它们发生时。充其量您可以以支持 v. N 和 v. N+1 的模式的方式编写代码，这本身就是一个很大的挑战。但是不可能以支持模式从v. N 转换为 到v. N+1 的方式编写代码。对于在模式上运行的代码，部署引起的模式更改必须是原子的。由于架构更改本身不能是原子的，因此升级有两种可能的途径：

• 在架构更改期间使代码脱机。这就是你现在正在做的，也是最安全的方法。当然，这意味着服务可用性停机时间并运行您已经经历过的风险（升级失败的回滚、冗长的升级等）。这种方法的一个变体是将服务重定向到数据的只读副本，并提供降级的服务体验（在停机期间不可能进行任何更改），这可能会或可能不会接受，具体取决于业务细节。

• 备用升级。这意味着您拍摄服务数据的快照（各种 HA 解决方案可能会提供开箱即用的备用快照，例如日志传送）。升级快照，然后将真实服务数据上发生的所有事务应用到升级的快照。这总是很棘手，因为它需要一种技术来检测、捕获和应用更改（例如更改跟踪、复制、自定义解决方案等）并且需要将每个更改转换为新的、升级的模式.一旦升级的模式与主服务的更改保持同步，服务就可以重定向到升级的模式。这种重定向也比听起来要复杂得多。对于选择何时切断旧模式并停止接受新更改，同时确保所有更改应用于新升级的模式数据库本身就是一个挑战。另一个挑战是解决代码理解升级前和升级后模式版本的冲突。正如我所说，开发同时处理这两种情况的代码存在问题且容易出错，因此一种解决方案是再次让服务在短时间内离线并替换代码。另一种解决方案是拥有一个备用服务，运行处理升级后数据库模式并连接到升级后数据库的代码，并将实时请求重定向到您的备用、升级服务。

当一个更大的部署解决方案的特定服务必须升级时，我什至没有触及服务交互这个棘手的主题。这是service API protocol back compatibility 发挥主要作用的时候，它允许升级后服务与其对等服务一起发挥作用。

最终没有任何灵丹妙药。我目睹了单机大型数据库部署需要 几周 来推出版本 N+1，其中转录复制连续地为升级后数据库模式提供来自升级前数据库的更改。我目睹了数千台机器分阶段部署版本 N+1，这是一场复杂的舞蹈，需要在几天内更改代码和数据以实现升级后的全部功能。这个问题很简单困难。

Answer 2

这就是 Azure 的绝妙之处。 Azure 云平台允许登台服务器和生产服务器。您可以对其进行设置，以便在将更改提交到 Git 或 TFS 后，它会自动推送到登台或生产服务器。您还可以设置为手动推送更改。大多数 ORM 库（如 Entity Framework）都支持迁移。

有很多关于这个主题的信息，比如： Azure seamless upgrade when database schema changes Staging or Production Instance?

Answer 3

您正在描述一种高可用性解决方案 (HA)。 HA 解决方案很昂贵，而且很快就会过火。您需要为您的应用程序和数据库服务器提供冗余，这意味着设置一个数据库集群。所有这些都会增加您部署更改所花费的时间，但代价是您的应用始终可用。

部署的主要内容是有一个可重复的过程。所以我最好的建议是尽可能地编写脚本或自动化。