是否可以在零停机时间内部署企业ASP.NET应用程序和SQL架构更改？

Question

我们有一个庞大的ASP.NET Web应用程序需要部署到LIVE，停机时间几乎为零或几乎为零。让我指出我已阅读the following question/answers但不幸的是它并没有解决我们的问题，因为我们的架构有点复杂。

假设目前我们有两台IIS服务器响应请求，并且两台服务器都连接到同一台MSSQL服务器。解决方案看起来像小菜一碟，但这不是因为我们不时要应用的主要架构变更。由于它的大小很大，简单的数据库备份大约需要8分钟，这已经变得不可接受，但出于安全原因，它必须在每次新部署之前进行。

我想请求您帮助尽可能缩短部署时间。如果您对不同的架构有任何好的想法，或者您使用的工具可以帮助我们，那么请不要害羞并分享信息。

目前我们提出的最好的想法是购买另一台SQL服务器，该服务器将被设置为原始数据库的副本。从负载均衡器，我们将所有新流量路由到两个IIS Web服务器之一。当第二个Web服务器没有运行会话时，我们可以部署新代码。现在来了困难的部分。此时我们将与网站脱机，取消两个SQL服务器之间的复制，这样我们就可以直接获得数据库的快照，并保持一致的状态（在8分钟内节省了7.5分）。最后，我们将更新主SQL服务器上的数据库模式，并在我们将第二个Web服务器升级到新版本时通过更新的Web服务器路由所有流量。

请分享您对此解决方案的看法。我们能以某种方式设法消除与网站脱机的需要吗？带有mammuth Web应用程序的bluechip公司如何进行部署？

每个想法或建议都非常受欢迎！购买新的硬件或软件确实不是问题 - 我们错过了突破性的想法。在此先感谢您的帮助！

编辑1（2010.01.12）：
另一个要求是消除人工干预，因此事实上我们正在寻找一种可以自动化方式应用的方法。

我想提醒你一下要求清单：
1.备份数据库
2A。部署网站
2B。更新数据库模式
3.更改为更新的网站
4（可选）：如果出现问题，可以轻松恢复旧网站。

Answer 1

首先，你可能没有意识到“point in time restore”的概念。长期和短期是，如果您正确备份事务日志，备份所需的时间并不重要 - 您始终可以恢复到任何时间点。您只需恢复上次备份并重新应用事务日志，然后就可以在部署之前进行恢复。

我倾向于建议在不同的网站定义上重新安装网站，并配置“死”主机标头 - 这是您的暂存网站。创建一个运行数据库的脚本一次更改（在事务中），然后翻转实时站点和暂存站点之间的主机头。

Answer 2

环境：

1. 当前的实时网站
2. 当前实时数据库
3. 新版网站
4. 新版数据库

方法：

1. 设置提要（例如复制，存储过程等），以便当前的实时数据库服务器将数据更新发送到新版本的数据库。
2. 更改路由器，以便新请求指向新版本的网站，直到旧网站不再提供请求为止。
3. 取下旧网站和数据库。

在这种方法中，停机时间为零，因为旧站点和新站点（及其各自的数据库）都可以并排提供请求。唯一的问题场景是有一个请求的客户端转到新服务器，后续请求转到旧服务器。在这种情况下，他们将看不到可能在新站点上创建的新数据。解决方案是将路由器配置为临时使用粘性会话，并确保新会话全部转到新的Web服务器。

Answer 3

一种可能性是在数据库中使用版本控制。

因此，您有一个全局设置，用于定义要使用的所有存储过程的当前版本。

When you come to do a release you do the following:
1. Change database schema, ensuring no stored procedures of the previous 
   version are broken.
2. Release the next version of stored procedures
3. Change the global setting, which switches the application to use the 
   next set of stored procedures/new schema.

棘手的部分是确保在更改数据库架构时不会破坏任何内容。

如果您需要进行基本更改，则需要使用“临时”表（用于一个版本），然后再转移到下一版本中所需的架构，或者您可以修改以前存储的版本程序更灵活。

这应该意味着几乎为零的停机时间，如果你能做对的话。

Answer 4

