技術Java遠程通訊的那些事兒

轉自：http://blog.sina.com.cn/s/blog_56fd58ab0100mrl6.html

 

在分布式服務架構中，一個最基礎的問題就是遠程服務是怎麼通訊的，在Java領域中有很多可實現遠程通訊的技術，例如：RMI、MINA、ESB、Burlap、Hessian、SOAP、EJB和JMS等，這些名詞之間到底是些什麼關係呢，它們背後到底是基於什麼原理實現的呢，瞭解這些是實現分布式服務架構的基礎知識，而如果在效能上有高的要求的話，那深入瞭解這些技術背後的機制就是必須的了，在這篇
blog中我們將來一探究竟，拋磚引玉，歡迎大家提供更多的實現遠程通訊的技術和原理的介紹。

基本原理
要實現網路機器間的通訊，首先得來看看電腦系統網路通訊的基本原理，在底層層面去看，網路通訊需要做的就是將流從一台電腦傳輸到另外一台電腦，基於傳輸協議和網路IO來實現，其中傳輸協議比較出名的有http、tcp、udp等等，http、tcp、udp都是在基於Socket概念上為某類應用情境而擴充出的傳輸協議，網路IO，主要有bio、nio、aio三種方式，所有的分布式應用通訊都基於這個原理而實現，只是為了應用的易用，各種語言通常都會提供一些更為貼近應用易用的應用程式層協議。

應用級協議
遠程服務通訊，需要達到的目標是在一台電腦發起請求，另外一台機器在接收到請求後進行相應的處理並將結果返回給請求端，這其中又會有諸如one way request、同步請求、非同步請求等等請求方式，按照網路通訊原理，需要實現這個需要做的就是將請求轉換成流，通過傳輸協議傳輸至遠端，遠端電腦在接收到請求的流後進行處理，處理完畢後將結果轉化為流，並通過傳輸協議返回給調用端。
原理是這樣的，但為了應用的方便，業界推出了很多基於此原理之上的應用級的協議，使得大家可以不用去直接操作這麼底層的東西，通常應用級的遠程通訊協定會提供：
1、為了避免直接做流操作這麼麻煩，提供一種更 加易用或貼合語言的標準傳輸格式；
2、網路通訊機制的實現，就是替你完成了將傳輸格式轉化為流，通過某種傳輸協議傳輸至遠端電腦，遠端電腦在接收到流後轉化為傳輸格式，並進行儲存或以某種方式通知遠端電腦。
所 以在學習應用級的遠程通訊協定時，我們可以帶著這幾個問題進行學習：
1、傳輸的標準格式是什嗎？
2、怎麼樣將請求轉化為傳輸的流？
3、 怎麼接收和處理流？
4、傳輸協議是？
不過應用級的遠程通訊協定並不會在傳輸協議上做什麼多大的改進，主要是在流操作方面，讓應用程式層產生流和處理流的這個過程更加的貼合所使用的語言或標準，至於傳輸協議則通常都是可選的，在java領域中知名的有：RMI、XML-RPC、Binary- RPC、SOAP、CORBA、JMS，來具體的看看這些遠程通訊的應用級協議：
--------------------------------------------------------------------------------------------------------------------------------------------------
RMI
RMI 是個典型的為java定製的遠程通訊協定，我們都知道，在single vm中，我們可以通過直接調用java object instance來實現通訊，那麼在遠程通訊時，如果也能按照這種方式當然是最好了，這種遠程通訊的機製成為RPC（Remote Procedure Call），RMI正是朝著這個目標而誕生的。
來看下基於RMI的一次完整的遠程通訊過程的原理：
1、用戶端發起請求，請求轉交至RMI 用戶端的stub類；
2、stub類將請求的介面、方法、參數等資訊進行序列化；
3、基於socket將序列化後的流傳輸至伺服器端；
4、伺服器端接收到流後轉寄至相應的 skelton類；
5、skelton類將請求的資訊還原序列化後調用實際的處理類；
6、處理類處理完畢後將結果返回給skelton類；
7、 Skelton類將結果序列化，通過socket將流傳送給用戶端的stub；
8、stub在接收到流後還原序列化，將還原序列化後的Java Object返回給調用者。
來看jboss-remoting對於此過程的一個更好的圖示：

