以 100% 的正常运行时间更新应用程序答案

【问题标题】：Updating an application with 100% uptime以 100% 的正常运行时间更新应用程序
【发布时间】：2009-01-04 15:08:19
【问题描述】：

在过去的一次采访中，有人问我如何编写一个必须保持 100% 正常运行时间、响应速度非常快且可更新的关键任务 Windows 服务。该服务被描述为一个基于远程处理的应用程序，它接收请求、执行计算并发送回响应。

我的解决方案是拥有一个非常通用的服务，它只是充当网关。这项服务永远不会停止。它将请求排队并将它们转发到一个单独的应用程序域中的另一个服务，该应用程序域将实际处理请求。至少需要有两个这样的处理服务，这样一个可以被关闭以进行更新，而另一个可以响应传入的请求。服务之间的接口将包括握手以查看服务是否正在运行的能力。将存在一个非常小的超时，因此如果服务完全退出，它不会阻止请求。我还强调了这个解决方案可以很好地扩展这一点，因为您可以在不同的盒子上添加更多这些服务。

由于跨应用域甚至跨网络通信之间的延迟问题，面试官对这个想法并没有太疯狂。我说过，对于任务关键型应用程序，您应该建立一个坚如磐石的基础设施，因为仅靠软件无法解决问题。他还说，他们目前有一个使用 relfection 的系统。我曾考虑将程序集加载到应用程序域并查看目录以了解程序集更改，但这似乎太容易出错了。

有没有人构建任何具有类似要求的东西？您使用了哪些解决方案？什么不起作用？反射是一个可用的选项吗？

【问题讨论】：

标签： .net architecture

【解决方案1】：

.Net 内置了对在使用时更新程序集的支持。它被称为Shadow Copy 并在加载它们之前有效地将程序集复制到单独的目录中。在加载新版本之前，您仍然需要卸载 appdomain，但其他 appdomains 仍然可以使用旧版本的程序集。这样一个 appdomain 就可以在新的 appdomain 加载时为请求提供服务。这也是 IIS 和 ASP.Net 处理事情的方式。

【讨论】：

【解决方案2】：

没有 100% 的正常运行时间。即使是最好的系统也以“5 个九”来衡量停机时间，这意味着 99.999% 的正常运行时间。

还有一个关键点：此测量适用于计划外的停机时间，例如故障。它不包括您为定期维护而故意关闭系统的时间。

在任何情况下，目标都是安装/更新软件而不会导致停机、计划或其他方式。如果 Web 服务器本身不支持动态重新加载，那么您的解决方案似乎是正确的，但我认为现在很多服务器都内置了这种方法。也就是说，您只需将新文件拖放到服务器上，它就会自动发现某些内容发生了变化并开始使用它们。

但是，取决于可能导致会话状态问题的更改的性质。也就是说，现有的用户会话最终可能会在会话中存储与您的新代码不兼容的对象。同样，服务器可能足够聪明，可以保留原始代码的缓存副本，直到使用旧代码的所有会话都终止，但也许您需要自己处理。您的“影子服务器”方法应该可以很好地处理这个问题。

【讨论】：

【解决方案3】：

100% 正常运行时间？ “五个九”意味着每年 315 秒的停机时间。如果你能做到这一点，你确实做得很好。

听起来像是一个不可能的面试问题。 “...保持 100% 的正常运行时间，响应迅速，并且可以更新...” - 给出了一个正常运行时间指标，但没有给出响应能力。

延迟是一个值得担心的问题，但后来他们说这是一个远程应用程序，所以你无法摆脱它。我认为面试官可能出于自身的原因不同意，也许是为了看看你会如何处理。

【讨论】：

【解决方案4】：

好吧，背景很少，我在无线电信工作，我们的平台需要绝对的正常运行时间，并且已经了解了所有不同的策略，你绝对不应该使用基于软件的方法，它增加了软件的复杂性，你只需要要做的是添加一些硬件。

由于他们要求进行无中断升级，因此必须有一个冗余系统，而让服务器应用程序冗余的绝对最佳方法是使用硬件负载平衡器。在工作中，我们有代工厂，我们所有的新东西都在 Cisco Ace 负载平衡器上进行。

因此，您需要两个 Cisco 负载平衡器，在它们之间设置 HSRP 以在负载平衡器之间进行故障转移。您可以对故障转移设置非常激进，但根据我们的经验，对这些设置过于激进可能会导致不必要的故障转移。另外，请确保关闭 proxy-arp（它会为您省去心痛，因为 cisco 默认情况下已启用它）。

现在，您有一个应用服务器集群，对吧？所以你有负载平衡器 ping、端口 ping 和监控应用程序响应时间。您只需要至少两台服务器，但您可以稍后添加更多（容量计划在哪里？）。所以现在这里是无中断升级，在您的维护窗口期间，您可以从负载均衡器管理您的服务器之一。但是负载平衡器可以执行真正的 wikid 管理员操作，任何当前连接都会保留，直到它们自然完成。

在这种状态下，任何请求都会发送到第二台服务器，并且您有时间对正在升级的服务器执行任何您想做的事情。就像真的一样，当您必须每 3 个月重新启动服务器以应用关键的 Windows 补丁时，为什么还要编写一个具有花哨的应用程序域重新加载功能的应用程序？只需为硬件掏出现金，并拥有可以 100% 正常工作的东西，即使出现计划外的问题，也能让你进入 5x 9 的范围内。

现在是下一步，地理冗余。思科确实有可以进行地理负载平衡的负载平衡产品，但我从未见过。我见过的最好的地理模型实际上是基于请求的应用程序。这不是无中断升级，但绝对可靠。您所做的是在请求应用程序中配置主服务器和故障转移服务器 IP 地址。如果服务器不可用，它的请求中的应用程序将向备用服务器发起相同的请求，在这种情况下，备用服务器可能位于同一服务器机房或备份位置。理想的组合是应用程序可以在一个位置或备份位置定位负载均衡器虚拟 IP，并且您可以使用负载均衡器在每个位置保持 100%。

另外，如果他担心应用程序域之间的延迟，或者整个网络的延迟，那家伙就在破解，因为使用正确的 cisco 设备，gig 链接上的延迟只有几微秒，而且不会是你很弱点。

祝你好运。

【讨论】：

【解决方案5】：

Spring dm Server 声称能够对 OSGi 包进行热部署/取消部署。如果硬件可以保持足够长的时间，您就可以更新应用程序而无需关闭服务器。如果这一点流行起来，它将成为所有 Java EE 应用服务器的标准功能。

【讨论】：