接著前面的寫。上文主要寫了
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ú)立，相互間沒(méi)有數(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)闆](méi)有
DM
的概念，每臺(tái)
server
都保持獨(dú)立。而使用了
DM
有時(shí)也會(huì)出現(xiàn)莫名奇妙的問(wèn)題，這當(dāng)然是由于不了解
DM
的機(jī)制所致，但總歸也增加了復(fù)雜度，這點(diǎn)在后面的教訓(xùn)中進(jìn)行說(shuō)明。
?????????
從水平擴(kuò)展性上看：
B
肯定更勝一籌。只要
F5
能支持，多少臺(tái)
server
都沒(méi)關(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ù)雜度，又可以帶來(lái)較好的水平擴(kuò)展。由于沒(méi)做過(guò)更大型的項(xiàng)目，這個(gè)也只是我的假象，請(qǐng)做過(guò)的同學(xué)斧正。
?
說(shuō)一說(shuō)集群中碰到的問(wèn)題。
?????????
首先是對(duì)各節(jié)點(diǎn)的同步：
有時(shí)為了方便測(cè)試，我們只對(duì)其中一個(gè)節(jié)點(diǎn)進(jìn)行更改，測(cè)試通過(guò)再放到其它節(jié)點(diǎn)。而如果測(cè)試周期較長(zhǎng)，有時(shí)就會(huì)造成節(jié)點(diǎn)的不同步，出現(xiàn)各種各樣莫名其妙的問(wèn)題。一個(gè)經(jīng)驗(yàn)就是：無(wú)論如何，在每天下班前要保證各節(jié)點(diǎn)的同步，不同步的現(xiàn)象不要過(guò)夜。
?????????
然后是對(duì)
DM
的理解：
我現(xiàn)在還只是實(shí)踐階段，沒(méi)有看過(guò)相關(guān)文檔。從意義上看，它控制了相關(guān)的配置文件，如果進(jìn)行節(jié)點(diǎn)同步，就會(huì)由它把配置文件同步到它管理的節(jié)點(diǎn)上。這對(duì)配置文件的修改提出了要求。我們開(kāi)始只修改節(jié)點(diǎn)的配置文件而沒(méi)有修改
DM
的，結(jié)果進(jìn)行節(jié)點(diǎn)同步就會(huì)覆蓋修改的配置文件，帶來(lái)很多不必要的工作。經(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
的同步，問(wèn)題也比較簡(jiǎn)單，自己寫內(nèi)存
cache
，或者使用開(kāi)源的
cache
組件如
ehcache,oscache
等就可以很好的解決問(wèn)題。而如果需要
cache
在幾個(gè)節(jié)點(diǎn)保持同步，就需要特殊的機(jī)制了，
ehcache
等號(hào)稱支持分布式
cache
，但好像需要
jgroup
，配置比較麻煩，我沒(méi)有用過(guò)，有用過(guò)的同學(xué)請(qǐng)指教。我本來(lái)想使用
session
保存，然后進(jìn)行
session
同步，后來(lái)
IBM
建議使用數(shù)據(jù)庫(kù)
cache
，即自己寫代碼，
cache
在數(shù)據(jù)庫(kù)中。這樣不需要
session
同步，對(duì)象不大，性能也能得到保證，現(xiàn)在用下來(lái)效果還可以。
?