在當今應用架構裡，分布式和應用與服務之間的通信都是核心思想。想要從分布式中獲益，你必須牢牢記住幾條基本的原則，否則你可能會很容易遇到性能和擴展性問題。在開發階段這些問題不會經常出現,但當你進行負載測試或產品化的時候，你可能會意識到你選擇的軟件架構不能滿足性能和擴展性需求。在這篇文章中，我們重點關注構建分布式應用需要記住的一些關鍵點。
分布式需要應用之間進行交互。范圍包括從大規模集群架構上簡單的點到點的交互，到動態的面向服務或基於服務的架構。跨系統邊界的通信也是提高軟件系統擴展性和可用性的關鍵。如今軟件架構已把分布式作為一個核心的必要的概念。Java平台成為了核心的角色，因為它的分布式、有很好的API和產品支持這些特點。應用場景從像SAP這樣在標准軟件上的系統集成，到內部或外部的服務集成。SOA提供這樣的方法，使服務和應用變的靈活和可重用，可以對新的市場需求很快的做響應。另外，像使用網格計算，虛擬機和多核刀片機的趨勢，導致越來越多的集群應用的出現。這主要是由於追求高可擴展性和高可用性驅動的。而且雲計算的發展趨勢表明，分布式平台將來會更加流行。另外，系統正變得希望能更動態的增加其靈活性。例如，在運行時添加應用節點。這些趨勢也導致了系統結構變得越來越復雜。對於開發人員來說，則更難理解產品中服務調用是如何實現的了。這種復雜性和缺乏對相應知識的了解，很容易導致資源消耗的增加（CPU,內存，網絡）和性能的降低。
面具後的惡魔
如今，遠程技術使分布式應用的實現更加簡單。底層通信的細節和服務端和客戶端的基礎結構對開發人員是透明的。現在，如果要把一個Java類暴露為一個服務，有時只需要簡單的加一個注解到這個類上。服務也可以被工具生成的代理很容易的訪問。如下圖所示，但是，這僅僅是冰山的一角。
圖1.遠程協議的上層架構
遠程堆棧的核心塊是對象的序列化和傳輸的格式化。通常，應用的開發者不需要知道這些。但是，這也是很多性能問題產生的原因。效率不高的序列化意味著，通過網絡傳輸了很多不需要的數據。復雜對象的顯示和大量的數據，在序列化和反序列化期間，導致CPU和內存的使用會很高。底層的基礎架構和它的配置對應用的性能有很大的影響。在客戶端，主要是連接的管理和底層線程模型。在分布式應用中使用連接的指導方針和數據庫的連接很像。建立一個連接需要一定的時間。但這同樣要看是什麼協議。例如，建立一個HTTPS的連接的開銷要大於一個簡單的TCP/IP連接。同時，連接又是系統很重要的資源。所以，使用連接池很重要。正確的配置在這裡也很關鍵，因為錯誤的配置文件給我們帶來的壞處要多於好處。線程的模型涉及到請求如何被處理。重要的是請求是被同步還是異步處理。同步通信阻塞一個進程直到收到相應。在異步通信中，當收到響應時會調用一個回調。這就允許這個線程被其他事務使用。在服務端，可用的工作線程數量就是定義的並行處理的最大服務請求數。網絡本身也是分布式應用的一個重要組件。網絡是比影響性能更加限制其可擴展性的重要的瓶頸資源。這塊通常在開發時會被忽視，因為沒有調用實際的網絡。
遠程調用之美在於...
這有很多可以選擇，Java提供了非常多的可能性和技術來實現分布式應用。遠程技術的選擇對應用的架構、性能和擴展性有十分重要的影響。最“老的”的但是幾乎是用的最廣的遠程協議是RMI（如下圖）。
圖2.RMI架構
RMI是J2EE應用的一個標准協議。像它的名稱暗示的一樣，設計時就是為了調用遠程Java虛擬主機上的對象提供的方法。對象在服務端被暴露出來，這時客戶端就可以通過代理調用這個對象。同樣的服務端對象被多個線程使用。線程池被RMI基礎設施管理。通信通過TCP/IP被處理，並且使用JRMP或針對RMI的基於IIOP GIOP（CORBA協議）的協議。應用服務端也提供自己的屬性協議來優化其性能。如服務端的引用需要管理一樣，RMI基礎設施也提供了垃圾回收器來管理引用。這個分布式垃圾回收器（DGC）本身也使用RMI協議來管理服務器端的對象生命周期。除了客戶端和服務端很強大，RMI還有一些其他的實現。關於RMI的詳細介紹及應用請參考51CTO之前的文章《用RMI實現基於Java的分布式計算》。
RMI只支持同步通信，缺點上面已經討論過了。另外，不能為數據驅動的服務提供低級緩存，因為它是基於2進制協議的。開發人員和系統架構能夠改變基礎設施的配置參數來優化性能。JMS是J2EE平台上使用的第二多的協議。如下圖：
圖3.JMS架構圖
有別於RMI, JMS是一個異步的協議。通信是基於隊列的，以便監聽器可以對消息作出反應。JMS不是一種標准的遠程調用協議，但是它仍然能夠滿足服務與服務之間的交互。在SOA中非常重要的很多ESB的實現，就采用基於JMS的中間件來進行服務之間的信息傳遞。由於JMS是異步的，一些典型的同步問題就可以避免。在很多系統中，高可擴展性的關鍵在於能夠很快的釋放資源（像線程）。在很多情況下，異步處理是唯一合適的方法。JMS提供很多不同的傳輸格式。XML是最通用的消息格式，但二進制格式也是可能的。消息結構的設計是應用架構的一個重要部分，因為它可以直接影響到應用的性能和可擴展性。
基於SOAP的WEB Service（如下圖）和其他相關的WS-*也在Java 企業應用領域中變得越來越重要。
圖4.同步和異步SOAP架構
設計SOAP是為了替換CORBA，而且一開始就得到了業界的強烈支持。因為WS-I之間的共同努力，不同平台差不多能夠很容易的連接起來。SOAP是一種基於XML的RPC協議，所以很容易和浪費帶寬聯系到一起。
