總結在幾者之間選擇的考量：
1. 如果你不需要很多語(yǔ)言相互調用， 希望保持清晰的java接口代碼（無(wú)任何業(yè)務(wù)不相關(guān)的接口繼承和方法，屬性定義），減少開(kāi)放工作量，推薦Hessian。
2. 如果你的系統之間傳輸的數據量不是很大(<2M都不算大)， 推薦Hessian。
3. 如果需要支持大數據量的傳輸，多語(yǔ)言調用，極高的并發(fā)支持，推薦使用thrift/protocol buffer。 通常我們并發(fā)很難超過(guò)1000 req/s，如果超過(guò)1000 req/s，在國內互聯(lián)網(wǎng)排名絕對前5，那么恭喜你。因此一般而言，用Hessian就夠了。
=====================================================================================最近重新考察了各種RPC解決方案，感覺(jué)最初的xmlrpc確實(shí)在技術(shù)上已經(jīng)有些落后了。
最初考慮的替代方案是采用hessian，原來(lái)沒(méi)有采用這一方案的原因之一是hessian最初只能是現java到j(luò )ava的訪(fǎng)問(wèn)，另外hessian需要web容器的支持。沒(méi)想到兩年時(shí)間hessian已經(jīng)發(fā)展到了多語(yǔ)言支持，并且采用Jetty嵌入web容器也變得非常簡(jiǎn)單，因此首先對hessian 進(jìn)行了嘗試，發(fā)現xmlrpc到hessian的轉換非常容易，尤其是使用純java的情況，轉換的代價(jià)非常小，性能也有顯著(zhù)的提高，對于最關(guān)心的二進(jìn)制數據傳輸，性能提高了一倍多一點(diǎn)，感覺(jué)很滿(mǎn)意。
由于有了Jetty，接下來(lái)考察了使用純servlet方案，雖然不夠靈活，但性能上能夠比hessian快一點(diǎn)。
經(jīng)過(guò)上述測試，基本上確認了，采用http協(xié)議的情況下，采用hessian比較適當，在一些關(guān)鍵點(diǎn)，可以采用自定義的servlet，性能上能夠進(jìn)一步提高。
本想下一步直接測試ICE的性能，由于最近google發(fā)布了protocol buffers，因此對這一類(lèi)的技術(shù)產(chǎn)生了興趣，首先考察了protocol buffers，但是目前提供的代碼中，雖然對于RPC留有了接口，但并沒(méi)有提供直接的實(shí)現，因此暫時(shí)放在一邊。在查找protocol buffers的過(guò)程中，與其類(lèi)似的thrift落入了眼簾，接下來(lái)對thrift進(jìn)行了考察，經(jīng)過(guò)簡(jiǎn)單地測試，發(fā)現thrift在開(kāi)發(fā)方面相當簡(jiǎn)單，而且性能也有明顯的提高，相比hessian，有將近80％的提高。測試過(guò)程中存在一點(diǎn)點(diǎn)插曲，由于thrift的文檔過(guò)于簡(jiǎn)單（估計沒(méi)有及時(shí)更新），其中沒(méi)有對二進(jìn)制數據類(lèi)型進(jìn)行說(shuō)明，因此最初采用List<Byte>對二進(jìn)制數據進(jìn)行封裝，性能極其低下，通過(guò)查找mail list，發(fā)現可以直接使用binary類(lèi)型，測試了一下，結果很理想。
從目前來(lái)看，基于中間描述的協(xié)議，例如corba的idl，protocol buffers的proto，thrift的ThriftIDL，ice的slice，這些協(xié)議可以通過(guò)中間描述生成代碼，數據的編碼和解析具有很好的性能，而基于直接類(lèi)型的協(xié)議如xmlrpc，hessian等，則必須采用反射的方法進(jìn)行編碼和解析，性能相對較低。
由于ICE的文檔太多，總是下不了決心攻讀一下，不過(guò)這次決心一定要對各種協(xié)議做一個(gè)全面的對比，下一步的重點(diǎn)將是ICE。
=====================================================================================
http://shiyanjun.cn/archives/499.html
我更想知道的是如何在TCP/UDP上封裝為RPC?。。。。。。。。。。?！
聯(lián)系客服
