我听说这就是 JavaRebel 所做的,但有没有其他好的方法来部署新版本的 EAR,同时允许用户在以前的版本上保持活动状态?我们使用 JBoss 作为应用程序服务器...
4 回答
这不是 JavaRebel 所做的。JavaRebel(根据描述)热替换内存中的类。在现有系统连接的情况下这是不可接受的,因为更新的类可能会破坏客户端的逻辑。
曾经我工作的一家公司也遇到过类似的问题,然后就这样解决了:
- 智能路由器被用作负载平衡器
- 新版本已部署到(新)集群的 50% 的节点
- 新连接被严格传送到这些更新的节点,旧节点在旧节点之间平衡
- 旧节点脱机(一个接一个,以使每个节点的客户端数量保持在限制范围内)
- 同时,新版本被部署到离线的“旧”节点,并作为新节点启动
- 由于 EJB 集群,会话和 bean 被其他旧节点拾取
- 最终(几个小时后),只剩下一个旧节点,只有一个旧版本实例,所有使用旧版本的客户端都连接到它
- 当最后一个旧客户端断开连接时,该节点也被关闭
现在,我不是网络人,不能给你很多细节(比如什么是路由器硬件等等)。我的理解这可以很容易地设置,除了,如果我没记错的话,我们必须设置一个额外的 Weblogic 域来部署应用程序的新版本(否则它将与 JNDI 名称上的旧版本冲突)。
希望有帮助。
PS Ichorus 提供了一条评论,称该应用程序部署在客户端的服务器上。所以路由器技巧可能不可行。现在,我现在只看到一个可行的解决方案(现在是 21:52,我可能会忽略一些事情 :))——
- 使用“版本化”的 JNDI 名称开发新版本;例如,如果客户 bean 在版本 1 中位于 ejb/Customer 下,那么在版本 2 中它将位于 ejb/Customer2 下
- 在应用程序中有一个具有稳定基本接口(工厂风格)的业务外观,当被要求提供 Customer bean 时,它会尝试找到最高版本的 JNDI 名称(当然,不是在每次调用时都可以缓存一个小时左右)。该外观可以(并且应该)部署为一个单独的应用程序——并且永远不会或很少更新
- 现在每个新客户端都可以访问最新部署的应用程序,并且应用程序不会发生冲突。
这种方法需要仔细规划和测试,但恕我直言。
我最近以类似的方式修改了一些应用程序,让它们在同一个域中共存(在它们对不同的数据源使用相同的 JNDI 名称之前)。
据我了解,WebLogic 有一个称为并行部署的功能,可以消除 EAR 版本升级期间的停机时间。您可以在不停止现有应用程序的情况下部署新版本,并且一旦成功部署新版本,您就可以透明地从旧版本切换到新版本。
我不确定其他应用程序服务器是否支持这一点。
参考:http://edocs.bea.com/wls/docs100/deployment/redeploy.html#wp1022490
Vladimir 关于使用负载均衡器的建议是实现您想要的非常可靠的方法。请记住,它不一定是高端硬件负载均衡器。相反,如果您在 JBoss 服务器前面使用本地 Web 服务器(Apache 或 IIS)和 mod_jk 或 mod_proxy,您可以维护一个通用的 Web 外观并在 EAR 升级时实现适用的加载和路由例程。
//尼古拉斯
我认为您可能想使用 OSGI 框架研究 Spring。 http://www.springframework.org/osgi