根據原理來回答下之前學習應用級協議帶著的幾個問題：
1、傳輸的標準格式是什嗎？
是Java ObjectStream。
2、怎麼樣將請求轉化為傳輸的流？
基於Java序列化機制將請求的java object資訊轉化為流。
3、怎麼接收和處理流？
根據採用的協議啟動相應的監聽連接埠，當有流進入後基於Java序列化機制將流進行還原序列化，並根據RMI協議擷取到相應的處理對象資訊，進行調用並處理，處理完畢後的結果同樣基於java序列化機制進行返回。
4、傳輸協議是？
Socket。
--------------------------------------------------------------------------------------------------------------------------------------------------
XML-RPC
XML- RPC也是一種和RMI類似的遠程調用的協議，它和RMI的不同之處在於它以標準的xml格式來定義請求的資訊(請求的對象、方法、參數等)，這樣的好處是什麼呢，就是在跨語言通訊的時候也可以使用。
來看下XML-RPC協議的一次遠程通訊過程：
1、用戶端發起請求，按照XML-RPC協 議將請求資訊進行填充；
2、填充完畢後將xml轉化為流，通過傳輸協議進行傳輸；
3、接收到在接收到流後轉換為xml，按照XML- RPC協議擷取請求的資訊並進行處理；
4、處理完畢後將結果按照XML-RPC協議寫入xml中並返回。
圖示以上過程：

同樣來回答問題：
1、傳輸的標準格式是？
標準格式的XML。
2、怎麼樣將請求轉化為傳輸的流？
將XML轉化為流。
3、怎麼接收和處理流？
通過監聽的連接埠擷取到請求的流，轉化為XML，並根據協議擷取請求的資訊，進行處理並將結果寫入XML中返回。
4、傳輸協議是？
Http。
--------------------------------------------------------------------------------------------------------------------------------------------------
Binary-RPC
Binary- RPC看名字就知道和XML-RPC是差不多的了，不同之處僅在於傳輸的標準格式由XML轉為了二進位的格式。
同樣來回答問題：
1、傳輸 的標準格式是？
標準格式的二進位檔案。
2、怎麼樣將請求轉化為傳輸的流？
將二進位格式檔案轉化為流。
3、 怎麼接收和處理流？
通過監聽的連接埠擷取到請求的流，轉化為二進位檔案，根據協議擷取請求的資訊，進行處理並將結果寫入XML中返回。
4、 傳輸協議是？
Http。
--------------------------------------------------------------------------------------------------------------------------------------------------
SOAP
SOAP 原意為Simple Object Access Protocol，是一個用於分布式環境的、輕量級的、基於XML進行資訊交換的通訊協定，可以認為SOAP是XML RPC的進階版，兩者的原理完全相同，都是http+XML，不同的僅在於兩者定義的XML規範不同，SOAP也是Webservice採用的服務調用協議標準，因此在此就不多加闡述了。
--------------------------------------------------------------------------------------------------------------------------------------------------
CORBA
Common Object Request Broker Architecture（公用對象請求代理[調度]程式體繫結構），是一組用來定義“分布式對象系統”的標準，由OMG(Object Menagement Group)作為發起和標準制定單位。CORBA的目的是定義一套協議，符合這個協議的對象可以互相互動，不論它們是用什麼樣的語言寫的，不論它們運行於什麼樣的機器和作業系統。
CORBA在我看來是個類似於SOA的體系架構，涵蓋可選的遠程通訊協定，但其本身不能列入通訊協定這裡來講，而且 CORBA基本淘汰，再加上對CORBA也不怎麼懂，在此就不進行闡述了。
--------------------------------------------------------------------------------------------------------------------------------------------------
JMS
JMS 呢，是實現java領域遠程通訊的一種手段和方法，基於JMS實現遠程通訊時和RPC是不同的，雖然可以做到RPC的效果，但因為不是從協議層級定義的，因此我們不認為JMS是個RPC協議，但它確實是個遠程通訊協定，在其他的語言體系中也存在著類似JMS的東西，可以統一的將這類機制稱為訊息機制，而訊息機制呢，通常是高並發、分布式領域推薦的一種通訊機制，這裡的主要一個問題是容錯（詳細見ErLang論文）。
來看JMS中的一次遠程通訊的過 程：
1、用戶端將請求轉化為符合JMS規定的Message；
2、通過JMS API將Message放入JMS Queue或Topic中；
3、如為JMS Queue，則發送中相應的目標Queue中，如為Topic，則發送給訂閱了此Topic的JMS Queue。
4、處理端則通過輪訓JMS Queue，來擷取訊息，接收到訊息後根據JMS協議來解析Message並處理。
回答問 題：
1、傳輸的標準格式是？
JMS規定的Message。
2、怎麼樣將請求轉化為傳輸的流？
將參數資訊放入Message中即可。
3、怎麼接收和處理流？
輪訓JMS Queue來接收Message，接收到後進行處理，處理完畢後仍然是以Message的方式放入Queue中發送或Multicast。
4、傳 輸協議是？
不限。
基於JMS也是常用的實現遠程非同步呼叫的方法之一。

