為什么需要RPC接口

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

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

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

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

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

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

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

　　分析

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

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

　　至于為什么用，其實很簡單，業(yè)務場景不一樣。我最早的單位所有的代碼都在一個工程里，一次要發(fā)布幾百m的代碼。這種架構是非常有利于小程序的。但是我們?yōu)槭裁匆獞胷pc層呢，一個功能，一套代碼下來不就解決了么？我覺得有幾個好處：

　　1靈活部署

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

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

　　用http交互其實就已經(jīng)屬于rpc了。

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