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

EN

已经注意到，在将更改推送到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.war和ROOT##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服务器。