可選實現技術
當然，在上面的原理中並沒有介紹到所有的java領域可選的遠程通訊協定了，例如還有EJB採用的ORMI、Spring自己定義的一個簡單的Http Invoker等等。
看完原理後我們再來看看目前java領域可用於實現遠程通訊的架構或library，知名的有：JBoss-Remoting、Spring-Remoting、Hessian、Burlap、XFire(Axis)、ActiveMQ、 Mina、Mule、EJB3等等，來對每種做個簡單的介紹和評價，其實呢，要做分布式服務架構，這些東西都是要有非常深刻的瞭解的，因為分布式服務架構其實是包含瞭解決分布式領域以及應用程式層面領域兩方面問題的。
當然，你也可以自己根據遠程網路通訊原理(transport protocol+Net IO)去實現自己的通訊架構或library。
那麼在瞭解這些遠程通訊的架構或library時，會帶著什麼問題去學 習呢？
1、是基於什麼協議實現的？
2、怎麼發起請求？
3、怎麼將請求轉化為符合協議的格式的？
4、使用什麼傳輸協議傳 輸？
5、響應端基於什麼機制來接收請求？
6、怎麼將流還原為傳輸格式的？
7、處理完畢後怎麼回應？
--------------------------------------------------------------------------------------------------------------------------------------------------
JBoss-Remoting
Jboss- remoting是由jboss編寫的一個java領域的遠程通訊架構，基於此架構，可以很簡單的實現基於多種傳輸協議的java對象的RPC。
直 接來回答問題：
1、是基於什麼協議實現的？
JBoss-Remoting是個通訊架構，因此它支援多種協議方式的通訊，例如純粹的socket+io方式、rmi方式、http+io方式等。
2、 怎麼發起請求？
在JBoss-Remoting中，只需將需要發起的請求參數對象傳入jboss-remoting的InvocationRequest對象即可，也可根據協議基於InvocationRequest封裝符合需求的InvocationRequest對象。
3、怎麼將請求轉化為符合協議的格式 的？
JBoss-Remoting基於Java序列化機制或JBoss自己的序列化實現來將請求轉化為對象位元組流。
4、使用 什麼傳輸協議傳輸？
支援多種傳輸協議，例如socket、http等。
5、響應端基於什麼機制來接收請求？
響應端只需將自己的處理對象註冊到JBoss-Remoting提供的server端的Connector對象中即可。
6、怎麼將流還原為傳輸 格式的？
JBoss-Remoting基於java序列化機制或jboss自己的序列化實現來將請求資訊還原為java對象。
7、 處理完畢後怎麼回應？
處理完畢後將結果對象直接返回即可，jboss-remoting會將此對象按照協議進行序列化，返回至調用端。
另外，jboss- remoting支援多種通訊方式，例如同步/非同步/單向通訊等。

--------------------------------------------------------------------------------------------------------------------------------------------------
Spring-Remoting
Spring- remoting是Spring提供java領域的遠程通訊架構，基於此架構，同樣也可以很簡單的將普通的spring bean以某種遠程協議的方式來發布，同樣也可以配置spring bean為遠程調用的bean。
1、是基於什麼協議實現的？
和JBoss-Remoting一樣，作為一個遠程通訊的架構，Spring通過整合多種遠程通訊的library，從而實現了對多種協議的支援，例如 rmi、http+io、xml-rpc、binary-rpc等。
2、怎麼發起請求？
在Spring中，由於其對於遠程調用的bean採用的是proxy實現，發起請求完全是通過服務介面調用的方式。
3、怎麼將請求轉化為符合協議 的格式的？
Spring按照協議方式將請求的對象資訊轉化為流，例如Spring Http Invoker是基於Spring自己定義的一個協議來實現的，傳輸協議上採用的為http，請求資訊是基於java序列化機制轉化為流進行傳輸。
4、 使用什麼傳輸協議傳輸？
支援多種傳輸協議，例如rmi、http等等。
5、響應端基於什麼機制來接收請求？
響應端遵循協議方式來接收請求，對於使用者而言，則只需通過spring的配置方式將普通的spring bean配置為響應端或者說提供服務端。
6、 怎麼將流還原為傳輸格式的？
按照協議方式來進行還原。
7、處理完畢後怎麼回應？
處理完畢後直接返回即可，spring-remoting將根據協議方式來做相應的序列化。

