2.6 應用服務器的集群策略及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標準框架之下，我們提供了完全可供用戶使用的產品，用戶的選擇是對我們產品最大的肯定。中國軟件起步較晚，基礎較薄弱，但在中間件領域我們是及時跟進的，當時站在同一條起跑線上，現在仍然沒有被淘汰出局，相反差距還在逐步縮小。我相信憑我們的技術實力，我們完全有資格和國外產品同臺競技。

　　在我參加各種技術大會，包括去年北京Java10周年大會時，跟許多技術人員交流、聊天的時候，他們都反映Apusic的啟動速度非常快，很快就啟動了，和同類產品相比非常突出。看來使用者們對它快速啟動的特點非常喜愛。據我了解，Apusic的代碼只是其它產品的幾分之一，是因為這個原因嗎?你設計時是怎么想的?

　　很多人不理解，為什么Apusic和其他產品比起來代碼規模上要小很多，但使用起來并沒有感覺到有什么功能缺失呢?這里要涉及到軟件使用上的一個“二八原則”，即80%的使用者通常只會用到一個軟件20%的功能。象微軟的產品個個都是巨無霸，但對某個產品真正做到完全精通的可以說寥寥無幾。以Word為例，平時我們只是用它來寫寫文檔，很多高級功能其實根本用不上。在Apusic應用服務器的開發上我們也是遵循同樣的原則，我們將盡可能地將整個軟件產品最重要的20%的功能做好、做完善，以保證大多數用戶的需求，剩下的80%功能將根據需要逐步增加。譬如國外產品很早就有的集群功能我們最近才推出來，并不是我們沒有能力實現集群功能，而是在我們看來，集群并不是解決性能問題的最好方案，只有在真正大并發請求下集群才會展現它的優勢。因此，我們把集群功能歸結為低優先級需求，只有在其他方面的性能和穩定性有了很大提高后再來考慮集群。

　　另一個使Apusic運行輕便的重要原因在于軟件架構的設計。架構是一個軟件的靈魂，好的架構將延長軟件的生命力，輕松應付各種變化。Apusic的架構在2001年時就已定型，以微內核和多路復用為其核心，歷經產品多次重大升級而未影響核心體系，展現了頑強的生命力。相反，如果架構設計不合理，每次升級都要對架構進行調整，勢必引入大量冗余代碼，使整個產品臃腫不堪。

　　第三個原因在于代碼編寫的簡潔性上。莎士比亞有一句名言：“簡潔是智慧的靈魂”，在科學界同樣也推崇簡潔性，麥克斯韋方程組簡潔深刻，被譽為是上帝譜寫的詩歌，愛因斯坦的著名公式E=mc^2更是將簡潔性發揮到了極致。程序設計語言不僅僅是為計算機運行而設計的，它也是一種思想表達工具，甚至比自然語言更簡潔、深刻、無歧義。我平時很少寫文檔，因為我認為代碼本身就已經表達了作者的思想。當我看到簡潔優美的代碼時，我認為是在讀一篇美麗的詩篇，并為作者深邃奔放的思想所折服。相反，當看到混亂、繁復而無章法的代碼時，我相信作者的思想同樣是混亂的。

　　計算機等級考試二級Java經典算法大全匯總

　　2010年9月計算機等級考試成績查詢時間匯總

 　　2011計算機等級考試二級JAVA學習精華匯總