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

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

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

此外,一个关键点是:这种测量适用于 非计划中的 停机时间,如失败。它不包括您故意关闭系统进行定期维护的时间。

在任何情况下,目标都是安装/更新软件,而不会导致停机,无论是计划停机还是其他停机。如果web服务器本身不支持动态重新加载,那么您的解决方案似乎是正确的,但我认为现在很多服务器都内置了动态重新加载。也就是说,你只需要将新文件放到服务器上,它就会自动看到有什么变化并开始使用它们。

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

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

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

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

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

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

因此,您需要的是两个思科负载均衡器,在它们之间设置HSRP,以便在负载均衡器之间进行故障转移。您可以非常积极地使用故障转移设置,但根据我们的经验,过于积极地使用这些设置可能会导致不必要的故障转移。此外,请确保关闭代理arp(这会让你省心,因为思科默认情况下是打开的)。

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

在这种状态下,任何请求都会发送到第二台服务器,你有足够的时间对要升级的服务器做任何你想做的事情。就像真的一样,当你必须每3个月重新启动服务器才能应用关键的windows补丁时,为什么要编写一个具有花哨的应用程序域重新加载功能的应用程序呢?只需为硬件支付现金,并拥有一种100%正常工作的东西,即使出现意外问题,也能让你达到5x9的范围。

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

此外,如果他担心应用程序域之间的延迟,或者整个网络的延迟,那么这个人就会崩溃,因为使用合适的思科设备,千兆链路上的延迟在微秒级,而不是微秒级。你是弱点。

祝你好运。

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