--------------------------------------------------------------------------------------------------------------------------------------------------
Hessian
Hessian 是由caucho提供的一個基於binary-RPC實現的遠程通訊library。
1、是基於什麼協議實現的？
基於Binary-RPC協議實現。
2、怎麼發起請求？
需通過Hessian本身提供的API來發起請求。
3、怎麼 將請求轉化為符合協議的格式的？
Hessian通過其自訂的序列化機制將請求資訊進行序列化，產生二進位流。
4、使用什麼 傳輸協議傳輸？
Hessian基於Http協議進行傳輸。
5、響應端基於什麼機制來接收請求？
響應端根據Hessian提供的API來接收請求。
6、怎麼將流還原為傳輸格式的？
Hessian根據其私人的序列化機制來將請求資訊進行還原序列化，傳遞給使用者時已是相應的請求資訊對象了。
7、處理完畢後怎麼回應？
處理完畢後直接返回，hessian將結果對象進行序列化，傳輸至調用端。

--------------------------------------------------------------------------------------------------------------------------------------------------
Burlap
Burlap 也是有caucho提供，它和hessian的不同在於，它是基於XML-RPC協議的。
1、是基於什麼協議實現的？
基於XML-RPC協議實現。
2、怎麼發起請求？
根據Burlap提供的API。
3、怎麼將請求轉化為符合協議的格 式的？
將請求資訊轉化為符合協議的XML格式，轉化為流進行傳輸。
4、使用什麼傳輸協議傳輸？
Http協議。
5、響應端基於什麼機制來接收請求？
監聽Http請求。
6、怎麼將流還原為傳輸格式的？
根據XML-RPC協議進行還原。
7、處理完畢後怎麼回應？
返回結果寫入XML中，由Burlap返回至調用端。

--------------------------------------------------------------------------------------------------------------------------------------------------
XFire、 Axis
XFire、Axis是Webservice的實現架構，WebService可算是一個完整的SOA架構實現標準了，因此採用 XFire、Axis這些也就意味著是採用webservice方式了。
1、是基於什麼協議實現的？
基於SOAP協議。
2、 怎麼發起請求？
擷取到遠端service的proxy後直接調用。
3、怎麼將請求轉化為符合協議的格式的？
將請求資訊轉化為遵循SOAP協議的XML格式，由架構轉化為流進行傳輸。
4、使用什麼傳輸協議傳輸？
Http協議。
5、 響應端基於什麼機制來接收請求？
監聽Http請求。
6、怎麼將流還原為傳輸格式的？
根據SOAP協議進行還原。
7、處理完畢後怎麼回應？
返回結果寫入XML中，由架構返回至調用端。

--------------------------------------------------------------------------------------------------------------------------------------------------
ActiveMQ
ActiveMQ 是JMS的實現，基於JMS這類訊息機制實現遠程通訊是一種不錯的選擇，畢竟訊息機制本身的功能使得基於它可以很容易的去實現同步/非同步/單向調用等，而且訊息機制從容錯角度上來說也是個不錯的選擇，這是Erlang能夠做到容錯的重要基礎。
1、是基於什麼協議實現的？
基於JMS協議。
2、怎麼發起請求？
遵循JMS API發起請求。
3、怎麼將請求轉化為符合協議的格式的？
不太清楚，猜想應該是二進位流。
4、使用什麼傳輸協議傳輸？
支援多種傳輸協議，例如socket、http等等。
5、 響應端基於什麼機制來接收請求？
監聽符合協議的連接埠。
6、怎麼將流還原為傳輸格式的？
同問題3。
7、 處理完畢後怎麼回應？
遵循JMS API產生訊息，並寫入JMS Queue中。
基於JMS此類機制實現遠程通訊的例子有 Spring-Intergration、Mule、Lingo等等。

