将运行在产品环境中的应用更新到新版本并非易事。更新应该将对已连接用户的影响降到最低,同时如果更新不成功,那么应该可以轻松地回退到之前的版本。运行在多个服务器(比如说集群)上的应用使得更新过程变得更加复杂。通常来说,该特性是由应用服务器厂商以一种私有解决方案的形式提供的。在 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
评论