接着前面的写。上文主要写了
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
各有优劣，适合不同的需要，下面进行些比较：
Ø
从应用部署上看：
A
使用了
websphere
集群，由一个
DeployManager
进行分发，部署应用，只需部署一次，由
DM
分发到几个节点上。而
B
每个
server
都是独立的，部署应用只能一台台部署，如果
server
较少差别还不明显，如果达到
10
台以上，一台台部署将是一个比较痛苦的事情。
Ø
从
session
上看：
A
使用了
websphere
集群，可以使用集群提供的
session
复制，对于一些关键应用（某台服务器宕机，
session
也必须保持的应用）很有必要。而对于一些能够允许
session
丢失的应用，才可以使用
B
。当然
A
也可以关闭
session
复制，因为
session
复制不管是使用数据库方式还是内存方式，总会消耗一定的性能。具体消耗多少性能，就要看不同的
application server
的
session
复制方案了，想深入了解，可以看集群方面的文档，我也只记得一个比较简单的
round robbin
了。
Ø
从架构复杂性看：
B
更为简单，因为没有
DM
的概念，每台
server
都保持独立。而使用了
DM
有时也会出现莫名奇妙的问题，这当然是由于不了解
DM
的机制所致，但总归也增加了复杂度，这点在后面的教训中进行说明。
Ø
从水平扩展性上看：
B
肯定更胜一筹。只要
F5
能支持，多少台
server
都没关系。而
A
多台
server
做集群，要看
websphere
支持的节点数量，应该不会太大。这个如果哪位同学知道，敬请告知。
当然
A
和
B
在服务器较多的情况下是可以共存的，可以考虑几台机器做集群，然后集群间做负载均衡，这样既可以减少部署的复杂度，又可以带来较好的水平扩展。由于没做过更大型的项目，这个也只是我的假象，请做过的同学斧正。
说一说集群中碰到的问题。
Ø
首先是对各节点的同步：
有时为了方便测试，我们只对其中一个节点进行更改，测试通过再放到其它节点。而如果测试周期较长，有时就会造成节点的不同步，出现各种各样莫名其妙的问题。一个经验就是：无论如何，在每天下班前要保证各节点的同步，不同步的现象不要过夜。
Ø
然后是对
DM
的理解：
我现在还只是实践阶段，没有看过相关文档。从意义上看，它控制了相关的配置文件，如果进行节点同步，就会由它把配置文件同步到它管理的节点上。这对配置文件的修改提出了要求。我们开始只修改节点的配置文件而没有修改
DM
的，结果进行节点同步就会覆盖修改的配置文件，带来很多不必要的工作。经验就是：或者修改
DM
的配置文件，然后进行节点同步，或者直接同时修改所有节点和
DM
的。
Ø
还有关于
cache
的：
Cache
是性能优化的一个有效手段。在单机环境下，最简单的就是内存
cache
，使用
static
的
Map
就行。而在集群环境中，
cache
就变的比较复杂了。首先还是从应用需求入手，是否要保持每台机器的
cache
同步。如果只是信息展示等要求不高的
cache
，不需保证
cache
的同步，问题也比较简单，自己写内存
cache
，或者使用开源的
cache
组件如
ehcache,oscache
等就可以很好的解决问题。而如果需要
cache
在几个节点保持同步，就需要特殊的机制了，
ehcache
等号称支持分布式
cache
，但好像需要
jgroup
，配置比较麻烦，我没有用过，有用过的同学请指教。我本来想使用
session
保存，然后进行
session
同步，后来
IBM
建议使用数据库
cache
，即自己写代码，
cache
在数据库中。这样不需要
session
同步，对象不大，性能也能得到保证，现在用下来效果还可以。