结合经验浅谈J2EE Cluster下的开发

通常来讲，一个相对大型的J2EE系统，都会采用如下这种Cluster的架构，

 

 Load Balancer －Web Server 1，2 －App Server 1，2

 

而其中Web Server 1，Web Server 2交叉链接App Server1，App Server 2叫作Active/Active Mode；Web Server 1直连App Server1，Web Server 2直连App Serer2，叫作Active/Standby Mode。

 

Cluster的好处这里就不提了，这里想谈谈Cluster的Limitation。

 

1. Failover并不能彻底避免错误。咱们指望的是，一个Request过来，假如接受请求的App Server Down了，请求可以无缝的链接到另外一台App Server去，没错，理论上应当如此。可是请注意Failover自己有其前提条件，“在方法调用之间”。而大多数的状况是，Client端会直接收到错误信息，除非这个方法是“幂等”的，例如Listing，Display，只有在这种状况下，某些足够聪明的Load Balancer才会将Failover转移到另外一个Instance上面。

 

2. 你可能会认为在一个Transaction中的全部方法都应该是幂等的，由于当请求失败时，Transaction会Rollback，对系统状态所作的改变所有会撤销，但实际的状况是，Transaction的界限极可能没法包含全部的RMI Call的边界。

 

3. 在Cluster的环境中，HTTP Session的使用有不少的限制，最重要的一点是Session中的Object必须是Serializable的。可是一些Design Pattern或者MVC Framework会在HTTP Session中存储一些UnSerializable的Object，如Servlet上下文，Web Service的引用等等，这种设计在Cluster下是没法正常工做的。所以，并非全部的Standalone Application可以透明的迁移到Cluster中来的。

 

4. 静态变量的使用要很是当心。传统的Design Pattern “Singleton”会使用静态变量来实现对多个Object之间的状态共享，这个在Cluster中是彻底失效的，由于Cluster中的每一个Server Instance都会有本身的一个JVM，这样打破了这个Design Pattern的机制。固然，必定要使用这个模式生效，能够考虑用DB来保存状态。

 

5. 交叉Mode比直连Mode更灵活？非也。大多数的的Server都是Web Container和EJB Container在同一个JVM Instance中运行的，让EJB Container处理来自其余Server的Web Container的Request不见得比处理本身Web Container的Request来得高效。若是EJB Container所在的Server Down了，Web Container也基本上Down了，交叉Mode没有提升可用性。交叉Mode有可能会致使Performance的低下，由于容易产生没必要要的，跨Server的交互，若是方法中有Transaction，那么Transaction的边界就要包含多个Server Instance。

 

6. 实际上，不少厂商包括JES，Weblogic，JBoss等等，对于EJB的Load Balancer都作了优化，优先选择在同一个Server Instance上的EJB。这就成了Active/Standby，也就是直连Mode了。