目前有很多RPC框架，有基于Json的，有基于XML，也有基于二進制對象的。

　　論復雜度，RPC框架肯定是高于簡單的HTTP接口的。但毋庸置疑，HTTP接口由于受限于HTTP協議，需要帶HTTP請求頭，導致傳輸起來效率或者說安全性不如RPC。

　　現在問題是，遇到怎樣的瓶頸了才需要或者說更適合用RPC（比如像阿里這么大的請求并發量，簡單的HTTP肯定達不到預期），但問題是大家所在的公司，要有像阿里這么大的量是比較少的，甚至說1/1000的量可能都沒有，那我們還需要使用RPC嗎？

　　技術應該不是為了使用新技術而去使用，而應該是舊技術存在某些瓶頸，存在難以支撐或者擴展性越老越差等問題暴露出來之后，用新技術來進行解決。

　　那RPC最大的優點，或者說它相比簡單的HTTP接口，它的優勢、更適合它的業務場景是怎樣呢？簡單的HTTP又哪里不足，哪些場景明顯不太適合呢？

　　RPC=RemoteProduceCall是一種技術的概念名詞。HTTP是一種協議，RPC可以通過HTTP來實現，也可以通過Socket自己實現一套協議來實現。

　　所以可以換一個問法，為何RPC還有除HTTP之外的實現法，有何必要。畢竟除了HTTP實現外，私有協議不具備通用性。那么我想唯一的答案就在于HTTP不能滿足其業務場景的地方，所以這個就要具體案例具體分析了。

　　分析

　　http接口是在接口不多、系統與系統交互較少的情況下，解決信息孤島初期常使用的一種通信手段；優點就是簡單、直接、開發方便。利用現成的http協議進行傳輸。但是如果是一個大型的網站，內部子系統較多、接口非常多的情況下，RPC框架的好處就顯示出來了，首先就是長鏈接，不必每次通信都要像http一樣去3次握手什么的，減少了網絡開銷；其次就是RPC框架一般都有注冊中心，有豐富的監控管理；發布、下線接口、動態擴展等，對調用方來說是無感知、統一化的操作。第三個來說就是安全性。最后就是最近流行的服務化架構、服務化治理，RPC框架是一個強力的支撐。

　　RPC是一種概念，http也是rpc實現的一種方式。論復雜度，dubbo/hessian用起來是超級簡單的。最近用dubbo和hessian比較多，http的幾乎都被廢棄了。

　　至于為什么用，其實很簡單，業務場景不一樣。我最早的單位所有的代碼都在一個工程里，一次要發布幾百m的代碼。這種架構是非常有利于小程序的。但是我們為什么要應用rpc層呢，一個功能，一套代碼下來不就解決了么？我覺得有幾個好處：

　　1靈活部署

　　2解耦至于為什么，當你用到的時候，你會體會。

　　系統做大了，肯定是需要做微服務的。比如做電商就是這樣，單獨有一個訂單系統，支付系統，商品系統，用戶系統。都是分開部署，單獨上線的。但交互是用HTTP接口來交互的，可以轉用RPC。

　　用http交互其實就已經屬于rpc了。

　　RPC的核心并不在于使用什么協議。RPC的目的是讓你在本地調用遠程的方法，而對你來說這個調用是透明的，你并不知道這個調用的方法是部署哪里。通過RPC能解耦服務，這才是使用RPC的真正目的。RPC的原理主要用到了動態代理模式，至于http協議，只是傳輸協議而已。簡單的實現可以參考springremoting，復雜的實現可以參考dubbo。