构建可扩展的Java EE应用（二） - 编程入门网

构建可扩展的Java EE应用（二）

当并发用户数明显的开始增长，你可能会不满意一台机器所能提供的性能，或 者由于单个JVM实例gc的限制，你没法扩展你的java应用，在这样的情况下你可以 做的另外的选择是在多个JVM实例或多台服务器上运行你的系统，我们把这种方法 称为水平扩展。

请注意，我们相信能够在一台机器的多个JVM上运行系统的扩展方式是水平扩 展方式，而非垂直扩展方式。JVM实例之间的IPC机制是有限的，两个JVM实例之间 无法通过管道、共享内存、信号量或指令来进行通讯，不同的JVM进程之间最有效 的通讯方式是socket。简而言之，如果Java EE应用如果扩展到多个JVM实例中运 行，那么大多数情况下它也可以扩展到多台服务器上运行。

随着计算机越来越便宜，性能越来越高，通过将低成本的机器群组装为集群可 以获得超过那些昂贵的超级计算机所具备的计算能力。不过，大量的计算机也意 味着增加了管理的复杂性以及更为复杂的编程模型，就像服务器节点之间的吞吐 量和延时等问题。

Java EE集群是一种成熟的技术，我在TSS上写了一篇名为“Uncover the Hood of J2EE Clustering”的文章来描述它的内部机制。

从失败的项目中吸取的教训

采用无共享的集群架构（SNA）

Figure 3: share nothing cluster

最具备扩展性的架构当属无共享的集群架构。在这样的集群中，每个节点具备 完全相同的功能，并且不需要知道其他节点存在与否。负载均衡器(Load Balancer)来完成如何将请求分发给这些后台的服务器实例。由于负载均衡器只是 做一些简单的工作，例如分派请求、健康检查和保持session，因此负载均衡器很 少会成为瓶颈。如果后端的数据库系统或其他的信息系统足够的强大，那么通过 增加更多的节点，集群的计算能力可以得到线性的增长。

几乎所有的Java EE提供商在他们的集群产品中都实现了HttpSession的 failover功能，这样即使在某些服务器节点不可用的情况下也仍然能够保证客户 端的请求中的session信息不丢失，但这点其实是打破了无共享原则的。为了实现 failover，同样的session数据将会被两个或多个节点共享，在我之前的文章中， 我曾经推荐除非是万不得已，不要使用session failover。就像我文章中提到的 ，当失败发生时，session failover功能并不能完全避免错误，而且同时还会对 性能和可扩展性带来损失。

使用可扩展的session复制机制

为了让用户获得更友好的体验，有些时候可能必须使用session failover功能 ，这里最重要的在于选择可扩展的复制型产品或机制。不同的厂商会提供不同的 复制方案 - 有些采用数据库持久，有些采用中央集中的状态服务器，而有些则采 用节点间内存复制的方式。最具可扩展性的是成对节点的复制(paired node replication)，这也是现在大部分厂商采用的方案，包括BEA Weblogic、JBoss和 IBM Websphere，Sun在Glassfish V2以及以上版本也实现了成对节点的复制。最 不可取的方案是数据库持久session的方式。在我们实验室中曾经测试过一个采用 数据库持久来实现 session复制的项目，测试结果表明如果session对象频繁更新 的话，节点在三到四个时就会导致数据库崩溃。

构建可扩展的Java EE应用（二）(2)

采用collocated部署方式来取代分布式

Java EE技术，尤其是EJB，天生就是用来做分布式计算的。解耦业务功能和重 用远程的组件使得多层的应用模型得以流行。但对于可扩展性而言，减少分布式 的层次可能是一个好的选择。

在我们实验室曾经以一个政府的项目测试过这两种方式在同样的服务器数量上 的部署 - 一种是分布式的，一种是collocated方式的，如下图所示：

Figure 4: distributed s

凌众科技专业提供服务器租用、服务器托管、企业邮局、虚拟主机等服务，公司网站：http://www.lingzhong.cn 为了给广大客户了解更多的技术信息，本技术文章收集来源于网络,凌众科技尊重文章作者的版权，如果有涉及你的版权有必要删除你的文章，请和我们联系。以上信息与文章正文是不可分割的一部分,如果您要转载本文章,请保留以上信息，谢谢!