為網絡做準備J2EE部署中的下一個沖擊波(圖)

2019-11-18 12:23:25

字體：大中小

來源：轉載

供稿：網友

　　摘要
　　
　　在九十年代，企業們發現最好是把存儲當作基礎結構來處理，而網絡附加存儲的理念在短短幾年間從一個激進的觀點逐漸成為一個主流的解決方案。如今，網絡的增強處理——中間整合層的服務已經逐漸發展為小型池計算組件——較為均衡地將類似的治理及整合益處賦與了J2EE部署，從而減少開發、部署、治理及維護分布式J2EE的成本及復雜性，
　　
　　J2EE技術在最近幾年已經獲得了廣泛的成功。但是維護、部署和治理J2EE應用對于許多企業來說已經成了個難題——幾乎全部的服務系統必須被設置和治理，并對人員和有效的數據中心設備資源造成了沉重負擔。而一項新的叫做網絡增強處理的技術可以幫助應付這些J2EE開發中的整合和治理的挑戰。
　　
　　我們成功的代價
　　
　　治理先驅Peter Senge曾經說“今天的難題都是來自昨天的解決方案”。當Senge在腦海里有了經濟和政治上的決定他都會考慮到這一點，這個說法也同樣適用于軟件技術，而且軟件更新的運動中快速的變化讓我們能很輕易看清這個真理。比如，九十年代的C/S技術革命旨在降低開發大型機的難度及成本，以使其更有效地解決較大的軟件問題。
　　
　　但是世界并不會老老實實地跟隨在革新的后面。隨著對復雜的企業應用的要求不斷提高，C/S的弊端逐漸顯露。分布式對象、Web應用、應用服務器、面向服務體系（SOA）——每一種企業軟件開發技術的產生都體現出前一代技術的一些缺陷，同時又使開發更復雜的應用成為可能。但是隨著新的技術的產生，新的問題浮出水面，比如可伸縮性、可治理性以及開發的復雜性。
　　
　　作為開發人員，我們非常興奮看到這些技術的快速發展——它們提供了很多新的有趣的思想讓我們來思考，以及新的技術讓我們運用，使我們能通過所提供的預算資源來解決更大范圍更復雜的問題，當然對我們的技能也提出了較高的要求。
　　
　　虛擬機和應用服務器的技術模式在發展中有個相同點：當它發展成為企業軟件開發的主要形式時（Gartner 預言到2008年年底，百分之八十的新型電子商務應用服務都將建立在虛擬機的基礎上），我們總是費盡心思地處理這個模式的成功所帶來的一系列后果——部署的復雜性，能力治理和計劃的挑戰，以及要在一堆繁復的拓撲技術中尋求平衡的開發應用的難題。應用服務器減輕了其中一部分困擾，但還是很復雜。java技術不僅僅證實了其在高效開發以及交互企業應用方面的價值，它同樣成為了它自身成功的犧牲品。
　　
　　當今分布式應用面臨的挑戰
　　
　　現在的硬件配置的價格是難以置信的低廉——只需幾千美元，你就可以買到遠比過去的大型機先進得多的商品，安裝支架，以及容錯系統。但是現在的應用系統卻比過去更加資源匱乏。我們用來加速軟件開發、提高軟件的可靠性，治理軟件的復雜性的技術耗費了大量的計算盈余；不斷提高的用戶期待也消耗了所剩部分，等等。結果便是，大部分的企業應用由于太過于龐大而不能在某臺低端服務器上運行，因而經常被分布部署在一堆廉價的主機中。J2EE分布式應用的軟件技術已經投入使用，但反過來增加了附加資源耗費的開支，以及開發、分布和治理復雜性的開支。
　　
　　雖然分布式可以提供較高的有效性和容錯性，但是假如為了達到理想的工作狀況而必須在100臺服務器之間采用分布式的話，可以肯定將會對設計、開發、調度等產生負面影響。（分布式應用的服務器支持一直在改進，但是不管它怎么改進，開發一個JVM上的應用仍然比開發分布應用簡單。）所以，假如我們自信可以在一個簡單的JVM上運行我們的應用，哪怕負載提高了，我們還是能省下很多開發、部署和治理上的精力，籍此以建立更強的應用。
　　
　　分布式還提出了一個明顯的操作上的挑戰。現在的數據中心往往擁有上百臺應用服務主機（所以被叫做“服務蔓延”），意味著系統治理員必須治理、維護這些服務器并提供高效服務。隨著處理要求的提高，操作員必須在不中斷服務的前提下快速的增加容量和重新配置應用。或者，假如因擴容而部署的時間要超出要求的響應時間，則應該為了避免不必要的拖延而提前做好維護。當然，從治理的角度，應盡可能地將系統和數據庫的治理員支出減到最低程度。
　　
　　因為較低運算能力的獨立服務系統難以滿足一個典型企業應用的要求，服務主機一般不橫跨共享多個應用；一個應用會占用一個或更多的服務器，而這些服務器并非互不相關的。這種方法讓很多企業開支可觀，因為那些每個應用所分配的資源是按照應用的最高負荷來規劃的（乘上安全邊界需求），即使一般的需求遠遠低于最高負荷。假如一個企業擁有多個應用，而這些應用的負荷峰值的期間并無關系—這正是大數企業的狀況，結果就是應用間的容量(參與成本，attendant cost)大量被浪費了。它的效用經常看起來像下表所列：
　　　為網絡做預備J2EE部署中的下一個沖擊波(圖)（圖一）

