這次做portal的一些總結（二）

接著前面的寫。上文主要寫了 ajax 在 portal 中的使用，這篇寫集群方面的體會?，F(xiàn)在比較流行的架構就是前端 F5 做負載均衡，后面 2 臺 websphere server 做成集群，各自都有 HttpServer ，每個 HttpServer 都向 2 臺 was 做轉發(fā)。這樣每臺都能獨立完成從 HttpServer 到 was 的流程。一臺出現(xiàn)故障， F5 首先進行切換，只向正常 server 的 HttpServer 發(fā)起請求，這臺 HttpServer 再進行切換只向同一臺 server 上的 was 做轉發(fā)。這次 portal 就是采用的這種架構，不妨稱為架構 A 。

另一種簡單點的架構就是只做 F5 負載均衡，不做 was 集群，每臺 websphere server 上的 HttpServer 接受 F5 轉發(fā)的請求，只向本 server 的 was 轉發(fā)。這樣每臺 websphere server 保持獨立，相互間沒有數(shù)據(jù)交換和轉發(fā)。不妨稱為架構 B 。

架構 A 和 B 各有優(yōu)劣，適合不同的需要，下面進行些比較：

????????? 從應用部署上看：

A 使用了 websphere 集群，由一個 DeployManager 進行分發(fā)，部署應用，只需部署一次，由 DM 分發(fā)到幾個節(jié)點上。而 B 每個 server 都是獨立的，部署應用只能一臺臺部署，如果 server 較少差別還不明顯，如果達到 10 臺以上，一臺臺部署將是一個比較痛苦的事情。

????????? 從 session 上看：

A 使用了 websphere 集群，可以使用集群提供的 session 復制，對于一些關鍵應用（某臺服務器宕機， session 也必須保持的應用）很有必要。而對于一些能夠允許 session 丟失的應用，才可以使用 B 。當然 A 也可以關閉 session 復制，因為 session 復制不管是使用數(shù)據(jù)庫方式還是內(nèi)存方式，總會消耗一定的性能。具體消耗多少性能，就要看不同的 application server 的 session 復制方案了，想深入了解，可以看集群方面的文檔，我也只記得一個比較簡單的 round robbin 了。

????????? 從架構復雜性看：

B 更為簡單，因為沒有 DM 的概念，每臺 server 都保持獨立。而使用了 DM 有時也會出現(xiàn)莫名奇妙的問題，這當然是由于不了解 DM 的機制所致，但總歸也增加了復雜度，這點在后面的教訓中進行說明。

????????? 從水平擴展性上看：

B 肯定更勝一籌。只要 F5 能支持，多少臺 server 都沒關系。而 A 多臺 server 做集群，要看 websphere 支持的節(jié)點數(shù)量，應該不會太大。這個如果哪位同學知道，敬請告知。

當然 A 和 B 在服務器較多的情況下是可以共存的，可以考慮幾臺機器做集群，然后集群間做負載均衡，這樣既可以減少部署的復雜度，又可以帶來較好的水平擴展。由于沒做過更大型的項目，這個也只是我的假象，請做過的同學斧正。

?

說一說集群中碰到的問題。

????????? 首先是對各節(jié)點的同步：

有時為了方便測試，我們只對其中一個節(jié)點進行更改，測試通過再放到其它節(jié)點。而如果測試周期較長，有時就會造成節(jié)點的不同步，出現(xiàn)各種各樣莫名其妙的問題。一個經(jīng)驗就是：無論如何，在每天下班前要保證各節(jié)點的同步，不同步的現(xiàn)象不要過夜。

????????? 然后是對 DM 的理解：

我現(xiàn)在還只是實踐階段，沒有看過相關文檔。從意義上看，它控制了相關的配置文件，如果進行節(jié)點同步，就會由它把配置文件同步到它管理的節(jié)點上。這對配置文件的修改提出了要求。我們開始只修改節(jié)點的配置文件而沒有修改 DM 的，結果進行節(jié)點同步就會覆蓋修改的配置文件，帶來很多不必要的工作。經(jīng)驗就是：或者修改 DM 的配置文件，然后進行節(jié)點同步，或者直接同時修改所有節(jié)點和 DM 的。

????????? 還有關于 cache 的：

Cache 是性能優(yōu)化的一個有效手段。在單機環(huán)境下，最簡單的就是內(nèi)存 cache ，使用 static 的 Map 就行。而在集群環(huán)境中， cache 就變的比較復雜了。首先還是從應用需求入手，是否要保持每臺機器的 cache 同步。如果只是信息展示等要求不高的 cache ，不需保證 cache 的同步，問題也比較簡單，自己寫內(nèi)存 cache ，或者使用開源的 cache 組件如 ehcache,oscache 等就可以很好的解決問題。而如果需要 cache 在幾個節(jié)點保持同步，就需要特殊的機制了， ehcache 等號稱支持分布式 cache ，但好像需要 jgroup ，配置比較麻煩，我沒有用過，有用過的同學請指教。我本來想使用 session 保存，然后進行 session 同步，后來 IBM 建議使用數(shù)據(jù)庫 cache ，即自己寫代碼， cache 在數(shù)據(jù)庫中。這樣不需要 session 同步，對象不大，性能也能得到保證，現(xiàn)在用下來效果還可以。

?

posted on 2006-12-13 13:39 pesome 閱讀(3803) 評論(9)  編輯  收藏 所屬分類: 系統(tǒng)架構