接著前面的寫。上文主要寫了
ajax
在
portal
中的使用，這篇寫集群方面的體會(huì)。現(xiàn)在比較流行的架構(gòu)就是前端
F5
做負(fù)載均衡，后面
2
臺(tái)
websphere server
做成集群，各自都有
HttpServer
，每個(gè)
HttpServer
都向
2
臺(tái)
was
做轉(zhuǎn)發(fā)。這樣每臺(tái)都能獨(dú)立完成從
HttpServer
到
was
的流程。一臺(tái)出現(xiàn)故障，
F5
首先進(jìn)行切換，只向正常
server
的
HttpServer
發(fā)起請(qǐng)求，這臺(tái)
HttpServer
再進(jìn)行切換只向同一臺(tái)
server
上的
was
做轉(zhuǎn)發(fā)。這次
portal
就是采用的這種架構(gòu)，不妨稱為架構(gòu)
A
。
另一種簡(jiǎn)單點(diǎn)的架構(gòu)就是只做
F5
負(fù)載均衡，不做
was
集群，每臺(tái)
websphere server
上的
HttpServer
接受
F5
轉(zhuǎn)發(fā)的請(qǐng)求，只向本
server
的
was
轉(zhuǎn)發(fā)。這樣每臺(tái)
websphere server
保持獨(dú)立，相互間沒有數(shù)據(jù)交換和轉(zhuǎn)發(fā)。不妨稱為架構(gòu)
B
。
架構(gòu)
A
和
B
各有優(yōu)劣，適合不同的需要，下面進(jìn)行些比較：
?????????
從應(yīng)用部署上看：
A
使用了
websphere
集群，由一個(gè)
DeployManager
進(jìn)行分發(fā)，部署應(yīng)用，只需部署一次，由
DM
分發(fā)到幾個(gè)節(jié)點(diǎn)上。而
B
每個(gè)
server
都是獨(dú)立的，部署應(yīng)用只能一臺(tái)臺(tái)部署，如果
server
較少差別還不明顯，如果達(dá)到
10
臺(tái)以上，一臺(tái)臺(tái)部署將是一個(gè)比較痛苦的事情。
?????????
從
session
上看：
A
使用了
websphere
集群，可以使用集群提供的
session
復(fù)制，對(duì)于一些關(guān)鍵應(yīng)用（某臺(tái)服務(wù)器宕機(jī)，
session
也必須保持的應(yīng)用）很有必要。而對(duì)于一些能夠允許
session
丟失的應(yīng)用，才可以使用
B
。當(dāng)然
A
也可以關(guān)閉
session
復(fù)制，因?yàn)?/span>
session
復(fù)制不管是使用數(shù)據(jù)庫(kù)方式還是內(nèi)存方式，總會(huì)消耗一定的性能。具體消耗多少性能，就要看不同的
application server
的
session
復(fù)制方案了，想深入了解，可以看集群方面的文檔，我也只記得一個(gè)比較簡(jiǎn)單的
round robbin
了。
?????????
從架構(gòu)復(fù)雜性看：
B
更為簡(jiǎn)單，因?yàn)闆]有
DM
的概念，每臺(tái)
server
都保持獨(dú)立。而使用了
DM
有時(shí)也會(huì)出現(xiàn)莫名奇妙的問題，這當(dāng)然是由于不了解
DM
的機(jī)制所致，但總歸也增加了復(fù)雜度，這點(diǎn)在后面的教訓(xùn)中進(jìn)行說明。
?????????
從水平擴(kuò)展性上看：
B
肯定更勝一籌。只要
F5
能支持，多少臺(tái)
server
都沒關(guān)系。而
A
多臺(tái)
server
做集群，要看
websphere
支持的節(jié)點(diǎn)數(shù)量，應(yīng)該不會(huì)太大。這個(gè)如果哪位同學(xué)知道，敬請(qǐng)告知。
當(dāng)然
A
和
B
在服務(wù)器較多的情況下是可以共存的，可以考慮幾臺(tái)機(jī)器做集群，然后集群間做負(fù)載均衡，這樣既可以減少部署的復(fù)雜度，又可以帶來較好的水平擴(kuò)展。由于沒做過更大型的項(xiàng)目，這個(gè)也只是我的假象，請(qǐng)做過的同學(xué)斧正。
?
說一說集群中碰到的問題。
?????????
首先是對(duì)各節(jié)點(diǎn)的同步：
有時(shí)為了方便測(cè)試，我們只對(duì)其中一個(gè)節(jié)點(diǎn)進(jìn)行更改，測(cè)試通過再放到其它節(jié)點(diǎn)。而如果測(cè)試周期較長(zhǎng)，有時(shí)就會(huì)造成節(jié)點(diǎn)的不同步，出現(xiàn)各種各樣莫名其妙的問題。一個(gè)經(jīng)驗(yàn)就是：無論如何，在每天下班前要保證各節(jié)點(diǎn)的同步，不同步的現(xiàn)象不要過夜。
?????????
然后是對(duì)
DM
的理解：
我現(xiàn)在還只是實(shí)踐階段，沒有看過相關(guān)文檔。從意義上看，它控制了相關(guān)的配置文件，如果進(jìn)行節(jié)點(diǎn)同步，就會(huì)由它把配置文件同步到它管理的節(jié)點(diǎn)上。這對(duì)配置文件的修改提出了要求。我們開始只修改節(jié)點(diǎn)的配置文件而沒有修改
DM
的，結(jié)果進(jìn)行節(jié)點(diǎn)同步就會(huì)覆蓋修改的配置文件，帶來很多不必要的工作。經(jīng)驗(yàn)就是：或者修改
DM
的配置文件，然后進(jìn)行節(jié)點(diǎn)同步，或者直接同時(shí)修改所有節(jié)點(diǎn)和
DM
的。
?????????
還有關(guān)于
cache
的：
Cache
是性能優(yōu)化的一個(gè)有效手段。在單機(jī)環(huán)境下，最簡(jiǎn)單的就是內(nèi)存
cache
，使用
static
的
Map
就行。而在集群環(huán)境中，
cache
就變的比較復(fù)雜了。首先還是從應(yīng)用需求入手，是否要保持每臺(tái)機(jī)器的
cache
同步。如果只是信息展示等要求不高的
cache
，不需保證
cache
的同步，問題也比較簡(jiǎn)單，自己寫內(nèi)存
cache
，或者使用開源的
cache
組件如
ehcache,oscache
等就可以很好的解決問題。而如果需要
cache
在幾個(gè)節(jié)點(diǎn)保持同步，就需要特殊的機(jī)制了，
ehcache
等號(hào)稱支持分布式
cache
，但好像需要
jgroup
，配置比較麻煩，我沒有用過，有用過的同學(xué)請(qǐng)指教。我本來想使用
session
保存，然后進(jìn)行
session
同步，后來
IBM
建議使用數(shù)據(jù)庫(kù)
cache
，即自己寫代碼，
cache
在數(shù)據(jù)庫(kù)中。這樣不需要
session
同步，對(duì)象不大，性能也能得到保證，現(xiàn)在用下來效果還可以。
?