使用100%正常运行时间更新应用程序

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

没有100%的工作时间。即使是最好的系统也会将停机时间衡量为“5个9”,这意味着99.999%的正常运行时间。

另外,一个关键点:这种测量方法适用于 非计划的 停机时间,如在故障中。它不包括为定期维护而故意关闭系统的时间。

在任何情况下,目标都是安装/更新软件,而不会导致计划内或其他停机。如果Web服务器本机不支持动态重新加载,那么您的解决方案似乎是正确的,但我认为这是目前许多服务器内置的。也就是说,您只需要将新文件放到服务器上,它就会自动看到一些更改并开始使用它们。

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

100%正常运行时间?“5个9”表示每年停机315秒。如果你能做到这一点,你会做得很好的。

听起来像是一个不可能的面试问题。”…保持100%的正常工作时间,反应迅速,也可以更新…-给出了一个正常工作时间的指标,但没有一个指标用于响应。

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

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

因为他们要求进行无障碍升级,所以必须有一个冗余系统,而让服务器应用程序冗余的最佳方法就是使用硬件负载均衡器。在工作中,我们有铸造厂,我们所有的新产品都在思科的ace负载平衡机上。

所以您需要的是两个Cisco负载均衡器,在它们之间设置HSRP,以便在负载均衡器之间进行故障转移。在故障转移设置方面,您可能非常激进,但在我们的经验中,对这些设置过于激进可能会导致不必要的故障转移。另外,一定要关闭代理ARP(这会让你省心,因为Cisco默认会打开它)。

现在,您有了一个应用服务器集群,对吗?所以您有负载平衡器ping、端口ping和监视应用程序响应时间。您所需要的是至少两台服务器,但是您可以稍后添加更多服务器(容量计划在哪里?)在维护窗口中,从负载均衡器可以管理其中一个服务器。但是负载均衡器可以进行真正的wikid管理,在那里任何当前连接都会保留到自然完成为止。

在这种状态下,任何请求都会转到第二个服务器,而您在世界上的所有时间都可以对要升级的服务器做任何您想做的事情。就像真的,为什么要写一个应用程序有一个花哨的应用程序域重新加载的事情,当你将不得不每3个月重新启动服务器应用一个关键的Windows补丁时,无论如何?只需支付硬件的现金,并拥有100%的时间都能正常工作的东西,即使有计划外的问题,也能让你在5x9的范围内工作。

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

另外,如果他担心应用程序域之间的延迟,或者整个网络的延迟,那么这个家伙就会崩溃,因为使用适当的Cisco设备,gig链接上的延迟在微秒之内,而不是你的弱点。

祝你好运。

SpringDM服务器声称能够热部署/取消部署OSGi包。如果硬件能够保持足够长的时间,您就可以在不关闭服务器的情况下更新应用程序。如果这样做,它将成为所有JavaEE应用服务器的标准特性。