2011年計算機等考二級JAVA學習精華整理(64)

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

　　開源代表的經(jīng)常是理想主義者，而商業(yè)公司代表的經(jīng)常是現(xiàn)實主義者，兩者之間有相互競爭的地方，但從長遠來看，更多的是一種是相互補充、相互促進的過程……

　　編者按：在中國Java技術界，袁紅崗是一個不能忽視的名字。他的觀點，及對中間件趨勢的看法，是很多人感興趣的。日前，在金蝶Apusic于廣州花園酒店舉辦的“Java俱樂部”上，記者和這位極少露面的金蝶中間件首席科學家就集群、Java EE5.0等熱門話題展開了直率的深入對話。果然，袁紅崗出語驚人，帶來了很多獨特的視角和精彩的觀點。

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

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

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

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

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

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

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

　　在我參加各種技術大會，包括去年北京Java10周年大會時，跟許多技術人員交流、聊天的時候，他們都反映Apusic的啟動速度非常快，很快就啟動了，和同類產(chǎn)品相比非常突出�？磥硎褂谜邆儗λ�快速啟動的特點非常喜愛。據(jù)我了解，Apusic的代碼只是其它產(chǎn)品的幾分之一，是因為這個原因嗎?你設計時是怎么想的?

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

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

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

　　計算機等級考試二級Java經(jīng)典算法大全匯總

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

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