用最少的停机时间部署Java webapps的最佳实践?

内容来源于 Stack Overflow,并遵循CC BY-SA 3.0许可协议进行翻译与使用

  • 回答 (2)
  • 关注 (0)
  • 查看 (10)

部署大型Java Web应用程序(> 100 MB .war)时,我正在使用以下部署过程:

  • 应用程序.war文件在开发机器上进行本地扩展。
  • 扩展的应用程序是从开发机器到实时环境的rsync:ed。
  • 实时环境中的应用服务器在rsync之后重新启动。这一步并非严格需要,但我发现在部署时重新启动应用程序服务器可避免由于频繁的类加载而导致“java.lang.OutOfMemoryError:PermGen space”。

这种方法的好处:

  • rsync最大限度地减少了从开发机器发送到现场环境的数据量。上传整个.war文件需要10分钟以上,而rsync需要几秒钟的时间。

这种方法的坏处:

  • 当rsync运行时,应用程序上下文会在文件更新后重新启动。理想情况下,重启应该在rsync完成之后发生,而不是在它仍在运行时发生。
  • 应用程序服务器重新启动导致大约两分钟的停机时间。

我想找到一个具有以下属性的部署过程:

  • 部署过程中停机时间最短。
  • 花费最少的时间上传数据。
  • 如果部署过程是特定于应用服务器的,那么应用服务器必须是开源的。

题:

  • 鉴于所述的要求,什么是最佳部署过程?
提问于
用户回答回答于

已经注意到,在将更改推送到WAR文件时,rsync无法正常工作。原因是WAR文件基本上是ZIP文件,默认情况下是使用压缩成员文件创建的。成员文件的小改动(压缩之前)导致ZIP文件的大规模差异,导致rsync的增量转换算法无效。

一种可能的解决方案是使用jar -0 ...来创建原始的WAR文件。该-0选项告诉jar命令在创建WAR文件时不压缩成员文件。然后,rsync比较旧版本和新版本的WAR文件时,增量转移算法应该能够创建小差异。然后安排rsync以压缩格式发送差异(或原始文件); 例如rsync -z ...在下面使用或压缩的数据流/传输。

编辑:根据WAR文件的结构,可能还需要使用它jar -0 ...来创建组件JAR文件。这将适用于频繁更改(或者简单重建)的JAR文件,而不适用于稳定的第三方JAR文件。

理论上讲,这个过程应该比发送常规WAR文件有显着的改进。在实践中我没有尝试过,所以我不能保证它会起作用。

缺点是部署的WAR文件会更大。这可能会导致更长的webapp启动时间,但我怀疑这种影响是微不足道的。

完全不同的方法是查看WAR文件,看看是否可以识别可能(几乎)不会改变的库JAR。将这些JAR从WAR文件中取出,并分别将它们部署到Tomcat服务器的common/lib目录中; 例如使用rsync

用户回答回答于

由于这个答案是第一次写的,所以出现了一个更好的方式将war文件部署到tomcat中,并且零宕机。在最新版本的tomcat中,你可以在你的war文件名中包含版本号。因此,例如,您可以同时部署文件ROOT##001.warROOT##002.war相同的上下文。之后的所有内容##被tomcat解释为版本号,而不是上下文路径的一部分。Tomcat将保持您的应用程序的所有版本运行,并将新的请求和会话提供给最新的版本,同时完美地完成旧版请求和会话。指定版本号也可以通过tomcat管理器甚至catalina ant任务完成。更多信息在这里

Rsync往往对压缩文件无效,因为它是增量传输算法查找文件中的变化,并且稍微更改未压缩的文件,可以彻底改变最终的压缩版本。出于这个原因,如果网络带宽证明是瓶颈,那么rsync可能是非常有意义的rsync一个未压缩的war文件而不是一个压缩版本。

使用Tomcat管理器应用程序执行部署有什么问题?如果您不想将整个war文件直接从远程位置上传到Tomcat管理器应用程序,则可以将其(未按上述原因压缩)rsync同步到生产箱上的占位符位置,重新打包为一场战争,以及然后把它交给经理本地。Tomcat附带的一个很好的ant任务允许您使用Tomcat管理器应用程序对脚本进行脚本编写。

你没有提到的方法还有一个缺陷:当你的应用程序部分部署时(在rsync操作期间),你的应用程序可能处于一个不一致的状态,即更改后的接口可能不同步,新的/更新的依赖关系可能会不可用等。另外,根据您的rsync作业需要多长时间,您的应用程序可能实际上会重新启动多次。您是否知道您可以并应该关闭Tomcat中的侦听更改文件和重新启动行为?实际上不推荐用于生产系统。您始终可以使用Tomcat管理器应用程序手动或通过脚本重新启动应用程序。

当然,您的应用程序在重新启动时将不可用。但是,如果您对可用性非常关注,那么负载平衡器后面肯定会有冗余Web服务器。在部署更新的war文件时,您可以暂时让负载平衡器将所有请求发送到其他web服务器,直到部署结束。冲洗并重复您的其他Web服务器。

扫码关注云+社区