热部署Java EAR以最小化或消除服务器上应用程序的停机时间？ [英] Hot Deploy a Java EAR to Minimize or Eliminate Downtime of an Application on a Server?
问题描述
这不是JavaRebel所做的。 JavaRebel（根据描述）热替换内存中的类。在系统现有连接的情况下，不可接受，因为更新后的类可能会破坏客户的逻辑。
一旦我正在工作的公司遇到类似的问题，这样解决了这个问题：
- 智能路由器被用作负载均衡器
- 新版本被部署到（新）集群的50％的节点中。
- 新连接严格传递到这些更新的节点，旧的节点在旧节点之间进行平衡
- 旧节点脱机（一个接一个地，保持每个节点的客户端数量在限制之内）
- 同时，部署了新版本到离线的旧节点，由于EJB聚类，它们被新建节点
- ，会话和bean由其他旧节点拾取 $ b $最终（在几个小时内），只剩下一个旧节点，具有旧版本的单个实例，所有使用旧版本的客户端都连接到它
- 当最后一个老客户断开连接时，该节点太落后了
现在，我不是网络人，不能给你很多细节（比如路由器硬件等等）。我的理解可以很简单，除非我记得正确，否则我们必须设置一个额外的Weblogic域来部署应用程序的新版本（否则它将与JNDI名称上的旧版本冲突）。
希望有所帮助。
Ichorus提供了一个评论，说该应用程序部署在客户端的服务器上。所以路由器的技巧可能是不可行的。现在，我现在看到只有一个可行的解决方案（现在是21:52，我可能会忽视东西:)） -
- 开发新的版本为版本化的JNDI名称;例如如果Customer bean在版本1中处于ejb / Customer，则在版本2中将处于ejb / Customer2
- 在应用程序中具有稳定的基本界面（Factory-style）的业务外观，当被问到Customer bean时，尝试找到最高版本的JNDI名称（不是每次调用，当然可以缓存一个小时左右）。该立面可以（并且应该）作为一个单独的应用程序部署 - 从来没有或很少更新
- 现在每个新客户端都可以访问部署的最新应用程序，
这种方法需要仔细的规划和测试，但应该运行IMHO。
我最近以类似的方式修改了几个应用程序，让它们在同一个域中共存（在为不同数据源使用相同的JNDI名称之前）。
I have heard that this is what JavaRebel does but is there any other good way to deploy a new version of an EAR while allowing users to remain active on the previous version? We use JBoss for the application server...
It's not what JavaRebel does. JavaRebel (according to description) hot-replaces the classes in memory. It's not acceptable in the case of existing connections to the system, since the updated classes may break the client's logic.
Once a company I was working for had a similar problem, and it was solved this way:
- a smart router was used as a load-balancer
- the new version was deployed to 50% of the nodes of the (new) cluster
- new connections were delivered strictly to these updated nodes, old ones were balanced between old nodes
- old nodes were took off-line (one-by-one, to keep number of clients per node within limits)
- at the same time, new version was deployed to off-line "old" nodes and they were brought up as new nodes
- due to EJB clustering, the sessions and beans were picked up by other old nodes
- eventually (in a few hours), only one old node left, having a single instance of old version and all clients using old version were connected to it
- when the last old client got disconnected, that node was too brought down
Now, I'm not a networking guy, and cannot give you many details (like what was the router hardware and such). My understanding this can be set up pretty easy, except, if I remember right, we had to setup an additional Weblogic domain to deploy new versions of the application (otherwise it would be conflicting with the old one on JNDI names).
Hope that helps.
P.S. Ichorus provided a comment saying that the app is deployed on clients' servers. So the router trick may be not feasible. Now, I see only one viable solution right now ( it's 21:52 now, I may overlook things :) ) --
- Develop new version with "versioned" JNDI names; e.g. if Customer bean was under ejb/Customer in version 1, in version 2 it would be under ejb/Customer2
- Have a business facade in the application with a stable basic interface (Factory-style) which, when asked for Customer bean, tries to find the highest-versioned JNDI name (not on every call, of course, can cache for a hour or so). That facade could (and should) be deployed as a separate application -- and never or very rarely updated
- Now every new client would get access to the latest application deployed, and the applications won't conflict.
This approach takes a careful planning and testing, but should work IMHO.
I recently modified a few applications in a similar way to let them coexist in the same domain (before they used the same JNDI name for different data sources).
这篇关于热部署Java EAR以最小化或消除服务器上应用程序的停机时间？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
