越來越多的基於REST的服務開始取代SOAP。Java中的REST服務在JSR 311中有說明，是基於HTTP所支持的基本操作而設計的。但是，REST不是作為RCP協議，而是面向資源的，為了訪問和操作（web）資源而設計的。這兩個協議都支持同步通信。這也是底層HTTP協議所要求的。WS-地址對SOAP協議進行擴展，所以它也允許異步服務的實現。REST最大的優點是，能夠很容易的通過HTTP代理實現緩存。REST依靠使用HTTP底層協議，無論如何都和用的機制。
可能犯的錯
分布式應用的很多地方都可能出現潛在的問題，如圖所示：
圖5 分布式應用的問題起因
在客戶端，主要的問題在於糟糕的交互設計-太多的服務調用，或者選擇了錯誤的通信模式。同步事務運行時間過長很容易導致性能問題。在通信層，大量的數據和過多的服務調用所產生的高的網絡負載是主要問題。在服務端，不適當的服務接口設計和不合適的序列化策略的使用導致性能和擴展性問題。我們下面仔細看下這些問題。
分布式應用的問題起因
通信協議的正確選擇主要取決於系統的整體架構和底層的需求。如果你工作在有mainframe、Java和.Net組件相互交互的特異環境中，用SOAP是行不通的。在純Java環境中，在JRMP上使用RMI仍是性能最優，可擴展性最好的解決方案，你能夠獲得開箱即用的編程支持。在很多SOA實現中，SOA和基於Web Service的實現同義而語。所以有越來越多的使用SOAP作為RPC協議的純Java應用案例出現，盡管采用這樣的方法一點有點都沒有。調查顯示，和RMI-JRMP相比，經常使用SOAP還是有意義的。除了描述過的標准協議，一些其他的基於XML的和二進制協議也在一些應用中使用。Hessian的性能就不錯。另外，還有一些其他編程語言的實現。例如使用Spring把POJOs暴露給遠程調用使不改變實現就在不同的協議間切換變得相對容易。Spring 支持RMI, HTTP, Hessian, Burlap, JAX-RPC, JAX-WS 和 JMS。
反模式：饒舌的應用
在搭建分布式應用時，一個核心的原則就是盡量減少遠程調用。這些意味著數據序列化的開銷，建立連接的開銷和附件的網絡負載。另外，CPU,內存和網絡資源的消耗限制了可擴展性。所以，為遠程應用的接口設計一種方法，來確保必要的服務交互數最小是十分重要的。尤其是那些起初是在本地搭建的，然後為了可擴展性原因遭遇了大量服務交互的應用。這些問題大多會在負載測試或產品化時出現，但當本地開發測試時一點問題都沒有。可以采用適當的性能管理方法，在開發過程中分析遠程行為就可以避免這些問題。下圖顯示的是一個通過dynaTrace分析一個應用的遠程行為的例子 。
基於這個分析，接口能夠重新創建，應用邏輯能夠重新設計來減少遠程調用的次數。可能的方法是，合並幾個方法的邏輯為一個，或在幾個調用請求周邊的對象處，使用數據容器。特定數據的位置也可以幫助減少遠程調用，因為在需要的地方數據是可用的。尤其當讀數據時，使用cache可以很大程度上提高性能和可擴展性。在軟件設計的早期，服務的分發和可能的通信在成為需求或將成為需求時已經考慮到是很重要的。
反模式：大格式消息
當調用遠程的服務時，這通常意味著數據會在不同的協議上傳輸。像XML在SOAP協議上傳輸或二進制數據在RMI協議上傳輸。大多數技術傳輸對象的數據或對象本身。大多數情況下，序列化的發生是在遠程實現的底層。序列化的開銷和所傳輸對象的大小相對應。在實際情況下，我們進行序列化的開銷要占到98%。怎麼會這樣？一個鑒權服務接口需要一個用戶對象來授權。這個用戶對象不僅有用戶名和密碼，還有很多屬性，關聯到其他用例的數據引用。標准的SOAP序列化要創建幾千字節的數據消息。這些數據要被服務解析並映射到用戶對象結構上，導致大量CPU和內存的消耗。解決方案再明顯不過了。接口要重構，只需要用戶ID和密碼。所以，除了選擇正確的遠程技術，消息內容的設計對構建好的性能和可擴展性的應用很重要。通常正好符合設計的很好一般對象會帶來高性能的回報。
反模式：分布部署
分布式的Java企業級應用會導致一個應用分割成多個服務和一些部署單元部署到一些應用服務上。分布式的有一個組件新的部署包不需要重新部署到其他組件上。另一個可能性是，大量使用的服務能夠部署到獨立的硬件或被部署多次。有大量部署單元的復雜應用，服務的交互變得越來越難理解。這會導致2個交互頻繁的服務被部署到不同的硬件上從而產生很多的遠程調用情況出現。在大規模應用中，分析交互的頻率和數據大小與部署結構一致是很重要的。很多時候，從分布式部署到本地可以使性能得到很大的提升而不需要損失靈活性和可擴展性。尤其對那些無狀態的服務，把它們部署到不同的節點來提升其本地性。
結論
從這些反模式中可以看出，在應用的設計初期階段就考慮可擴展性是很重要的。它是應用架構的一個關鍵驅動。在後期提高性能和可擴張性在多數或大多數情況下工作會越困難。對應用產品的詳細分析來識別遠程調用的頻率或大體積數據，優化系統的一致性是不可或缺的。如果你遇到了相似的或不同的問題，請讓我知道，我好擴充我的反模式記錄。
【更多Java分布式技術】
原文標題：Performance Considerations in Distributed Applications
鏈接地址：http://blog.dynatrace.com/2009/09/28/performance-considerations-in-distributed-applications/
【責任編輯：red7 TEL：（010）68476606】
