應用服務器的集群策略及Java EE 5.0

摘要：集群并不是解決性能問題的最佳途徑，在單機低并發的情況下如果發現性能不理想，那么請不要指望集群能給你帶來性能的提升，相反性能還會有所下降
編者按:在中國Java技術界，袁紅崗是一個不能忽視的名字。他的觀點，及對中間件趨勢的看法，是很多人感興趣的。日前，在金蝶Apusic于廣州花園酒店舉辦的“Java俱樂部”上，記者和這位極少露面的金蝶中間件首席科學家就集群、Java EE5.0等熱門話題展開了直率的深入對話。果然，袁紅崗出語驚人，帶來了很多獨特的視角和精彩的觀點。

　　記者:不管是一般的技術觀點，還是在平時打單過程中，我們似乎可以感覺到，集群功能一直是國外中間件廠商攻擊國內中間件的弱點。而據我們所知，你們金蝶中間件在去年下半年推出了自己的集群功能，并且在宣傳中提及，在國家質檢總局全行業這個大單中和幾個主要國外產品同等測試，測試結果甚至排在前面，這是否表示Apusic的集群功能已經能滿足客戶的需求?你對集群功能又怎么看，你認為中J2EE集群的本質是什么?

　　袁紅崗:首先我可以向你證實，在國家質檢總局的核心電子業務系統“大通關”項目中，金蝶Apusic中間件與三家世界主要中間件廠商的產品，在同一平臺和環境下用國際測試工具進行了全方位的性能測試，經過三輪嚴苛的點對點、兼容性和性能測試，結果我們成功奪標。在測試結果中，Apusic在集群性能上并不遜色國外同類產品。

　　集群是中間件廠商經常熱捧的一個概念，說只有采取集群策略你的應用系統的性能才能提高。不明就里的用戶在付出了數倍的價錢去購買集群設備和軟件以后，卻往往得不到所應該得到的效果。Apusic作為一家負責任的公司，應當向大家來澄清所謂的“集群悖論”。所謂集群，只有在細粒度計算中其效果才會明顯，也就是將計算過程以一定的并行算法進行細分，將計算分布到多個處理機運行，最后再將計算結果合并。有一個很有名計劃叫做SETI@home，是一項利用全球聯網的閑置計算機共同搜索地外文明的科學實驗計劃，只需要下載一個小程序就可以對從射點望遠鏡得到數據進行分析。這就是一個典型的細粒度計算，所有的參與計劃的計算機并行地計算浩如煙海的龐大數據庫中的一小段數據，再將計算的結果匯總，從而發現可能的智能信號。而反過來我們看到在J2EE應用中大多數計算都是粗粒度的，再加上事務處理需要在分布式計算中進行協調，更降低了集群的整體處理能力。因此集群并不是解決性能問題的最佳途徑，在單機低并發的情況下如果你認為性能不理想，那么請不要指望集群能給你帶來性能的提升，相反你會發現性能反而還會有所下降。

　　那么，集群僅是廠商宣傳的噱頭嗎?在以下兩種情況下集群是有用的:1. 高并發超負荷運行的主機，例如google這樣的網站，它的訪問量是相當大的，因此google會采取集群策略來分散客戶的請求，以提高整體響應能力。我們接觸的很多J2EE應用負荷量都不大，其實每秒訪問量在500以下的應用都沒有必要采取集群策略。2. 失效轉移，其實我認為這才是集群真正有用的地方，使用一臺低成本計算設備作為主設備的備份，在主設備發生故障時及時接替，以保證7x24小時不間斷服務。綜上所述，在準備采用集群之前，一定要仔細分析具體的應用環境，以避免不必要的浪費。

　　作為一種選擇，Apusic同樣實現了集群技術，但我們并沒有沿用大多數應用服務器廠商所采取的內存復制技術(in-memory replication)，我們知道在集群中需要在各結點之間同步一些狀態信息，如果采用內存復制技術，將耗費大量的網絡帶寬，對性能也有很大影響。這是因為每當一個結點的狀態發生變化時，都需要通過多播等方式向其他結點傳遞狀態信息，隨著集群內部結點的增多，內存復制將會非常頻繁，從而造成廣播風暴，嚴重阻塞帶寬。Apusic所采取的技術是客戶端緩存，即直接將狀態信息保存在客戶端，當服務器失效時將狀態轉移到可用服務器。

　　記者:其實直到現在，還有人對中國人能做出中間件不相信、對產品不信任。你在去年曾說“大家在同一個標準下開發，Apusic和IBM、BEA的產品沒什么本質區別”、對于這句話，你今天能否再解釋一下?

　　袁紅崗:這個問題其實不需要證明，沒有人認為神舟飛船和阿波羅飛船在本質上有什么區別，都是為載人航天而制造出來的工具，并不會因為一個是中國制造、另一個是美國制造，在用途上就存在什么區別。誠然，我們和國外產品還存在一些差距，但在J2EE標準框架之下，我們提供了完全可供用戶使用的產品，用戶的選擇是對我們產品最大的肯定。中國軟件起步較晚，基礎較薄弱，但在中間件領域我們是及時跟進的，當時站在同一條起跑線上，現在仍然沒有被淘汰出局，相反差距還在逐步縮小。我相信憑我們的技術實力，我們完全有資格和國外產品同臺競技。

原文轉自：http://www.anti-gravitydesign.com