轉載自：http://www.oschina.net/question/271044_2155059?sort=default&p=1#answers

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

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

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

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

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

---

RPC=Remote Produce Call 是一種技術的概念名詞. 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，但問題是我現在還沒發現為什麽需要用RPC，我還沒能理解它的作用和意義。

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

---------

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

--------

RPC是一個軟件結構概念，是構建分布式應用的理論基礎。就好比為啥你家可以用到發電廠發出來的電？是因為電是可以傳輸的。至於用銅線還是用鐵絲還是其他 種類的導線，也就是用http還是用其他協議的問題了。這個要看什麽場景，對性能要求怎麽樣。比如在java中的最基本的就是RMI技術，它是java原 生的應用層分布式技術。我們可以肯定的是在傳輸性能方面，RMI的性能是優於HTTP的。那為啥很少用到這個技術？那是因為用這個有很多局限性，首先它要 保證傳輸的兩端都要要用java實現，且兩邊需要有相同的對象類型和代理接口，不需要容器，但是加大了編程的難度，在應用內部的各個子系統之間還是會看到 他的身影，比如EJB就是基於rmi技術的。這就與目前的bs架構的軟件大相徑庭。用http必須要服務端位於http容器裏面，這樣減少了網絡傳輸方面 的開發，只需要關註業務開發即可。所以在架構一個軟件的時候，不能一定根據需求選定技術。

為什麽需要RPC，而不是簡單的HTTP接口