这次做portal的一些总结（二）

接着前面的写。上文主要写了 ajax 在 portal 中的使用，这篇写集群方面的体会。现在比较流行的架构就是前端 F5 做负载均衡，后面 2 台 websphere server 做成集群，各自都有 HttpServer ，每个 HttpServer 都向 2 台 was 做转发。这样每台都能独立完成从 HttpServer 到 was 的流程。一台出现故障， F5 首先进行切换，只向正常 server 的 HttpServer 发起请求，这台 HttpServer 再进行切换只向同一台 server 上的 was 做转发。这次 portal 就是采用的这种架构，不妨称为架构 A 。

另一种简单点的架构就是只做 F5 负载均衡，不做 was 集群，每台 websphere server 上的 HttpServer 接受 F5 转发的请求，只向本 server 的 was 转发。这样每台 websphere server 保持独立，相互间没有数据交换和转发。不妨称为架构 B 。

架构 A 和 B 各有优劣，适合不同的需要，下面进行些比较：

Ø         从应用部署上看： <!----> <o:p> </o:p>

A 使用了 websphere 集群，由一个 DeployManager 进行分发，部署应用，只需部署一次，由 DM 分发到几个节点上。而 B 每个 server 都是独立的，部署应用只能一台台部署，如果 server 较少差别还不明显，如果达到 10 台以上，一台台部署将是一个比较痛苦的事情。

Ø         从 session 上看： <o:p> </o:p>

A 使用了 websphere 集群，可以使用集群提供的 session 复制，对于一些关键应用（某台服务器宕机， session 也必须保持的应用）很有必要。而对于一些能够允许 session 丢失的应用，才可以使用 B 。当然 A 也可以关闭 session 复制，因为 session 复制不管是使用数据库方式还是内存方式，总会消耗一定的性能。具体消耗多少性能，就要看不同的 application server 的 session 复制方案了，想深入了解，可以看集群方面的文档，我也只记得一个比较简单的 round robbin 了。

Ø         从架构复杂性看： <o:p> </o:p>

B 更为简单，因为没有 DM 的概念，每台 server 都保持独立。而使用了 DM 有时也会出现莫名奇妙的问题，这当然是由于不了解 DM 的机制所致，但总归也增加了复杂度，这点在后面的教训中进行说明。

Ø         从水平扩展性上看： <o:p> </o:p>

B 肯定更胜一筹。只要 F5 能支持，多少台 server 都没关系。而 A 多台 server 做集群，要看 websphere 支持的节点数量，应该不会太大。这个如果哪位同学知道，敬请告知。

当然 A 和 B 在服务器较多的情况下是可以共存的，可以考虑几台机器做集群，然后集群间做负载均衡，这样既可以减少部署的复杂度，又可以带来较好的水平扩展。由于没做过更大型的项目，这个也只是我的假象，请做过的同学斧正。

<o:p> </o:p>

说一说集群中碰到的问题。

Ø         首先是对各节点的同步： <o:p> </o:p>

有时为了方便测试，我们只对其中一个节点进行更改，测试通过再放到其它节点。而如果测试周期较长，有时就会造成节点的不同步，出现各种各样莫名其妙的问题。一个经验就是：无论如何，在每天下班前要保证各节点的同步，不同步的现象不要过夜。

Ø         然后是对 DM 的理解： <o:p> </o:p>

我现在还只是实践阶段，没有看过相关文档。从意义上看，它控制了相关的配置文件，如果进行节点同步，就会由它把配置文件同步到它管理的节点上。这对配置文件的修改提出了要求。我们开始只修改节点的配置文件而没有修改 DM 的，结果进行节点同步就会覆盖修改的配置文件，带来很多不必要的工作。经验就是：或者修改 DM 的配置文件，然后进行节点同步，或者直接同时修改所有节点和 DM 的。 <o:p> </o:p>

Ø         还有关于 cache 的： <o:p> </o:p>

Cache 是性能优化的一个有效手段。在单机环境下，最简单的就是内存 cache ，使用 static 的 Map 就行。而在集群环境中， cache 就变的比较复杂了。首先还是从应用需求入手，是否要保持每台机器的 cache 同步。如果只是信息展示等要求不高的 cache ，不需保证 cache 的同步，问题也比较简单，自己写内存 cache ，或者使用开源的 cache 组件如 ehcache,oscache 等就可以很好的解决问题。而如果需要 cache 在几个节点保持同步，就需要特殊的机制了， ehcache 等号称支持分布式 cache ，但好像需要 jgroup ，配置比较麻烦，我没有用过，有用过的同学请指教。我本来想使用 session 保存，然后进行 session 同步，后来 IBM 建议使用数据库 cache ，即自己写代码， cache 在数据库中。这样不需要 session 同步，对象不大，性能也能得到保证，现在用下来效果还可以。

<o:p> </o:p>