部署 ASP.NET 网站并以零停机时间更新 MSSQL 数据库答案

【问题标题】：Deploy ASP.NET web site and Update MSSQL database with zero downtime部署 ASP.NET 网站并以零停机时间更新 MSSQL 数据库
【发布时间】：2011-04-11 08:08:08
【问题描述】：

我对 ASP.NET 网站和 MSSQL 数据库部署有疑问。我们正在托管 asp.net 网站并开发了新版本，更改了一些 asp.net 文件，并对数据库进行了一些修改。什么是最好的为什么不停机上传新版本的网站和升级 MSSQL 数据库？

【问题讨论】：

旧版网站能否与新版数据库兼容？
不，新的数据库版本有很多新的字段，一些旧的被删除了。

标签： asp.net sql-server deployment

【解决方案1】：

在过去的 5 年里，我管理着一个每月发布一次的大型网站，并且在超过 95% 的时间里实现了零停机时间。不幸的是，关键是确保数据库始终向后兼容，但仅限于以前的版本，因此您有机会回滚。

因此，例如，如果您打算删除您的应用程序所依赖的列：

将您的应用程序代码更改为不依赖于列，然后释放它（不删除数据库中的列）。
在下一个版本中删除该列（因为应用程序不再依赖它）。

这需要您的开发团队一定的纪律，但如果您有正确的环境设置（开发/测试/暂存/生产），则非常容易实现。

发布时：

将数据库更改部署到尽可能接近生产的暂存环境。最好以自动化方式执行此操作，使用 SQL 比较和 SQL 数据比较之类的工具，这样您就知道数据库完全与您的测试环境保持同步。
使用旧应用程序执行“冒烟测试”，但使用新数据库架构，确保没有对数据库引入重大的破坏性更改。
发布您的应用程序代码。
Smoke 测试您的暂存应用程序。
发布到生产环境。

我们为确保网站零停机时间所做的另一件事是蓝绿部署。这包括为每个网站创建 2 个文件夹，更新一个并在 IIS 主目录更新后切换它。我在这里写过博客：http://davidduffett.net/post/4833657659/blue-green-deployment-to-iis-with-powershell

【讨论】：

【解决方案2】：

不要这样做。点。

零停机安装非常困难，涉及到数据库的多个副本、在暂存环境中对其进行预检查、仔细编程和重新同步数据库。

稍微停机时间总是比较好。晚上睡很长时间，凌晨2点部署。或者早点起床。确定何时租用不方便您的用户。

就所花费的时间而言，实现 100% 正常运行时间非常昂贵。除非这里有一个严格的商业案例，否则偶尔停机是一个更明智的商业决定。

【讨论】：

有可能。一直在开发一个计划停机时间要求为零的系统。除了可能每年一次进行重大更新。不过，这很残酷。对操作和工作的要求是可怕的。
“计划停机时间为零” ...“可能每年一次除外”。与 100% 正常运行时间不同。
并非总是如此。即使有一些非常困难的 100% 停机系统，有时您也有自然的时间可以将它们关闭。一个例子？我们开始 - 金融交易应用程序。即使在全球范围内交易，所有市场周日也不交易。不是一整天，因为数据分布通常在当地下午早些时候开始，但 oyu 每周有 12 小时的安全时间进行维护。 OTOH 一周中的中断可能是残酷的 ;)

【解决方案3】：

即使是像 salesforce.com 和 ebay.com 这样的大型网站也有预定的维护时段，在这些时段中，由于后端的更改，这些网站的至少一部分在一段时间内不可用。

对于 ebay，它是每个 Thursday night 并持续 4 小时，其中“某些功能在此期间可能会很慢或不可用”。对于销售人员，根据需要they schedule and notify users。

根据您的网站，您最好将 1 小时的窗口安排在您的网站处于最低流量水平的某个较晚时间。在 1 周前、1 天前和 1 小时前提前通知用户。

在使其脱机之前，请确保您从另一台服务器上当前生产数据库的副本测试您的部署。这将使您了解可能遇到的任何问题，并让您确切知道需要多长时间。通知用户时将该数字加倍。多次运行测试以确保不仅要花费时间，还要验证数据的一致性。

Duffman 对于在很短的窗口内并行运行版本以推送更新有一个很好的答案。但是，它们通常是数据模型更改的原因，通常最好在部署时转换所有现有数据。运行此转换可能会使某些事务在进行时无效并导致数据损坏。

经历了许多“热门”生产推动后，我可以 100% 肯定地说，我和我的客户都不想再处理这些问题了。绝对没有错误的余地。

【讨论】：