　　圖1.每個應用基礎所產生典型效率。
　　
　　這些普遍存在的維護方式，過于繁重的維護及在每個應用基礎上對峰值所做的維護，導致了更高的硬件支出，更高的員工開支，并降低資源利用效率——其結果就會是降低IT投資的收益。
　　
　　利用網絡聯合處理降低治理和容量計劃的復雜性
　　
　　企業很早就熟悉到網絡附加存儲（NAS: network attached storage）和存儲領域網（SAN: storage area network）技術在降低改進服務質量和可靠性的方面的巨大價值。通過治理跨企業的存儲能力替代基于個體系統上的治理，存儲效率提高了；存儲空間可以很方便的進行添加，分配，或者根據需要進行重新分配；要害數據可以更輕易的拷貝和恢復；可以更輕易的監視高峰和進行中心治理。
　　
　　NAS和SAN在1995年還是備受爭議的，而今已成為解決存儲問題的主流方案。這些問題實際上和我已經討論過的服務維護相似——大量而且一直在增多的存儲器需要治理；每個復合的存儲器則都需要一個應用；存儲器都要分配一個特定的應用，影響了效率；而且伴隨著高額開支的重復維護資源要求有相應的模式變化。網絡附加處理，這項新的技術在處理資源方面可以與NAS的存儲處理相媲美，它對數據中心的治理就像一個專家。
　　
　　就像NAS的出現就伴隨著龐大且不斷膨脹的存儲池，隨后交給治理人員將存儲塊劃分為虛擬存儲盤，并自動設置資源利用方案，網絡附加處理也伴隨著一個巨大的計算機資源治理池，可以按照可定制資源治理方案來靜態或動態地分配應用。
　　
　　Azul的網絡附加處理解決方案：計算應用
　　
　　第一個（從時間上來說）發布網絡附加處理方案的是加利福尼亞“群山視野”的Auzl系統，一個384處理器，11-U 可插槽的，帶有256GB相關的統一通道的內存的計算器，利用定制的專為運行虛擬機的技術的處理器，利用硬件特性來加快垃圾回收以及并發性處理。
　　
　　利用SAN技術，這種計算機器可以被邏輯劃分為復合的虛擬主機，CPU和內存資源都可以被自動分配給虛擬主機。這些虛擬主機被認為是“可裝配計算池”，使得復合應用可以從企業應用的巨大范圍內調用其計算功能。一個獨立384通道的計算應用可以處理50個或更多的在虛擬機上的應用，而這些應用都有上千GB，包含著上千個線程。
　　
　　因為有如此多的應用都要依靠它們，計算池主機需要保證有更高可靠性和容錯性。而Azul存儲器具有一切所需的RAS(有效性、可用性、服務性)功能——在主存儲器和高速緩存中的ECC（糾錯代碼），錯誤監視，以及即插式電源和風扇。高速讀寫的硬件設備保證了同步垃圾回收功能無停頓，響應時間可以更輕易預知。當然，這項超酷的技術只是解決了一方面的問題——這項技術的全部目的就是降低J2EE應用的治理和部署開支。
　　
　　精簡容量計劃
　　
　　這個計算池的出現顛覆了容量原有的工序，使容量的規劃能在整個企業平臺上進行。不是在每個應用上都要安排硬件的獲得與服務的治理，而是在計算池里給每一臺虛擬主機分配應用，并且隨著需求的增長，虛擬主機的資源分配也可以自動的增長。假如不斷增長的復合應用共享一個計算器，當它增大到超出了計算主機的存儲能力時，它（或者其他應用中的一個）會自然的被轉換到別的計算器的剩余空間內，而不需要應用級別的重新配置。Azul的計算池治理軟件答應資源分配和使用方案在所有計算器內可以被設置。
　　
　　更好的資源利用
　　
　　因為應用載入時間的高峰隨著應用的不同而不同(比如發薪水的應用在月初最高，發勞保金的應用在開放注冊時最高，等等)，治理企業基礎上的容量可以獲得更大的硬件利用效率，因為你再也不需要在應用的最大值時購買或供給額外的容量給服務應用——除了在所有應用的載入最大值的時候，而這時的值也比獨立應用的峰值之和要小得多。（將應用層的處理整合進計算池，也簡化了治理使用與規劃容量的過程）。
　　
　　圖2表示了圖1中的5個應用在一個計算池里運行的效率（加上另外十個相似的應用）。結果表明：效率從3提高到了5，并且對應用重新分配資源的靈活性也改善了。
　　　為網絡做預備J2EE部署中的下一個沖擊波(圖)（圖二）

　　圖2，使用計算池并帶有相同級別計算資源的主機，可獲得更多容量。
　　
　　向網絡附加處理轉移
　　
　　對于現有的應用，我們需要花很多精力來建立和部署它們。計算池的出現也許可以提供巨大的可伸縮性，但移植一個應用到另一個平臺還是需要開支。對于網絡附加處理，所需的開支就和從局部存儲到網絡附加存儲的移植差不多——現有的軟硬件配置都不需要做任何改變。不用把整個應用移植到計算設備上，只需轉移計算部分——應用、存儲、數據庫還有安全配置都原封不動的保留在現有的服務器上。不同的是本地JVM將由一個代理JVM代替，代理JVM將通過搜索Azul計算池治理器找到一個可用的計算應

上一篇：J2ee核心技術：J2EE Frameworks介紹

下一篇：JRockit JVM對AOP的支持，第2部分