LiveRebel 1.0：更新生产环境里的应用时，不用再停止服务了

ZeroTurnaround的LiveRebel 1.0旨在服务器部署自动化的过程中缩短服务停止的时间、减少会话丢失的个数。据ZeroTurnaround的CTO Jevgeni Kabanov说，大部分应用都要在非高峰时段停止服务进行更新。那些一次只能处理一个服务器的工作人员会非常痛苦。这些工作基本上没有工具支持，流程只有部分进行了脚本化，主要还得靠人工完成。InfoQ有幸对ZeroTurnaround进行了采访。

InfoQ：客户目前使用LiveRebel进行部署，能提供一些有关复杂性/规模的详细信息么？

这里说的部署都还在测试，部署的规模大多比较小，不过一些生产环境的部署很快就会超过一百个服务器。

InfoQ：LiveRebel主要关注单节点应用（WAR、EAR、JAR），还是可以处理更复杂的多节点部署？

我们可以处理各种类型的部署，包括规模极大的集群，甚至是弹性云部署。

InfoQ：什么情况下LiveRebel会优于比较传统的可用方式？比如一次只更新集群里的一个服务器。

从概念上讲，原因有：

• 每次只重启一个服务器会花费很长时间，很小的变化也会变得很昂贵。
• 应用的状态结构只要有变化，会话迁移就会失败。应用如果一直处于活动状态，那会话就能永远维持下去。
• 数据库结构或远程API要是有任何变化，应用的新旧版本就可能不兼容了，这种情况下新旧版本也不能同时运行。

InfoQ：以后的版本会有哪些值得期待的内容？

LiveRebel 1.0非常简单。不久的将来我们会添加：

• Hudson/Jenkins插件，
• 状态变化（比如添加一个属性）的自动处理机制和手动处理机制，
• 数据库更新集成，也会集成一些应用生命周期管理产品。

从长远来说，我们打算修复多个比较严重的缺陷，这些缺陷都是我们在现有的应用生命周期管理产品中发现的。

LiveRebel 1.0包括的功能有：

• 完全脚本化的服务器和Web控制台，控制台可以管理任意规模的Java EE应用，这些应用可以在单节点上，也可以在集群里或云中。
• 对每个类和资源都进行单独的版本化，而不是重新装载整个应用，从而避免与容器重部署和滚动升级相关的问题。
• 推出对用户不透明的即时更新。代码就地更新，保留所有已有的状态。
• 在节点上使用纯Java的JVM插件（-javaagent），这会带来3-5%的性能开销。

但这个版本也有一些局限。虽然LiveRebel能处理所有资源的变更，但它不能：

• 替换超类
• 实现新接口
• 处理没有liverebel.xml文件的JAR的变更（在更新第三方JAR包和支持库的时候最有可能遇到）

此外，由于LiveRebel不能创建新的状态，以下几类更改可能会有一些讨厌的副作用：

• 添加新的实例属性或重命名现有的实例属性时，现有的对象会把这个实例属性初始化为null
• 更改过的构造函数只对更新后才创建的对象生效
• 一般来说，各种初始化程序的变化对现有对象都没有影响

ZeroTurnaround最近进行了一项调查，证实了对LiveRebel的需求。调查指出，服务器部署自动化是特性功能，而不是规范要求的（特别是对有2-50个服务器实例的生产环境来说，大部分被调查者都处于这种生产环境下），大家也能接受停止服务和丢失会话的做法， ZeroTurnaround希望能有所改变：“在依赖关系不那么稳固的环境里迁移用户、应用和数据库状态是更新Java应用每天都要去做的事情，我们希望这件事能变得美好一些。”

查看英文原文：LiveRebel 1.0: No-Downtime Production Updates