java - 以最少的停机时间部署 Java webapps 的最佳实践？

Question

在部署大型 Java webapp (>100 MB .war) 时，我目前使用以下部署过程:

• 应用程序 .war 文件在开发机器上本地展开。
• 扩展的应用程序从开发机器rsync:ed到实时环境。
• 实时环境中的应用服务器在 rsync 后重启。这一步不是必须的，但我发现在部署时重新启动应用程序服务器可以避免由于频繁加载类而出现“java.lang.OutOfMemoryError: PermGen space”。

这种方法的好处:

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

这种方法的坏处:

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

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

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

问题:

• 鉴于所述要求，最佳部署流程是什么？

Answer 1

更新:

自从第一次编写此答案以来，已经出现了一种更好的方法来将 war 文件部署到 tomcat 并且零停机时间。在最新版本的 tomcat 中，您可以在您的 war 文件名中包含版本号。例如，您可以将文件 ROOT##001.war 和 ROOT##002.war 同时部署到相同的上下文中。 ## 之后的所有内容都被 tomcat 解释为版本号，而不是上下文路径的一部分。 Tomcat 将使您的应用程序的所有版本保持运行，并为完全启动的最新版本提供新的请求和 session ，同时在它们开始的版本上优雅地完成旧请求和 session 。指定版本号也可以通过 tomcat 管理器甚至 catalina ant 任务来完成。更多信息 here .

原答案:

Rsync 对压缩文件往往无效，因为它的增量传输算法会查找文件中的更改，而未压缩文件的微小更改可能会极大地改变生成的压缩版本。因此，如果网络带宽被证明是一个瓶颈，那么 rsync 未压缩的 war 文件而不是压缩版本可能更有意义。

使用 Tomcat 管理器应用程序进行部署有什么问题？如果您不想将整个 war 文件从远程位置直接上传到 Tomcat 管理器应用程序，您可以将其 rsync(由于上述原因未压缩)到生产盒上的占位符位置，将其重新打包到 war 中，然后然后交给本地的经理。 Tomcat 附带了一个不错的 ant 任务，允许您使用 Tomcat 管理器应用程序编写部署脚本。

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

当然，在重新启动期间，用户将无法使用您的应用程序。但是，如果您非常关心可用性，那么您肯定在负载均衡器后面有冗余的 Web 服务器。部署更新的 war 文件时，您可以暂时让负载均衡器将所有请求发送到其他 Web 服务器，直到部署结束。冲洗并重复您的其他网络服务器。