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 应用每天都要去做的事情,我们希望这件事能变得美好一些。”
评论