使用 LiveRebel 2.0 更新运行在产品环境中的 Web 应用

将运行在产品环境中的应用更新到新版本并非易事。更新应该将对已连接用户的影响降到最低，同时如果更新不成功，那么应该可以轻松地回退到之前的版本。运行在多个服务器（比如说集群）上的应用使得更新过程变得更加复杂。通常来说，该特性是由应用服务器厂商以一种私有解决方案的形式提供的。在 Apache Tomcat 的最新版中，甚至连它都为这种零时间的停机更新提供了最低的支持。

ZeroTurnaround 提供了 LiveRebel 2.0 ，这是其针对 Java EE 应用在线更新解决方案的下一主版本。虽然 JRebel 用于项目的开发阶段，但 LiveRebel 的目标则是产品部署。LiveRebel 的一个主要特性是它可用于多个应用服务器。这是通过一个特殊的 Java agent （类似于 JRebel 的方式）实现的。目前支持如下环境：

• Tomcat 5、6、7
• Jetty 5、6、7、8
• JBoss 4、5、6
• Oracle Weblogic 9、10
• Oracle application server 9、10
• GlassFish open source 3.x
• WebShere 6、7
• 独立的 Java 应用

一个或多个服务器上分别安装了各自的 agent 后，管理员就可以统一查看所有受管理的服务器，并且可以即时更新运行着的应用。有几种更新策略，如hotpaching（类似于JRebel）或轮询的服务器重启等。LiveRebel 能够确保所有更新都是事务性的（要么全部成功、要么全部失败）并且所有更新都是可逆的。

要想使用LiveRebel，Java 应用还需要一个特殊的 liverebel.xml文件，这是一个内容无法再精简的文件，它持有打包应用的版本号。如果应用是通过 Maven 构建的，那么就能很轻松地在构建阶段集成其生成的内容。

InfoQ 有幸采访到了 ZeroTurnaround 的市场经理 Oliver White 以进一步了解 LiveRebel：

InfoQ：可否将相同的应用部署到不同的服务器上（比如说一个是 GlassFish，另一个是 Tomcat），然后让 LiveRebel 对其进行更新？抑或所有服务器都要是一样的？

不必，服务器不需要是一样的。

InfoQ：LiveRebel 2.0 还为“独立”更新提供了一个选项。这到底是如何做到的呢？这是针对那些没有运行在应用服务器上的应用的么？那么 agent 安装到哪里呢？

没错，这是针对那些通过常规的“main”方法运行的应用的。agent 依旧安装到了 JVM 上，安装过程与使用应用服务器的情形是类似的（你需要通过 LiveRebel 包装器来运行应用）。然而，该模式有一些严重的限制（由于 LiveRebel 并不知晓处理 HTTP 的 socket，因此它无法代理 HTTP 请求），这意味着在更新过程中是没有轮询重启和 socket 暂停的。在该模式下，唯一有用的更新方式就是 Hotpatching 了。

InfoQ：LiveRebel 是否依赖于 JRebel？这意味着新版本的 JRebel 总是会导致新版本的 LiveRebel 出现？

LiveRebel 使用了 JRebel 技术来实现 Hotpatch 更新（作为一种更新策略），但在内部，我们是将其分开的，偶尔通过推 / 拉的方式实现两者间的变更。这种同步并不依赖于 JRebel 的发布计划。

InfoQ：能否向我们的读者介绍一下价格呢？

很遗憾，我们目前还不能披露价格，但不久之后我们的网站就会公布，现在我们只能说只要你有产品部署，那么你就能负担得起其价格。

ZeroTurnaround 现已发布了 2.0.7 版，带有改进的用户界面。要想了解更多信息，请查看文档、 FAQ 以及入门指南。

查看英文原文： Updating Web Applications Running In Production with LiveRebel 2.0