如何在对用户影响最小的情况下将网站部署到生产环境

Question

我正在寻找最佳的服务器架构解决方案，以便向一个外部公共Asp.net网站发布每月更新。我要寻找的是发布新版本网站的方法，对用户的影响最小。除了采用标准方式进行部署（即停止IIS，将新网站复制到现有网站上，启动IIS），还有哪些更好的部署解决方案？在更新期间，如果他们保留他们的会话并且不必看到“网站维护中”消息，那就太好了。

我的服务器配置：

我们有2个IIS Web服务器（2003年），正在尝试找出最佳的利用它们进行部署的方法。我的第一个想法是使用最新版本更新非活动Web服务器。然后，通过最小化对用户的影响来使web流量优雅地指向该服务器（最好情况下，用户不会失去他的会话）。您将如何从服务器1重定向Web流量到服务器2？更改防火墙NAT？更改DNS记录？还是其他方式？我们需要能够在发布新更改后立即测试实时站点（显然）。

顺便说一句，我们正在使用nant和cruise control自动化构建，并使用自定义Web服务将构建部署到生产环境中。因此，只需单击按钮即可完成所有操作。

是否可以使用第三个服务器实现更好的解决方案？如果可以，怎么做？

- goku_da_master

Answer 1

首先，考虑使用负载均衡解决方案。Windows 2003服务器附带了Windows负载平衡（WLBS），虽然它不是最好的产品，但是它是免费的。使用它可以将所有流量指向一个服务器，更新它，然后执行相反的操作。

其次，您可能需要考虑一下如何处理会话。HTTP是无状态的，这意味着只要您可以在任何页面上重建用户的会话，您就应该没问题。朝着这个目标迈出的一个理想步骤是使用ASP.NET表单身份验证-它写入的cookie与ASP.NET会话没有关联。当然，这种方法也带来了更大的风险-如果用户在您复制文件时恰好访问某些东西，则有可能会看到错误屏幕。然后，将会有一个延迟，因为应用程序池正在刷新。

总的来说，您更好的选择是负载均衡。即使有了它，还是要考虑尝试第二个选项-具有可以重新生成的会话，如果用户未粘滞在池中的其中一个服务器上，则效果很好。

- John Christensen

---

谢谢John。这证实了负载均衡器可能是最好的解决方案。 - goku_da_master

Answer 2

我们的做法是：

我们使用来自 Netscaler 的负载均衡器，

将其中一个 Web 服务器从负载均衡器中取出，进行所有部署操作，执行 iisreset，然后再放回负载均衡器。

对于 server2 做同样的事情。

最后使负载均衡器缓存失效。

- kobe

---

只是好奇想知道 - 在您将Web服务器从负载均衡器中移除之前，您是否确保没有用户在其上保持活动会话 - 如果是这样，您是如何做到的？还是说您只是使用像数据库这样的内存外会话来确保用户不会丢失现有会话？ - Jagmag

@inSane，负载均衡器会处理这个问题，这取决于你如何设置粘性会话或非粘性会话。当新请求进来时，用户将被重定向到新的Web服务器，并且只要URL正确，它就会再次使用他正在使用的相同会话。 - kobe

我知道这是一个晚评论，但感谢您提供详细的解释。我猜想，即使您升级了1台服务器并将其放回负载均衡器，现在由于负载均衡器缓存的原因，两台服务器都具有不同的代码库，它也不会弄乱一切，对吗？ - goku_da_master

Answer 3

我想补充一下，我的以前的工作中，我们通过使用以下设置实现了无缝部署：

一个负载均衡器会指向生产ASP.NET Web服务器（在您的情况下有两个，但我们有三个），而Web服务器将设置其会话以从专用于托管OutOfProc ASP.NET会话的第三个服务器中获取。

要部署网站，我们会将其中一个服务器从负载均衡器中取出，更新文件，重新启动它，然后将其放回到负载均衡器池中。对于其他Web服务器也是如此。

由于每个Web服务器都从一个中央服务器获取会话数据，因此取出一个Web服务器并不会注销该服务器上的用户。

如果我们有与现有会话数据不兼容的代码更改，我们会等待计划维护窗口进行部署。否则，具有该会话数据的用户将在注销之前收到错误信息。

另外，由于此设置依赖于Web服务器处于运行状态，因此如果您想提高可靠性，可以将OutOfProc更改为基于SQL的会话服务器。您需要多个服务器来复制相同的会话数据库并将Web服务器指向它们。这样做更加复杂，但可以减少网站停机时间。

- Justas