首先 - 做一些常规的小改动 - 我曾在几家主要的投资银行担任过各种24/7实时交易系统的自由开发人员，我见过的最好，最顺畅的部署模式是定期（月度）部署每次定义良好的回滚策略。

通过这种方式，所有更改都保持在最低限度，错误得到及时修复，开发不会出现蠕变，并且因为它经常发生，所以每个人都有动力将部署过程视为自动和打嗝尽可能。

但不可避免的是，大型架构的变化使得回滚变得非常困难（尽管知道并测试 - 如果必须的话，你将如何回滚仍然很重要。）

对于这些大的架构变化，我们采用了“弥合差距”的模型。也就是说，我们将实现一个几乎实时运行的数据库转换层，根据实时数据在第二个数据库中更新新样式架构数据的实时副本。目前部署的系统。

我们每天将这几次复制到UAT系统并将其用作测试的基础（因此测试人员总是有一个真实的数据集来测试，并且转换层正在作为其中的一部分进行测试）。 / p>

因此，数据库中的更改将持续在线运行，然后新系统的部署就是以下情况：

1. 冻结所有人
2. 关闭转换层
3. 启用新的应用程序层
4. 将用户切换到新的应用层
5. 解冻所有内容

这是回滚成为问题的地方。如果新系统运行了一个小时，则回滚到旧系统并不容易。反向转换层将是理想的，但我认为我们没有任何人愿意花时间在它上面。

最后，我们会在最安静的时间段内部署并让每个人都同意回滚会将我们带到切换点，任何丢失的东西都必须手动重新键入。请注意 - 这会激励人们正确测试内容：）

最后 - 如何进行转换层 - 在一些较简单的情况下，我们在数据库中使用了触发器。只有一次，我认为我们将代码移植到先前版本中进行了“双重更新”，即对当前系统的原始更新，以及对新样式架构的另一次更新。目的是在下一个版本中发布新系统，但是测试显示需要对数据库进行调整，此时“转换层”正在生产中，因此该过程变得混乱。

我们最常用于转换层的模型只是运行另一个服务器进程，观察数据库并根据任何更改更新新数据库。这很好，因为代码在生产之外运行，可以随意更改而不会影响生产系统（好吧 - 如果你可以运行生产数据库的复制，但是否则你必须注意不要生产生产带有一些自杀性查询的数据库 - 只需在代码的这一部分上放置最认真的人！）

无论如何 - 抱歉为漫长的漫步 - 希望我把这个想法放在一边 - 继续将你的数据库部署作为“实时，运行”部署到第二个数据库，然后你要做的就是部署新系统所要做的就是部署应用程序层并将所有内容传递给它。

Answer 5

我建议您使用Analysis Services而不是数据库引擎来满足您的报告需求。然后你可以处理你的立方体..移动你的数据库..更改连接字符串，重新处理你的立方体，从而 - 没有停机时间。

死严重......世界上没有比Analysis Services更好的产品了。

Answer 6

正如您所说，购买新服务器时没有问题，我建议最好的方法是先让新服务器部署您的应用程序。请遵循以下步骤：
1.如果需要，将新证书添加到此新服务器并使用新设置测试应用程序。
2.关闭旧服务器并将其IP分配给新服务器，停机时间与服务器停机时间相同，并将新IP分配给新服务器。
3.如果您看到新部署不起作用，则可以再次按照步骤2恢复。
关于数据库备份，您必须设置备份计划。

Answer 7

我刚才看过这篇文章，但从未使用它，因此无法保证易用性/适用性，但MS有一个免费的Web场部署框架可能适合您：

http://weblogs.asp.net/scottgu/archive/2010/09/08/introducing-the-microsoft-web-farm-framework.aspx

Answer 8

请在此处查看我的回答：How to deploy an ASP.NET Application with zero downtime

我的方法是使用轮询AppDomains和命名互斥锁的组合来创建原子部署代理。

Answer 9

我刚才在这里回答了类似的问题：Deploy ASP.NET web site and Update MSSQL database with zero downtime

讨论如何在零停机期间更新数据库和IIS网站，主要是确保数据库始终向后兼容（但仅限于上一个应用程序版本）。