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