用最少的停机时间部署Java webapps的最佳实践？ [英] Best practices for deploying Java webapps with minimal downtime?

问题描述

在部署大型Java Web应用程序（> 100 MB .war）时，我正在使用以下部署过程：

• 应用程序.war文件在开发机器上进行本地扩展。
  
• 扩展的应用程序是从开发机器到实时环境的rsync：ed。


• 实时环境中的应用程序服务器在rsync之后重新启动。这一步并非严格需要，但我发现在部署时重新启动应用程序服务器可避免由于频繁的类加载而导致java.lang.OutOfMemoryError：PermGen space。

这种方法的好处是：

• rsync将从开发机器发送到生活环境。上传整个.war文件需要10分钟以上，而rsync需要几秒钟。 / p>
  
  
  
  
  • 当rsync运行时，应用程序上下文会在文件更新后重新启动。理想情况下，重新启动应在rsync完成后进行，而不是在仍在运行时进行。
  
  
  • 应用程序服务器重新启动会造成大约两分钟的停机时间。 ul>
    
    

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

    
    
    • 最小在部署过程中停机。
    
    
    • 上传数据的最少时间。
    
    
    • 如果部署过程是特定于应用服务器的，则应用服务器必须处于打开状态
      
      
      

      问题：
      
      

      
      
      • 给定的要求，什么是最佳的部署过程？
      有人指出，在推送对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 。

      
      

      When deploying a large Java webapp (>100 MB .war) I'm currently use the following deployment process:

      • The application .war file is expanded locally on the development machine.
      • The expanded application is rsync:ed from the development machine to the live environment.
      • The app server in the live environment is restarted after the rsync. This step is not strictly needed, but I've found that restarting the application server on deployment avoids "java.lang.OutOfMemoryError: PermGen space" due to frequent class loading.

      Good things about this approach:

      • The rsync minimizes the amount of data sent from the development machine to the live environment. Uploading the entire .war file takes over ten minutes, whereas an rsync takes a couple of seconds.

      Bad things about this approach:

      • While the rsync is running the application context is restarted since the files are updated. Ideally the restart should happen after the rsync is complete, not when it is still running.
      • The app server restart causes roughly two minutes of downtime.

      I'd like to find a deployment process with the following properties:

      • Minimal downtime during deployment process.
      • Minimal time spent uploading the data.
      • If the deployment process is app server specific, then the app server must be open-source.

      Question:

      • Given the stated requirements, what is the optimal deployment process?

      解决方案

      It has been noted that rsync does not work well when pushing changes to a WAR file. The reason for this is that WAR files are essentially ZIP files, and by default are created with compressed member files. Small changes to the member files (before compression) result in large scale differences in the ZIP file, rendering rsync's delta-transfer algorithm ineffective.

      One possible solution is to use jar -0 ... to create the original WAR file. The -0 option tells the jar command to not compress the member files when creating the WAR file. Then, when rsync compares the old and new versions of the WAR file, the delta-transfer algorithm should be able to create small diffs. Then arrange that rsync sends the diffs (or original files) in compressed form; e.g. use rsync -z ... or a compressed data stream / transport underneath.

      EDIT: Depending on how the WAR file is structured, it may also be necessary to use jar -0 ... to create component JAR files. This would apply to JAR files that are frequently subject to change (or that are simply rebuilt), rather than to stable 3rd party JAR files.

      In theory, this procedure should give a significant improvement over sending regular WAR files. In practice I have not tried this, so I cannot promise that it will work.

      The downside is that the deployed WAR file will be significantly bigger. This may result in longer webapp startup times, though I suspect that the effect would be marginal.

      ---

      A different approach entirely would be to look at your WAR file to see if you can identify library JARs that are likely to (almost) never change. Take these JARs out of the WAR file, and deploy them separately into the Tomcat server's common/lib directory; e.g. using rsync.

      这篇关于用最少的停机时间部署Java webapps的最佳实践？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！