想象一下,我们有一个复杂的 asp.net 解决方案:MSSQL + ASP.NET MVC + ASP.NET Web Forms + WCF 服务托管在 IIS 中。
每周一次,解决方案必须为用户透明地部署到单个生产服务器。部署可以包括数据库方案的更改、较小的 IIS 重新配置、文件替换。部署会消耗时间并且可能会影响正常运行时间。
如何在不中断用户的情况下进行部署或最大限度地减少停机时间?有哪些技术和最佳实践?
(例如切换分段/生产环境)
想象一下,我们有一个复杂的 asp.net 解决方案:MSSQL + ASP.NET MVC + ASP.NET Web Forms + WCF 服务托管在 IIS 中。
每周一次,解决方案必须为用户透明地部署到单个生产服务器。部署可以包括数据库方案的更改、较小的 IIS 重新配置、文件替换。部署会消耗时间并且可能会影响正常运行时间。
如何在不中断用户的情况下进行部署或最大限度地减少停机时间?有哪些技术和最佳实践?
(例如切换分段/生产环境)
如果您最关心的是正常运行时间,您可以查看该站点的负载平衡服务器 - 一个可以关闭、更新然后重新启动,而另一个则可以更新。您需要查看在这种情况下如何管理会话,例如使用 sql server 或 state server 机制。
我无法提供完整的解决方案,但有几点“对我有用”:
将您的数据库升级分为 (a) 向后兼容的更改和 (b) 重大更改。这样,您可以在旧版本的软件仍在运行时运行 (a) 部分(添加字段、添加表、添加索引,...)。对于(b)部分(更改字段类型,转换数据,...),我认为无法避免停机。尝试使大多数数据库更改不中断。
宣布停机时间,以便您的用户能够适应它。在升级时,使用app_offline.htm 功能确保您的用户看到一个很好的错误消息来解释这种情况。它还确保您的应用程序被重新加载。无需重新加载(即“仅替换文件”)的 Web 应用程序的就地、无停机升级可能会导致奇怪的错误。
测试升级:制作生产系统(软件加数据库)的副本,这在系统运行时应该是可行的。在测试系统上执行升级。如果在升级过程中出现问题:修复问题,改进升级过程并重复。