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

Bob*_*Bob 10 .net architecture

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

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

由于跨应用领域甚至整个网络进行通信之间的延迟问题,采访者对这个想法并不太疯狂.我说过一个关键任务应用程序你应该建立一个坚如磐石的基础设施,因为软件本身不能解决问题.他还说他们目前有一个使用relfection的系统.我想过将程序集加载到app域并观察目录以进行程序集更改,但这似乎太容易出错了.

有没有人建造有类似要求的东西?你用了什么解决方案?什么不起作用?反射是一种可用的选择吗?

Lar*_*ens 11

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


Cla*_*ton 6

100%的时间没有这样的事情.即便是最好的系统也将停机时间视为"5个9",这意味着99.999%的正常运行时间.

此外,关键点:此测量适用于非计划停机时间,如故障.它不包括将系统故意用于定期维护的时间.

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

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