Refer To：http://ihyperwin.iteye.com/blog/1627794
在分布式服務(wù)框架中，一個最基礎(chǔ)的問題就是遠程服務(wù)是怎么通訊的，在Java領(lǐng)域中有很多可實現(xiàn)遠程通訊的技術(shù)，例如：RMI、MINA、ESB、Burlap、Hessian、SOAP、EJB和JMS等，這些名詞之間到底是些什么關(guān)系呢，它們背后到底是基于什么原理實現(xiàn)的呢，了解這些是實現(xiàn)分布式服務(wù)框架的基礎(chǔ)知識，而如果在性能上有高的要求的話，那深入了解這些技術(shù)背后的機制就是必須的了，在這篇 blog中我們將來一探究竟，拋磚引玉，歡迎大家提供更多的實現(xiàn)遠程通訊的技術(shù)和原理的介紹。 基本原理 要實現(xiàn)網(wǎng)絡(luò)機器間的通訊，首先得來看看計算機系統(tǒng)網(wǎng)絡(luò)通信的基本原理，在底層層面去看，網(wǎng)絡(luò)通信需要做的就是將流從一臺計算機傳輸?shù)搅硗庖慌_計算機，基于傳輸協(xié)議和網(wǎng)絡(luò)IO來實現(xiàn)，其中傳輸協(xié)議比較出名的有http、tcp、udp等等，http、tcp、udp都是在基于Socket概念上為某類應(yīng)用場景而擴展出的傳輸協(xié)議，網(wǎng)絡(luò)IO，主要有bio、nio、aio三種方式，所有的分布式應(yīng)用通訊都基于這個原理而實現(xiàn)，只是為了應(yīng)用的易用，各種語言通常都會提供一些更為貼近應(yīng)用易用的應(yīng)用層協(xié)議。 應(yīng)用級協(xié)議 遠程服務(wù)通訊，需要達到的目標是在一臺計算機發(fā)起請求，另外一臺機器在接收到請求后進行相應(yīng)的處理并將結(jié)果返回給請求端，這其中又會有諸如one way request、同步請求、異步請求等等請求方式，按照網(wǎng)絡(luò)通信原理，需要實現(xiàn)這個需要做的就是將請求轉(zhuǎn)換成流，通過傳輸協(xié)議傳輸至遠端，遠端計算機在接收到請求的流后進行處理，處理完畢后將結(jié)果轉(zhuǎn)化為流，并通過傳輸協(xié)議返回給調(diào)用端。 原理是這樣的，但為了應(yīng)用的方便，業(yè)界推出了很多基于此原理之上的應(yīng)用級的協(xié)議，使得大家可以不用去直接操作這么底層的東西，通常應(yīng)用級的遠程通信協(xié)議會提供： 1、為了避免直接做流操作這么麻煩，提供一種更 加易用或貼合語言的標準傳輸格式； 2、網(wǎng)絡(luò)通信機制的實現(xiàn)，就是替你完成了將傳輸格式轉(zhuǎn)化為流，通過某種傳輸協(xié)議傳輸至遠端計算機，遠端計算機在接收到流后轉(zhuǎn)化為傳輸格式，并進行存儲或以某種方式通知遠端計算機。 所 以在學習應(yīng)用級的遠程通信協(xié)議時，我們可以帶著這幾個問題進行學習： 1、傳輸?shù)臉藴矢袷绞鞘裁矗?nbsp;2、怎么樣將請求轉(zhuǎn)化為傳輸?shù)牧鳎?nbsp;3、 怎么接收和處理流？ 4、傳輸協(xié)議是？ 不過應(yīng)用級的遠程通信協(xié)議并不會在傳輸協(xié)議上做什么多大的改進，主要是在流操作方面，讓應(yīng)用層生成流和處理流的這個過程更加的貼合所使用的語言或標準，至于傳輸協(xié)議則通常都是可選的，在java領(lǐng)域中知名的有：RMI、XML-RPC、Binary- RPC、SOAP、CORBA、JMS，來具體的看看這些遠程通信的應(yīng)用級協(xié)議： -------------------------------------------------------------------------------------------------------------------------------------------------- RMI RMI 是個典型的為java定制的遠程通信協(xié)議，我們都知道，在single vm中，我們可以通過直接調(diào)用java object instance來實現(xiàn)通信，那么在遠程通信時，如果也能按照這種方式當然是最好了，這種遠程通信的機制成為RPC（Remote Procedure Call），RMI正是朝著這個目標而誕生的。 來看下基于RMI的一次完整的遠程通信過程的原理： 1、客戶端發(fā)起請求，請求轉(zhuǎn)交至RMI 客戶端的stub類； 2、stub類將請求的接口、方法、參數(shù)等信息進行序列化； 3、基于socket將序列化后的流傳輸至服務(wù)器端； 4、服務(wù)器端接收到流后轉(zhuǎn)發(fā)至相應(yīng)的 skelton類； 5、skelton類將請求的信息反序列化后調(diào)用實際的處理類； 6、處理類處理完畢后將結(jié)果返回給skelton類； 7、 Skelton類將結(jié)果序列化，通過socket將流傳送給客戶端的stub； 8、stub在接收到流后反序列化，將反序列化后的Java Object返回給調(diào)用者。 來看jboss-remoting對于此過程的一個更好的圖示： 
根據(jù)原理來回答下之前學習應(yīng)用級協(xié)議帶著的幾個問題： 1、傳輸?shù)臉藴矢袷绞鞘裁矗?nbsp;是Java ObjectStream。 2、怎么樣將請求轉(zhuǎn)化為傳輸?shù)牧鳎?nbsp;基于Java串行化機制將請求的java object信息轉(zhuǎn)化為流。 3、怎么接收和處理流？ 根據(jù)采用的協(xié)議啟動相應(yīng)的監(jiān)聽端口，當有流進入后基于Java串行化機制將流進行反序列化，并根據(jù)RMI協(xié)議獲取到相應(yīng)的處理對象信息，進行調(diào)用并處理，處理完畢后的結(jié)果同樣基于java串行化機制進行返回。 4、傳輸協(xié)議是？ Socket。 -------------------------------------------------------------------------------------------------------------------------------------------------- XML-RPC XML- RPC也是一種和RMI類似的遠程調(diào)用的協(xié)議，它和RMI的不同之處在于它以標準的xml格式來定義請求的信息(請求的對象、方法、參數(shù)等)，這樣的好處是什么呢，就是在跨語言通訊的時候也可以使用。 來看下XML-RPC協(xié)議的一次遠程通信過程： 1、客戶端發(fā)起請求，按照XML-RPC協(xié) 議將請求信息進行填充； 2、填充完畢后將xml轉(zhuǎn)化為流，通過傳輸協(xié)議進行傳輸； 3、接收到在接收到流后轉(zhuǎn)換為xml，按照XML- RPC協(xié)議獲取請求的信息并進行處理； 4、處理完畢后將結(jié)果按照XML-RPC協(xié)議寫入xml中并返回。 圖示以上過程： 
同樣來回答問題： 1、傳輸?shù)臉藴矢袷绞牵?nbsp;標準格式的XML。 2、怎么樣將請求轉(zhuǎn)化為傳輸?shù)牧鳎?nbsp;將XML轉(zhuǎn)化為流。 3、怎么接收和處理流？ 通過監(jiān)聽的端口獲取到請求的流，轉(zhuǎn)化為XML，并根據(jù)協(xié)議獲取請求的信息，進行處理并將結(jié)果寫入XML中返回。4、傳輸協(xié)議是？ Http。 -------------------------------------------------------------------------------------------------------------------------------------------------- Binary-RPC Binary- RPC看名字就知道和XML-RPC是差不多的了，不同之處僅在于傳輸?shù)臉藴矢袷接蒟ML轉(zhuǎn)為了二進制的格式。 同樣來回答問題： 1、傳輸 的標準格式是？ 標準格式的二進制文件。 2、怎么樣將請求轉(zhuǎn)化為傳輸?shù)牧鳎?nbsp;將二進制格式文件轉(zhuǎn)化為流。 3、 怎么接收和處理流？ 通過監(jiān)聽的端口獲取到請求的流，轉(zhuǎn)化為二進制文件，根據(jù)協(xié)議獲取請求的信息，進行處理并將結(jié)果寫入二進制文件中返回。 4、 傳輸協(xié)議是？ Http。 -------------------------------------------------------------------------------------------------------------------------------------------------- SOAP SOAP 原意為Simple Object Access Protocol，是一個用于分布式環(huán)境的、輕量級的、基于XML進行信息交換的通信協(xié)議，可以認為SOAP是XML RPC的高級版，兩者的原理完全相同，都是http+XML，不同的僅在于兩者定義的XML規(guī)范不同，SOAP也是Webservice采用的服務(wù)調(diào)用協(xié)議標準，因此在此就不多加闡述了。 -------------------------------------------------------------------------------------------------------------------------------------------------- CORBA Common Object Request Broker Architecture（公用對象請求代理[調(diào)度]程序體系結(jié)構(gòu)），是一組用來定義“分布式對象系統(tǒng)”的標準，由OMG(Object Menagement Group)作為發(fā)起和標準制定單位。CORBA的目的是定義一套協(xié)議，符合這個協(xié)議的對象可以互相交互，不論它們是用什么樣的語言寫的，不論它們運行于什么樣的機器和操作系統(tǒng)。 CORBA在我看來是個類似于SOA的體系架構(gòu)，涵蓋可選的遠程通信協(xié)議，但其本身不能列入通信協(xié)議這里來講，而且 CORBA基本淘汰，再加上對CORBA也不怎么懂，在此就不進行闡述了。 -------------------------------------------------------------------------------------------------------------------------------------------------- JMS JMS 呢，是實現(xiàn)java領(lǐng)域遠程通信的一種手段和方法，基于JMS實現(xiàn)遠程通信時和RPC是不同的，雖然可以做到RPC的效果，但因為不是從協(xié)議級別定義的，因此我們不認為JMS是個RPC協(xié)議，但它確實是個遠程通信協(xié)議，在其他的語言體系中也存在著類似JMS的東西，可以統(tǒng)一的將這類機制稱為消息機制，而消息機制呢，通常是高并發(fā)、分布式領(lǐng)域推薦的一種通信機制，這里的主要一個問題是容錯（詳細見ErLang論文）。 來看JMS中的一次遠程通信的過 程： 1、客戶端將請求轉(zhuǎn)化為符合JMS規(guī)定的Message； 2、通過JMS API將Message放入JMS Queue或Topic中； 3、如為JMS Queue，則發(fā)送中相應(yīng)的目標Queue中，如為Topic，則發(fā)送給訂閱了此Topic的JMS Queue。 4、處理端則通過輪訓JMS Queue，來獲取消息，接收到消息后根據(jù)JMS協(xié)議來解析Message并處理。 回答問 題： 1、傳輸?shù)臉藴矢袷绞牵?nbsp;JMS規(guī)定的Message。 2、怎么樣將請求轉(zhuǎn)化為傳輸?shù)牧鳎?nbsp;將參數(shù)信息放入Message中即可。 3、怎么接收和處理流？ 輪訓JMS Queue來接收Message，接收到后進行處理，處理完畢后仍然是以Message的方式放入Queue中發(fā)送或Multicast。 4、傳 輸協(xié)議是？ 不限。 基于JMS也是常用的實現(xiàn)遠程異步調(diào)用的方法之一。 可選實現(xiàn)技術(shù) 當然，在上面的原理中并沒有介紹到所有的java領(lǐng)域可選的遠程通信協(xié)議了，例如還有EJB采用的ORMI、Spring自己定義的一個簡單的Http Invoker等等。 看完原理后我們再來看看目前java領(lǐng)域可用于實現(xiàn)遠程通訊的框架或library，知名的有：JBoss-Remoting、Spring-Remoting、Hessian、Burlap、XFire(Axis)、ActiveMQ、 Mina、Mule、EJB3等等，來對每種做個簡單的介紹和評價，其實呢，要做分布式服務(wù)框架，這些東西都是要有非常深刻的了解的，因為分布式服務(wù)框架其實是包含了解決分布式領(lǐng)域以及應(yīng)用層面領(lǐng)域兩方面問題的。 當然，你也可以自己根據(jù)遠程網(wǎng)絡(luò)通信原理(transport protocol+Net IO)去實現(xiàn)自己的通訊框架或library。 那么在了解這些遠程通訊的框架或library時，會帶著什么問題去學 習呢？ 1、是基于什么協(xié)議實現(xiàn)的？ 2、怎么發(fā)起請求？ 3、怎么將請求轉(zhuǎn)化為符合協(xié)議的格式的？ 4、使用什么傳輸協(xié)議傳 輸？ 5、響應(yīng)端基于什么機制來接收請求？ 6、怎么將流還原為傳輸格式的？ 7、處理完畢后怎么回應(yīng)？ -------------------------------------------------------------------------------------------------------------------------------------------------- JBoss-Remoting Jboss- remoting是由jboss編寫的一個java領(lǐng)域的遠程通訊框架，基于此框架，可以很簡單的實現(xiàn)基于多種傳輸協(xié)議的java對象的RPC。 直 接來回答問題： 1、是基于什么協(xié)議實現(xiàn)的？ JBoss-Remoting是個通訊框架，因此它支持多種協(xié)議方式的通信，例如純粹的socket+io方式、rmi方式、http+io方式等。 2、 怎么發(fā)起請求？ 在JBoss-Remoting中，只需將需要發(fā)起的請求參數(shù)對象傳入jboss-remoting的InvocationRequest對象即可，也可根據(jù)協(xié)議基于InvocationRequest封裝符合需求的InvocationRequest對象。 3、怎么將請求轉(zhuǎn)化為符合協(xié)議的格式 的？ JBoss-Remoting基于Java串行化機制或JBoss自己的串行化實現(xiàn)來將請求轉(zhuǎn)化為對象字節(jié)流。 4、使用 什么傳輸協(xié)議傳輸？ 支持多種傳輸協(xié)議，例如socket、http等。 5、響應(yīng)端基于什么機制來接收請求？ 響應(yīng)端只需將自己的處理對象注冊到JBoss-Remoting提供的server端的Connector對象中即可。 6、怎么將流還原為傳輸 格式的？ JBoss-Remoting基于java串行化機制或jboss自己的串行化實現(xiàn)來將請求信息還原為java對象。 7、 處理完畢后怎么回應(yīng)？ 處理完畢后將結(jié)果對象直接返回即可，jboss-remoting會將此對象按照協(xié)議進行序列化，返回至調(diào)用端。 另外，jboss- remoting支持多種通信方式，例如同步/異步/單向通信等。 -------------------------------------------------------------------------------------------------------------------------------------------------- Spring-Remoting Spring- remoting是Spring提供java領(lǐng)域的遠程通訊框架，基于此框架，同樣也可以很簡單的將普通的spring bean以某種遠程協(xié)議的方式來發(fā)布，同樣也可以配置spring bean為遠程調(diào)用的bean。 1、是基于什么協(xié)議實現(xiàn)的？ 和JBoss-Remoting一樣，作為一個遠程通訊的框架，Spring通過集成多種遠程通訊的library，從而實現(xiàn)了對多種協(xié)議的支持，例如 rmi、http+io、xml-rpc、binary-rpc等。 2、怎么發(fā)起請求？ 在Spring中，由于其對于遠程調(diào)用的bean采用的是proxy實現(xiàn)，發(fā)起請求完全是通過服務(wù)接口調(diào)用的方式。 3、怎么將請求轉(zhuǎn)化為符合協(xié)議 的格式的？ Spring按照協(xié)議方式將請求的對象信息轉(zhuǎn)化為流，例如Spring Http Invoker是基于Spring自己定義的一個協(xié)議來實現(xiàn)的，傳輸協(xié)議上采用的為http，請求信息是基于java串行化機制轉(zhuǎn)化為流進行傳輸。 4、 使用什么傳輸協(xié)議傳輸？ 支持多種傳輸協(xié)議，例如rmi、http等等。 5、響應(yīng)端基于什么機制來接收請求？ 響應(yīng)端遵循協(xié)議方式來接收請求，對于使用者而言，則只需通過spring的配置方式將普通的spring bean配置為響應(yīng)端或者說提供服務(wù)端。 6、 怎么將流還原為傳輸格式的？ 按照協(xié)議方式來進行還原。 7、處理完畢后怎么回應(yīng)？ 處理完畢后直接返回即可，spring-remoting將根據(jù)協(xié)議方式來做相應(yīng)的序列化。 -------------------------------------------------------------------------------------------------------------------------------------------------- Hessian Hessian 是由caucho提供的一個基于binary-RPC實現(xiàn)的遠程通訊library。 1、是基于什么協(xié)議實現(xiàn)的？ 基于Binary-RPC協(xié)議實現(xiàn)。 2、怎么發(fā)起請求？ 需通過Hessian本身提供的API來發(fā)起請求。 3、怎么 將請求轉(zhuǎn)化為符合協(xié)議的格式的？ Hessian通過其自定義的串行化機制將請求信息進行序列化，產(chǎn)生二進制流。 4、使用什么 傳輸協(xié)議傳輸？ Hessian基于Http協(xié)議進行傳輸。 5、響應(yīng)端基于什么機制來接收請求？ 響應(yīng)端根據(jù)Hessian提供的API來接收請求。 6、怎么將流還原為傳輸格式的？ Hessian根據(jù)其私有的串行化機制來將請求信息進行反序列化，傳遞給使用者時已是相應(yīng)的請求信息對象了。 7、處理完畢后怎么回應(yīng)？ 處理完畢后直接返回，hessian將結(jié)果對象進行序列化，傳輸至調(diào)用端。 -------------------------------------------------------------------------------------------------------------------------------------------------- Burlap Burlap 也是有caucho提供，它和hessian的不同在于，它是基于XML-RPC協(xié)議的。 1、是基于什么協(xié)議實現(xiàn)的？ 基于XML-RPC協(xié)議實現(xiàn)。 2、怎么發(fā)起請求？ 根據(jù)Burlap提供的API。 3、怎么將請求轉(zhuǎn)化為符合協(xié)議的格 式的？ 將請求信息轉(zhuǎn)化為符合協(xié)議的XML格式，轉(zhuǎn)化為流進行傳輸。 4、使用什么傳輸協(xié)議傳輸？ Http協(xié)議。 5、響應(yīng)端基于什么機制來接收請求？ 監(jiān)聽Http請求。 6、怎么將流還原為傳輸格式的？ 根據(jù)XML-RPC協(xié)議進行還原。 7、處理完畢后怎么回應(yīng)？ 返回結(jié)果寫入XML中，由Burlap返回至調(diào)用端。 -------------------------------------------------------------------------------------------------------------------------------------------------- XFire、 Axis XFire、Axis是Webservice的實現(xiàn)框架，WebService可算是一個完整的SOA架構(gòu)實現(xiàn)標準了，因此采用 XFire、Axis這些也就意味著是采用webservice方式了。 1、是基于什么協(xié)議實現(xiàn)的？ 基于SOAP協(xié)議。 2、 怎么發(fā)起請求？ 獲取到遠端service的proxy后直接調(diào)用。 3、怎么將請求轉(zhuǎn)化為符合協(xié)議的格式的？ 將請求信息轉(zhuǎn)化為遵循SOAP協(xié)議的XML格式，由框架轉(zhuǎn)化為流進行傳輸。 4、使用什么傳輸協(xié)議傳輸？ Http協(xié)議。 5、 響應(yīng)端基于什么機制來接收請求？ 監(jiān)聽Http請求。 6、怎么將流還原為傳輸格式的？ 根據(jù)SOAP協(xié)議進行還原。 7、處理完畢后怎么回應(yīng)？ 返回結(jié)果寫入XML中，由框架返回至調(diào)用端。 -------------------------------------------------------------------------------------------------------------------------------------------------- ActiveMQ ActiveMQ 是JMS的實現(xiàn)，基于JMS這類消息機制實現(xiàn)遠程通訊是一種不錯的選擇，畢竟消息機制本身的功能使得基于它可以很容易的去實現(xiàn)同步/異步/單向調(diào)用等，而且消息機制從容錯角度上來說也是個不錯的選擇，這是Erlang能夠做到容錯的重要基礎(chǔ)。 1、是基于什么協(xié)議實現(xiàn)的？ 基于JMS協(xié)議。 2、怎么發(fā)起請求？ 遵循JMS API發(fā)起請求。 3、怎么將請求轉(zhuǎn)化為符合協(xié)議的格式的？ 不太清楚，猜想應(yīng)該是二進制流。 4、使用什么傳輸協(xié)議傳輸？ 支持多種傳輸協(xié)議，例如socket、http等等。 5、 響應(yīng)端基于什么機制來接收請求？ 監(jiān)聽符合協(xié)議的端口。 6、怎么將流還原為傳輸格式的？ 同問題3。 7、 處理完畢后怎么回應(yīng)？ 遵循JMS API生成消息，并寫入JMS Queue中。 基于JMS此類機制實現(xiàn)遠程通訊的例子有 Spring-Intergration、Mule、Lingo等等。 -------------------------------------------------------------------------------------------------------------------------------------------------- Mina Mina 是Apache提供的通訊框架，在之前一直沒有提到網(wǎng)絡(luò)IO這塊，之前提及的框架或library基本都是基于BIO的，而Mina是采用NIO 的，NIO在并發(fā)量增長時對比BIO而言會有明顯的性能提升，而java性能的提升，與其NIO這塊與OS的緊密結(jié)合是有不小的關(guān)系的。 1、是基 于什么協(xié)議實現(xiàn)的？ 基于純粹的Socket+NIO。 2、怎么發(fā)起請求？ 通過Mina提供的Client API。 3、怎么將請求轉(zhuǎn)化為符合協(xié)議的格式的？ Mina遵循java串行化機制對請求對象進行序列化。 4、使用什么傳輸協(xié)議傳輸？ 支持多種傳輸協(xié)議，例如socket、http等等。 5、響應(yīng)端基于什么機制來接收請求？ 以NIO的方式監(jiān)聽協(xié)議端口。 6、 怎么將流還原為傳輸格式的？ 遵循java串行化機制對請求對象進行反序列化。 7、處理完畢后怎么回應(yīng)？ 遵循Mina API進行返回。 MINA是NIO方式的，因此支持異步調(diào)用是毫無懸念的。 -------------------------------------------------------------------------------------------------------------------------------------------------- EJB EJB 最突出的在于其分布式，EJB采用的是ORMI協(xié)議，和RMI協(xié)議是差不多的，但EJB在分布式通訊的安全控制、transport pool、smart proxy等方面的突出使得其在分布式領(lǐng)域是不可忽視的力量。 1、是基于什么協(xié)議實現(xiàn)的？ 基于ORMI協(xié)議。 2、怎 么發(fā)起請求？ EJB調(diào)用。 3、怎么將請求轉(zhuǎn)化為符合協(xié)議的格式的？ 遵循java串行化機制對請求對象進行序列化。 4、使用什么傳輸協(xié)議傳輸？ Socket。 5、響應(yīng)端基于什么機制來 接收請求？ 監(jiān)聽協(xié)議端口。 6、怎么將流還原為傳輸格式的？ 遵循java串行化機制對請求對象進行反序列化。 7、處理完畢后怎么回應(yīng)？ 直接返回處理對象即可。 在之前的分布式服務(wù)框架系列的文章中對于jndi有誤導(dǎo)的嫌疑，在這篇blog中也順帶的提下jndi的機制，由于JNDI取決于具體的實現(xiàn)，在這里只能是講解下jboss的jndi的實現(xiàn)了。 在將對象實例綁定到j(luò)boss jnp server后，當遠程端采用context.lookup()方式獲取遠程對象實例并開始調(diào)用時，jboss jndi的實現(xiàn)方法是從jnp server上獲取對象實例，將其序列化回本地，然后在本地進行反序列化，之后在本地進行類調(diào)用。 通過這個機制，就可以知道了，本地其實是必須有綁定到j(luò)boss上的對象實例的class的，否則反序列化的時候肯定就失敗了，而遠程通訊需要做到的是在遠程執(zhí)行某動作，并獲取到相應(yīng)的結(jié)果，可見純粹基于JNDI是無法實現(xiàn)遠程通訊的。 但JNDI也是實現(xiàn)分布式服務(wù)框架一個很關(guān)鍵的技術(shù)點，因為可以通過它來實現(xiàn)透明化的遠端和本地調(diào)用，就像 ejb，另外它也是個很好的隱藏實際部署機制(就像datasource)等的方案。 總結(jié) 由上一系列的分析可知，在遠程通訊領(lǐng)域中，涉及的知識點還是相當?shù)亩嗟模缬校和ㄐ艆f(xié)議(Socket/tcp/http/udp /rmi/xml-rpc etc.)、消息機制、網(wǎng)絡(luò)IO（BIO/NIO/AIO）、MultiThread、本地調(diào)用與遠程調(diào)用的透明化方案（涉及java classloader、Dynamic Proxy、Unit Test etc.）、異步與同步調(diào)用、網(wǎng)絡(luò)通信處理機制（自動重連、廣播、異常、池處理等等）、Java Serialization (各種協(xié)議的私有序列化機制等)、各種框架的實現(xiàn)原理（傳輸格式、如何將傳輸格式轉(zhuǎn)化為流的、如何將請求信息轉(zhuǎn)化為傳輸格式的、如何接收流的、如何將流還原為傳輸格式的等等），要精通其中的哪些東西，得根據(jù)實際需求來決定了，只有在了解了原理的情況下才能很容易的做出選擇，甚至可以根據(jù)需求做私有的遠程通訊協(xié)議，對于從事分布式服務(wù)平臺或開發(fā)較大型的分布式應(yīng)用的人而言，我覺得至少上面提及的知識點是需要比較了解的。 ————————————————————————————————————————————————————————————————————————————一、綜述 本文比較了RMI，Hessian，Burlap，Httpinvoker，web service等5種通訊協(xié)議的在不同的數(shù)據(jù)結(jié)構(gòu)和不同數(shù)據(jù)量時的傳輸性能。 RMI是java語言本身提供的遠程通訊協(xié)議，穩(wěn)定高效，是EJB的基礎(chǔ)。但它只能用于JAVA程序之間的通訊。 Hessian和Burlap是caucho公司提供的開源協(xié)議，基于HTTP傳輸，服務(wù)端不用開防火墻端口。協(xié)議的規(guī)范公開，可以用于任意語言。 Httpinvoker是SpringFramework提供的遠程通訊協(xié)議，只能用于JAVA程序間的通訊，且服務(wù)端和客戶端必須使用SpringFramework。 Web service是連接異構(gòu)系統(tǒng)或異構(gòu)語言的首選協(xié)議，它使用SOAP形式通訊，可以用于任何語言，目前的許多開發(fā)工具對其的支持也很好。 測試結(jié)果顯示，幾種協(xié)議的通訊效率依次為： RMI > Httpinvoker >= Hessian >> Burlap >> web service RMI不愧是JAVA的首選遠程調(diào)用協(xié)議，非常高效穩(wěn)定，特別是在大數(shù)據(jù)量的情況下，與其他通訊協(xié)議的差距尤為明顯。 HttpInvoker使用java的序列化技術(shù)傳輸對象，與RMI在本質(zhì)上是一致的。從效率上看，兩者也相差無幾，HttpInvoker與RMI的傳輸時間基本持平。 Hessian在傳輸少量對象時，比RMI還要快速高效，但傳輸數(shù)據(jù)結(jié)構(gòu)復(fù)雜的對象或大量數(shù)據(jù)對象時，較RMI要慢20%左右。 Burlap僅在傳輸1條數(shù)據(jù)時速度尚可，通常情況下，它的毫時是RMI的3倍。 Web Service的效率低下是眾所周知的，平均來看，Web Service的通訊毫時是RMI的10倍。 二、結(jié)果分析 1、直接調(diào)用 直接調(diào)用的所有毫時都接近0，這說明程序處理幾乎沒有花費時間，記錄的全部時間都是遠程調(diào)用耗費的。 2、RMI調(diào)用 與設(shè)想的一樣，RMI理所當然是最快的，在幾乎所有的情況下，它的毫時都是最少的。特別是在數(shù)據(jù)結(jié)構(gòu)復(fù)雜，數(shù)據(jù)量大的情況下，與其他協(xié)議的差距尤為明顯。 為了充分發(fā)揮RMI的性能，另外做了測試類，不使用Spring，用原始的RMI形式（繼承UnicastRemoteObject對象）提供服務(wù)并遠程調(diào)用，與Spring對POJO包裝成的RMI進行效率比較。結(jié)果顯示：兩者基本持平，Spring提供的服務(wù)還稍快些。 初步認為，這是因為Spring的代理和緩存機制比較強大，節(jié)省了對象重新獲取的時間。 3、Hessian調(diào)用 caucho公司的resin服務(wù)器號稱是最快的服務(wù)器，在java領(lǐng)域有一定的知名度。Hessian做為resin的組成部分，其設(shè)計也非常精簡高效，實際運行情況也證明了這一點。平均來看，Hessian較RMI要慢20%左右，但這只是在數(shù)據(jù)量特別大，數(shù)據(jù)結(jié)構(gòu)很復(fù)雜的情況下才能體現(xiàn)出來，中等或少量數(shù)據(jù)時，Hessian并不比RMI慢。 Hessian的好處是精簡高效，可以跨語言使用，而且協(xié)議規(guī)范公開，我們可以針對任意語言開發(fā)對其協(xié)議的實現(xiàn)。目前已有實現(xiàn)的語言有：java, c++, .net, python, ruby。還沒有delphi的實現(xiàn)。 另外，Hessian與WEB服務(wù)器結(jié)合非常好，借助WEB服務(wù)器的成熟功能，在處理大量用戶并發(fā)訪問時會有很大優(yōu)勢，在資源分配，線程排隊，異常處理等方面都可以由成熟的WEB服務(wù)器保證。而RMI本身并不提供多線程的服務(wù)器。而且，RMI需要開防火墻端口，Hessian不用。 4、Burlap調(diào)用 Burlap與Hessian都是caucho公司的開源產(chǎn)品，只不過Hessian采用二進制的方式，而Burlap采用xml的格式。 測試結(jié)果顯示，Burlap在數(shù)據(jù)結(jié)構(gòu)不復(fù)雜，數(shù)據(jù)量中等的情況下，效率還是可以接受的，但如果數(shù)據(jù)量大，效率會急劇下降。平均計算，Burlap的調(diào)用毫時是RMI的3倍。 我認為，其效率低有兩方面的原因，一個是XML數(shù)據(jù)描述內(nèi)容太多，同樣的數(shù)據(jù)結(jié)構(gòu)，其傳輸量要大很多；另一方面，眾所周知，對xml的解析是比較費資源的，特別對于大數(shù)據(jù)量情況下更是如此。 5、HttpInvoker調(diào)用 HttpInvoker是SpringFramework提供的JAVA遠程調(diào)用方法，使用java的序列化機制處理對象的傳輸。從測試結(jié)果看，其效率還是可以的，與RMI基本持平。 不過，它只能用于JAVA語言之間的通訊，而且，要求客戶端和服務(wù)端都使用SPRING框架。 另外，HttpInvoker 并沒有經(jīng)過實踐的檢驗，目前還沒有找到應(yīng)用該協(xié)議的項目。 6、web service調(diào)用 本次測試選用了apache的AXIS組件作為WEB SERVICE的實現(xiàn)，AXIS在WEB SERVICE領(lǐng)域相對成熟老牌。 為了僅測試數(shù)據(jù)傳輸和編碼、解碼的時間，客戶端和服務(wù)端都使用了緩存，對象只需實例化一次。但是，測試結(jié)果顯示，web service的效率還是要比其他通訊協(xié)議慢10倍。 如果考慮到多個引用指向同一對象的傳輸情況，web service要落后更多。因為RMI，Hessian等協(xié)議都可以傳遞引用，而web service有多少個引用，就要復(fù)制多少份對象實體。 Web service傳輸?shù)娜哂嘈畔⑦^多是其速度慢的原因之一，監(jiān)控發(fā)現(xiàn)，同樣的訪問請求，描述相同的數(shù)據(jù)，web service返回的數(shù)據(jù)量是hessian協(xié)議的6.5倍。另外，WEB SERVICE的處理也很毫時，目前的xml解析器效率普遍不高，處理xml <-> bean很毫資源。從測試結(jié)果看，異地調(diào)用比本地調(diào)用要快，也從側(cè)面說明了其毫時主要用在編碼和解碼xml文件上。這比冗余信息更為嚴重，冗余信息占用的只是網(wǎng)絡(luò)帶寬，而每次調(diào)用的資源耗費直接影響到服務(wù)器的負載能力。（MS的工程師曾說過，用WEB SERVICE不能負載100個以上的并發(fā)用戶。） 測試過程中還發(fā)現(xiàn)，web service編碼不甚方便，對非基本類型需要逐個注冊序列化和反序列化類，很麻煩，生成stub更累，不如spring + RMI/hessian處理那么流暢簡潔。而且，web service不支持集合類型，只能用數(shù)組，不方便。 -----------------------------------------------------
Silence, the way to avoid many problems;
Smile, the way to solve many problems;