--------------------------------------------------------------------------------------------------------------------------------------------------
Mina
Mina 是Apache提供的通訊架構，在之前一直沒有提到網路IO這塊，之前提及的架構或library基本都是基於BIO的，而Mina是採用NIO 的，NIO在並發量增長時對比BIO而言會有明顯的效能提升，而java效能的提升，與其NIO這塊與OS的緊密結合是有不小的關係的。
1、是基 於什麼協議實現的？
基於純粹的Socket+NIO。
2、怎麼發起請求？
通過Mina提供的Client API。
3、怎麼將請求轉化為符合協議的格式的？
Mina遵循java序列化機制對請求對象進行序列化。
4、使用什麼傳輸協議傳輸？
支援多種傳輸協議，例如socket、http等等。
5、響應端基於什麼機制來接收請求？
以NIO的方式監聽協議連接埠。
6、 怎麼將流還原為傳輸格式的？
遵循java序列化機制對請求對象進行還原序列化。
7、處理完畢後怎麼回應？
遵循Mina API進行返回。
MINA是NIO方式的，因此支援非同步呼叫是毫無懸念的。

--------------------------------------------------------------------------------------------------------------------------------------------------
EJB
EJB 最突出的在於其分布式，EJB採用的是ORMI協議，和RMI協議是差不多的，但EJB在分布式通訊的安全控制、transport pool、smart proxy等方面的突出使得其在分布式領域是不可忽視的力量。
1、是基於什麼協議實現的？
基於ORMI協議。
2、怎 麼發起請求？
EJB調用。
3、怎麼將請求轉化為符合協議的格式的？
遵循java序列化機制對請求對象進行序列化。
4、使用什麼傳輸協議傳輸？
Socket。
5、響應端基於什麼機制來 接收請求？
監聽協議連接埠。
6、怎麼將流還原為傳輸格式的？
遵循java序列化機制對請求對象進行還原序列化。
7、處理完畢後怎麼回應？
直接返回處理對象即可。

在之前的分布式服務架構系列的文章中對於jndi有誤導的嫌疑，在這篇blog中也順帶的提下jndi的機制，由於JNDI取決於具體的實現，在這裡只能是講解下jboss的jndi的實現了。
在將對象執行個體綁定到jboss jnp server後，當遠程端採用context.lookup()方式擷取遠程對象執行個體並開始調用時，jboss jndi的實現方法是從jnp server上擷取對象執行個體，將其序列化回本地，然後在本地進行還原序列化，之後在本地進行類調用。
通過這個機制，就可以知道了，本地其實是必須有綁定到jboss上的對象執行個體的class的，否則還原序列化的時候肯定就失敗了，而遠程通訊需要做到的是在遠程執行某動作，並擷取到相應的結果，可見純粹基於JNDI是無法實現遠程通訊的。
但JNDI也是實現分布式服務架構一個很關鍵的技術點，因為可以通過它來實現透明化的遠端和本地調用，就像 ejb，另外它也是個很好的隱藏實際部署機制(就像datasource)等的方案。

總結
由上一系列的分析可知，在遠程通訊領域中，涉及的知識點還是相當的多的，例如有：通訊協定(Socket/tcp/http/udp /rmi/xml-rpc etc.)、訊息機制、網路IO（BIO/NIO/AIO）、MultiThread、本地調用與遠程調用的透明化方案（涉及java classloader、Dynamic Proxy、Unit Test etc.）、非同步與同步調用、網路通訊處理機制（自動重連、廣播、異常、池處理等等）、Java Serialization (各種協議的私人序列化機制等)、各種架構的實現原理（傳輸格式、如何將傳輸格式轉化為流的、如何將請求資訊轉化為傳輸格式的、如何接收流的、如何將流還原為傳輸格式的等等），要精通其中的哪些東西，得根據實際需求來決定了，只有在瞭解了原理的情況下才能很容易的做出選擇，甚至可以根據需求做私人的遠程通訊協議，對於從事分布式服務平台或開發較大型的分布式應用的人而言，我覺得至少上面提及的知識點是需要比較瞭解的。

相關參考：
1.       《
Java 遠程通訊可選技術及原理》
http://java.chinaitlab.com/base/740383.html

 

2.      
《 Hessian-3.2.0 源碼》

3.      
《 hessian 序列化實現初探》 http://www.javaeye.com/topic/245238