在當今應用架構里，分布式和應用與服務(wù)之間的通信都是核心思想。想要從分布式中獲益，你必須牢牢記住幾條基本的原則，否則你可能會(huì )很容易遇到性能和擴展性問(wèn)題。在開(kāi)發(fā)階段這些問(wèn)題不會(huì )經(jīng)常出現,但當你進(jìn)行負載測試或產(chǎn)品化的時(shí)候，你可能會(huì )意識到你選擇的軟件架構不能滿(mǎn)足性能和擴展性需求。在這篇文章中，我們重點(diǎn)關(guān)注構建分布式應用需要記住的一些關(guān)鍵點(diǎn)。
分布式需要應用之間進(jìn)行交互。范圍包括從大規模集群架構上簡(jiǎn)單的點(diǎn)到點(diǎn)的交互，到動(dòng)態(tài)的面向服務(wù)或基于服務(wù)的架構?？缦到y邊界的通信也是提高軟件系統擴展性和可用性的關(guān)鍵。如今軟件架構已把分布式作為一個(gè)核心的必要的概念。Java平臺成為了核心的角色，因為它的分布式、有很好的API和產(chǎn)品支持這些特點(diǎn)。應用場(chǎng)景從像SAP這樣在標準軟件上的系統集成，到內部或外部的服務(wù)集成。SOA提供這樣的方法，使服務(wù)和應用變的靈活和可重用，可以對新的市場(chǎng)需求很快的做響應。另外，像使用網(wǎng)格計算，虛擬機和多核刀片機的趨勢，導致越來(lái)越多的集群應用的出現。這主要是由于追求高可擴展性和高可用性驅動(dòng)的。而且云計算的發(fā)展趨勢表明，分布式平臺將來(lái)會(huì )更加流行。另外，系統正變得希望能更動(dòng)態(tài)的增加其靈活性。例如，在運行時(shí)添加應用節點(diǎn)。這些趨勢也導致了系統結構變得越來(lái)越復雜。對于開(kāi)發(fā)人員來(lái)說(shuō)，則更難理解產(chǎn)品中服務(wù)調用是如何實(shí)現的了。這種復雜性和缺乏對相應知識的了解，很容易導致資源消耗的增加（CPU,內存，網(wǎng)絡(luò )）和性能的降低。
面具后的惡魔
如今，遠程技術(shù)使分布式應用的實(shí)現更加簡(jiǎn)單。底層通信的細節和服務(wù)端和客戶(hù)端的基礎結構對開(kāi)發(fā)人員是透明的?，F在，如果要把一個(gè)Java類(lèi)暴露為一個(gè)服務(wù)，有時(shí)只需要簡(jiǎn)單的加一個(gè)注解到這個(gè)類(lèi)上。服務(wù)也可以被工具生成的代理很容易的訪(fǎng)問(wèn)。如下圖所示，但是，這僅僅是冰山的一角。
遠程堆棧的核心塊是對象的序列化和傳輸的格式化。通常，應用的開(kāi)發(fā)者不需要知道這些。但是，這也是很多性能問(wèn)題產(chǎn)生的原因。效率不高的序列化意味著(zhù)，通過(guò)網(wǎng)絡(luò )傳輸了很多不需要的數據。復雜對象的顯示和大量的數據，在序列化和反序列化期間，導致CPU和內存的使用會(huì )很高。底層的基礎架構和它的配置對應用的性能有很大的影響。在客戶(hù)端，主要是連接的管理和底層線(xiàn)程模型。在分布式應用中使用連接的指導方針和數據庫的連接很像。建立一個(gè)連接需要一定的時(shí)間。但這同樣要看是什么協(xié)議。例如，建立一個(gè)HTTPS的連接的開(kāi)銷(xiāo)要大于一個(gè)簡(jiǎn)單的TCP/IP連接。同時(shí)，連接又是系統很重要的資源。所以，使用連接池很重要。正確的配置在這里也很關(guān)鍵，因為錯誤的配置文件給我們帶來(lái)的壞處要多于好處。線(xiàn)程的模型涉及到請求如何被處理。重要的是請求是被同步還是異步處理。同步通信阻塞一個(gè)進(jìn)程直到收到相應。在異步通信中，當收到響應時(shí)會(huì )調用一個(gè)回調。這就允許這個(gè)線(xiàn)程被其他事務(wù)使用。在服務(wù)端，可用的工作線(xiàn)程數量就是定義的并行處理的最大服務(wù)請求數。網(wǎng)絡(luò )本身也是分布式應用的一個(gè)重要組件。網(wǎng)絡(luò )是比影響性能更加限制其可擴展性的重要的瓶頸資源。這塊通常在開(kāi)發(fā)時(shí)會(huì )被忽視，因為沒(méi)有調用實(shí)際的網(wǎng)絡(luò )。
遠程調用之美在于...
這有很多可以選擇，Java提供了非常多的可能性和技術(shù)來(lái)實(shí)現分布式應用。遠程技術(shù)的選擇對應用的架構、性能和擴展性有十分重要的影響。最“老的”的但是幾乎是用的最廣的遠程協(xié)議是RMI（如下圖）。
RMI是J2EE應用的一個(gè)標準協(xié)議。像它的名稱(chēng)暗示的一樣，設計時(shí)就是為了調用遠程Java虛擬主機上的對象提供的方法。對象在服務(wù)端被暴露出來(lái)，這時(shí)客戶(hù)端就可以通過(guò)代理調用這個(gè)對象。同樣的服務(wù)端對象被多個(gè)線(xiàn)程使用。線(xiàn)程池被RMI基礎設施管理。通信通過(guò)TCP/IP被處理，并且使用JRMP或針對RMI的基于IIOP GIOP（CORBA協(xié)議）的協(xié)議。應用服務(wù)端也提供自己的屬性協(xié)議來(lái)優(yōu)化其性能。如服務(wù)端的引用需要管理一樣，RMI基礎設施也提供了垃圾回收器來(lái)管理引用。這個(gè)分布式垃圾回收器（DGC）本身也使用RMI協(xié)議來(lái)管理服務(wù)器端的對象生命周期。除了客戶(hù)端和服務(wù)端很強大，RMI還有一些其他的實(shí)現。
RMI只支持同步通信，缺點(diǎn)上面已經(jīng)討論過(guò)了。另外，不能為數據驅動(dòng)的服務(wù)提供低級緩存，因為它是基于2進(jìn)制協(xié)議的。開(kāi)發(fā)人員和系統架構能夠改變基礎設施的配置參數來(lái)優(yōu)化性能。JMS是J2EE平臺上使用的第二多的協(xié)議。如下圖：
有別于RMI, JMS是一個(gè)異步的協(xié)議。通信是基于隊列的，以便監聽(tīng)器可以對消息作出反應。JMS不是一種標準的遠程調用協(xié)議，但是它仍然能夠滿(mǎn)足服務(wù)與服務(wù)之間的交互。在SOA中非常重要的很多ESB的實(shí)現，就采用基于JMS的中間件來(lái)進(jìn)行服務(wù)之間的信息傳遞。由于JMS是異步的，一些典型的同步問(wèn)題就可以避免。在很多系統中，高可擴展性的關(guān)鍵在于能夠很快的釋放資源（像線(xiàn)程）。在很多情況下，異步處理是唯一合適的方法。JMS提供很多不同的傳輸格式。XML是最通用的消息格式，但二進(jìn)制格式也是可能的。消息結構的設計是應用架構的一個(gè)重要部分，因為它可以直接影響到應用的性能和可擴展性。
基于SOAP的WEB Service（如下圖）和其他相關(guān)的WS-*也在Java 企業(yè)應用領(lǐng)域中變得越來(lái)越重要。
設計SOAP是為了替換CORBA，而且一開(kāi)始就得到了業(yè)界的強烈支持。因為WS-I之間的共同努力，不同平臺差不多能夠很容易的連接起來(lái)。SOAP是一種基于XML的RPC協(xié)議，所以很容易和浪費帶寬聯(lián)系到一起。
本文地址：【伊甸網(wǎng)】http://www.edenw.com/tech/devdeloper/java/2010-07-20/4817.html
越來(lái)越多的基于REST的服務(wù)開(kāi)始取代SOAP。Java中的REST服務(wù)在JSR 311中有說(shuō)明，是基于HTTP所支持的基本操作而設計的。但是，REST不是作為RCP協(xié)議，而是面向資源的，為了訪(fǎng)問(wèn)和操作（web）資源而設計的。這兩個(gè)協(xié)議都支持同步通信。這也是底層HTTP協(xié)議所要求的。WS-地址對SOAP協(xié)議進(jìn)行擴展，所以它也允許異步服務(wù)的實(shí)現。REST最大的優(yōu)點(diǎn)是，能夠很容易的通過(guò)HTTP代理實(shí)現緩存。REST依靠使用HTTP底層協(xié)議，無(wú)論如何都和用的機制。
可能犯的錯
分布式應用的很多地方都可能出現潛在的問(wèn)題，如圖所示：
在客戶(hù)端，主要的問(wèn)題在于糟糕的交互設計-太多的服務(wù)調用，或者選擇了錯誤的通信模式。同步事務(wù)運行時(shí)間過(guò)長(cháng)很容易導致性能問(wèn)題。在通信層，大量的數據和過(guò)多的服務(wù)調用所產(chǎn)生的高的網(wǎng)絡(luò )負載是主要問(wèn)題。在服務(wù)端，不適當的服務(wù)接口設計和不合適的序列化策略的使用導致性能和擴展性問(wèn)題。我們下面仔細看下這些問(wèn)題。
分布式應用的問(wèn)題起因
通信協(xié)議的正確選擇主要取決于系統的整體架構和底層的需求。如果你工作在有mainframe、Java和.NET組件相互交互的特異環(huán)境中，用SOAP是行不通的。在純Java環(huán)境中，在JRMP上使用RMI仍是性能最優(yōu)，可擴展性最好的解決方案，你能夠獲得開(kāi)箱即用的編程支持。在很多SOA實(shí)現中，SOA和基于Web Service的實(shí)現同義而語(yǔ)。所以有越來(lái)越多的使用SOAP作為RPC協(xié)議的純Java應用案例出現，盡管采用這樣的方法一點(diǎn)有點(diǎn)都沒(méi)有。調查顯示，和RMI-JRMP相比，經(jīng)常使用SOAP還是有意義的。除了描述過(guò)的標準協(xié)議，一些其他的基于XML的和二進(jìn)制協(xié)議也在一些應用中使用。Hessian的性能就不錯。另外，還有一些其他編程語(yǔ)言的實(shí)現。例如使用Spring把POJOs暴露給遠程調用使不改變實(shí)現就在不同的協(xié)議間切換變得相對容易。Spring 支持RMI, HTTP, Hessian, Burlap, JAX-RPC, JAX-WS 和 JMS。
反模式：饒舌的應用
在搭建分布式應用時(shí)，一個(gè)核心的原則就是盡量減少遠程調用。這些意味著(zhù)數據序列化的開(kāi)銷(xiāo)，建立連接的開(kāi)銷(xiāo)和附件的網(wǎng)絡(luò )負載。另外，CPU,內存和網(wǎng)絡(luò )資源的消耗限制了可擴展性。所以，為遠程應用的接口設計一種方法，來(lái)確保必要的服務(wù)交互數最小是十分重要的。尤其是那些起初是在本地搭建的，然后為了可擴展性原因遭遇了大量服務(wù)交互的應用。這些問(wèn)題大多會(huì )在負載測試或產(chǎn)品化時(shí)出現，但當本地開(kāi)發(fā)測試時(shí)一點(diǎn)問(wèn)題都沒(méi)有?？梢圆捎眠m當的性能管理方法，在開(kāi)發(fā)過(guò)程中分析遠程行為就可以避免這些問(wèn)題。下圖顯示的是一個(gè)通過(guò)dynaTrace分析一個(gè)應用的遠程行為的例子 。
基于這個(gè)分析，接口能夠重新創(chuàng )建，應用邏輯能夠重新設計來(lái)減少遠程調用的次數?？赡艿姆椒ㄊ?，合并幾個(gè)方法的邏輯為一個(gè)，或在幾個(gè)調用請求周邊的對象處，使用數據容器。特定數據的位置也可以幫助減少遠程調用，因為在需要的地方數據是可用的。尤其當讀數據時(shí)，使用cache可以很大程度上提高性能和可擴展性。在軟件設計的早期，服務(wù)的分發(fā)和可能的通信在成為需求或將成為需求時(shí)已經(jīng)考慮到是很重要的。
反模式：大格式消息
當調用遠程的服務(wù)時(shí)，這通常意味著(zhù)數據會(huì )在不同的協(xié)議上傳輸。像XML在SOAP協(xié)議上傳輸或二進(jìn)制數據在RMI協(xié)議上傳輸。大多數技術(shù)傳輸對象的數據或對象本身。大多數情況下，序列化的發(fā)生是在遠程實(shí)現的底層。序列化的開(kāi)銷(xiāo)和所傳輸對象的大小相對應。在實(shí)際情況下，我們進(jìn)行序列化的開(kāi)銷(xiāo)要占到98%。怎么會(huì )這樣？一個(gè)鑒權服務(wù)接口需要一個(gè)用戶(hù)對象來(lái)授權。這個(gè)用戶(hù)對象不僅有用戶(hù)名和密碼，還有很多屬性，關(guān)聯(lián)到其他用例的數據引用。標準的SOAP序列化要創(chuàng )建幾千字節的數據消息。這些數據要被服務(wù)解析并映射到用戶(hù)對象結構上，導致大量CPU和內存的消耗。解決方案再明顯不過(guò)了。接口要重構，只需要用戶(hù)ID和密碼。所以，除了選擇正確的遠程技術(shù)，消息內容的設計對構建好的性能和可擴展性的應用很重要。通常正好符合設計的很好一般對象會(huì )帶來(lái)高性能的回報。
反模式：分布部署
分布式的Java企業(yè)級應用會(huì )導致一個(gè)應用分割成多個(gè)服務(wù)和一些部署單元部署到一些應用服務(wù)上。分布式的有一個(gè)組件新的部署包不需要重新部署到其他組件上。另一個(gè)可能性是，大量使用的服務(wù)能夠部署到獨立的硬件或被部署多次。有大量部署單元的復雜應用，服務(wù)的交互變得越來(lái)越難理解。這會(huì )導致2個(gè)交互頻繁的服務(wù)被部署到不同的硬件上從而產(chǎn)生很多的遠程調用情況出現。在大規模應用中，分析交互的頻率和數據大小與部署結構一致是很重要的。很多時(shí)候，從分布式部署到本地可以使性能得到很大的提升而不需要損失靈活性和可擴展性。尤其對那些無(wú)狀態(tài)的服務(wù)，把它們部署到不同的節點(diǎn)來(lái)提升其本地性。
結論
從這些反模式中可以看出，在應用的設計初期階段就考慮可擴展性是很重要的。它是應用架構的一個(gè)關(guān)鍵驅動(dòng)。在后期提高性能和可擴張性在多數或大多數情況下工作會(huì )越困難。對應用產(chǎn)品的詳細分析來(lái)識別遠程調用的頻率或大體積數據，優(yōu)化系統的一致性是不可或缺的。如果你遇到了相似的或不同的問(wèn)題，請讓我知道，我好擴充我的反模式記錄。
本文地址：【伊甸網(wǎng)】http://www.edenw.com/tech/devdeloper/java/2010-07-20/4817.html
聯(lián)系客服
