總體性能比較：
Socket(BIO/NIO)>RMI>HTTPInvoker>=Hessian>REST>>Burlap>EJB>>Web Service
如果協(xié)議設(shè)計(jì)的比較好，Socket性能毫無疑問是最高，同時(shí)靈活性和復(fù)雜度也最高，如果采用高效的網(wǎng)絡(luò)框架如:Mina、Netty等可以降低開發(fā)復(fù)雜度，一般在對(duì)性能有非常苛刻的條件下使用。 RMI的性能相對(duì)略低，但是與Socket還在同1個(gè)數(shù)量級(jí)，同時(shí)只能在Java系統(tǒng)間通信，如果是基于互聯(lián)網(wǎng)使用，還存在穿越防火墻的問題。采用Spring封裝的方式使用比原始RMI方式性能略高，主要原因是：Spring采用了代理和緩存機(jī)制，節(jié)省了對(duì)象重新獲取的時(shí)間。 HTTPInvoker是Spring特有的，只能在客戶端和服務(wù)器端都采用Spring框架下使用，與RMI本質(zhì)相同，使用java的序列化技術(shù)傳輸對(duì)象，兩者性能差別較小。 Hessian在數(shù)據(jù)量較小時(shí)性能表現(xiàn)出眾，甚至比RMI還高，在數(shù)據(jù)結(jié)構(gòu)復(fù)雜的對(duì)象或者大量數(shù)據(jù)對(duì)象時(shí)，較RMI要慢20%左右；Hessian的優(yōu)點(diǎn)是精簡(jiǎn)高效，同時(shí)可以跨語言使用，目前支持Java,C++, .net, python, ruby等語言。另外Hessian可以充分利用web容器的成熟功能，在處理大量用戶訪問時(shí)很有優(yōu)勢(shì)，在資源分配、線程排隊(duì)、異常處理等方面都可以由web容器保證，而RMI本身不提供多線程的服務(wù)器。 REST架構(gòu)也是一種比較簡(jiǎn)單、高效的Web服務(wù)架構(gòu)，相對(duì)于Hessian性能略低，但還在同一個(gè)數(shù)量級(jí)，同時(shí)也是基于HTTP協(xié)議，目前也有比較多的成功案例。 Burlap在數(shù)據(jù)量非常小時(shí)性能尚可，同時(shí)性能隨著數(shù)據(jù)量的增加急劇降低，通常性能耗時(shí)是RMI的3倍左右，主要原因是：Hessian采用二進(jìn)制傳輸數(shù)據(jù)，而Burlap采用XML格式，而XML描述內(nèi)容太多，同樣的結(jié)構(gòu)，其傳輸量要大很多，同時(shí)，XML的解析是比較耗資源的，尤其大數(shù)據(jù)量情況下更是如此。 EJB基于RMI協(xié)議，性能不高，同時(shí)只能在Java系統(tǒng)內(nèi)使用，不能跨語言，目前使用越來越少，目前阿里巴巴內(nèi)部已經(jīng)完全放棄EJB。 在這些遠(yuǎn)程調(diào)用協(xié)議中，Web Service的性能是最低的，一般情況下，Web Service的性能相對(duì)于Hessian性能要慢10~20倍左右，同時(shí)，對(duì)于同樣的訪問請(qǐng)求，Web Service的傳輸數(shù)據(jù)量約為Hessian的6倍左右，對(duì)網(wǎng)絡(luò)帶寬消耗非常大，同時(shí)XML的解碼器普遍性能不高，XML<->Java Bean的編碼、解碼非常耗費(fèi)資源，對(duì)于并發(fā)和負(fù)載比較高的網(wǎng)站不是一個(gè)好的選擇。同時(shí)，Web Service的使用也不太方便。
總結(jié)：Hessian和REST架構(gòu)個(gè)人認(rèn)為是比較優(yōu)秀的高性能通信協(xié)議，如果對(duì)性能要求特別苛刻可以直接采用Socket方式，目前，阿里巴巴內(nèi)部的遠(yuǎn)程調(diào)用主要采用Hessian和Dubbo(基于Mina框架)，經(jīng)受了苛刻的高并發(fā)、高負(fù)載考驗(yàn)。
主要幾種協(xié)議遠(yuǎn)程調(diào)用消耗大致時(shí)間(小數(shù)據(jù)量)：
Socket/RMI/Hessian: 0.5ms
REST:0.7ms
Web Service(Axis): 約10ms，其中如果采用wsdl2java的方式，效率更低些。
Socket/RMI/Hessian/REST之間選擇還需要在傳輸數(shù)據(jù)量，性能要求等各方面考量，合適的場(chǎng)景選擇合適的協(xié)議
聯(lián)系客服
