用最少的停机时间部署Java webapps的最佳实践？
用最少的停机时间部署Java webapps的最佳实践？
提问于 2018-03-23 05:23:37
部署大型Java Web应用程序（> 100 MB .war）时，我正在使用以下部署过程：
- 应用程序.war文件在开发机器上进行本地扩展。
- 扩展的应用程序是从开发机器到实时环境的rsync：ed。
- 实时环境中的应用服务器在rsync之后重新启动。这一步并不是严格需要的，但我发现在部署时重新启动应用程序服务器可以避免由于频繁的类加载而导致“java.lang.OutOfMemoryError：PermGen空间”。
这种方法的好处：
- rsync最大限度地减少了从开发机器发送到现场环境的数据量。上传整个.war文件需要10分钟以上，而rsync需要几秒钟的时间。
这种方法的坏处：
- 当rsync运行时，应用程序上下文会在文件更新后重新启动。理想情况下，重启应该在rsync完成之后发生，而不是在它仍在运行时发生。
- 应用程序服务器重新启动导致大约两分钟的停机时间。
我想找到一个具有以下属性的部署过程：
- 部署过程中停机时间最短。
- 花费最少的时间上传数据。
- 如果部署过程是特定于应用服务器的，那么应用服务器必须是开源的。
题：
- 鉴于所述的要求，什么是最佳部署过程？
Stack Overflow用户
发布于 2018-03-23 13:41:36
已经注意到，在将更改推送到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。
页面原文内容由Stack Overflow提供。腾讯云小微IT领域专用引擎提供翻译支持
原文链接：
https://stackoverflow.com/questions/-100007755
复制相关文章
相似问题