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

构建可扩展的Java EE应用（二）2011-07-08 blogjava BlueDavy当并发用户数明显的开始增长，你可能会不满意一台机器所能提供的性能，或者由于单个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对象频繁更新的话，节点在三到四个时就会导致数据库崩溃。