RPC與HTTP

一、為什么需要RPC，而不是簡單的HTTP接口？

　　RPC（即Remote Procedure Call，遠程過程調用），主要是基於TCP/IP協議；而HTTP服務主要是基於HTTP協議的。我們都知道HTTP協議是在傳輸層協議TCP之上的，所以效率來看的話，RPC當然是要更勝一籌啦！下面來具體說一說RPC服務和HTTP服務。

二、RPC

　　從三個角度來介紹RPC服務：分別是RPC架構，同步異步調用以及流行的RPC框架。

　　1.RPC架構

　　一個完整的RPC架構里面包含了四個核心的組件，分別是Client ,Server,Client Stub以及Server Stub，這個Stub大家可以理解為存根。分別說說這幾個組件：

• 客戶端（Client），服務的調用方。
• 服務端（Server），真正的服務提供者。
• 客戶端存根，存放服務端的地址消息，再將客戶端的請求參數打包成網絡消息，然后通過網絡遠程發送給服務方。
• 服務端存根，接收客戶端發送過來的消息，將消息解包，並調用本地的方法　　

　　

　　RPC主要是用在大型企業里面，因為大型企業里面系統繁多，業務線復雜，而且效率優勢非常重要的一塊，這個時候RPC的優勢就比較明顯了。實際的開發當中是這么做的，項目一般使用maven來管理。比如我們有一個處理訂單的系統服務，先聲明它的所有的接口（這里就是具體指Java中的interface），然后將整個項目打包為一個jar包，服務端這邊引入這個二方庫，然后實現相應的功能，客戶端這邊也只需要引入這個二方庫即可調用了。為什么這么做？主要是為了減少客戶端這邊的jar包大小，因為每一次打包發布的時候，jar包太多總是會影響效率。另外也是將客戶端和服務端解耦，提高代碼的可移植性。

　　2.同步調用與異步調用

　　什么是同步調用？什么是異步調用？同步調用就是客戶端等待調用執行完成並返回結果。異步調用就是客戶端不等待調用執行完成返回結果，不過依然可以通過回調函數等接收到返回結果的通知。如果客戶端並不關心結果，則可以變成一個單向的調用。這個過程有點類似於Java中的callable和runnable接口，我們進行異步執行的時候，如果需要知道執行的結果，就可以使用callable接口，並且可以通過Future類獲取到異步執行的結果信息。如果不關心執行的結果，直接使用runnable接口就可以了，因為它不返回結果，當然啦，callable也是可以的，我們不去獲取Future就可以了。

　　3.流行的RPC框架

　    目前流行的開源RPC框架還是比較多的。下面重點介紹三種：

　　（1）gRPC是Google公布的開源軟件，基於最新的HTTP2.0協議，並支持常見的眾多編程語言。 我們知道HTTP2.0是基於二進制的HTTP協議升級版本，目前各大瀏覽器都在快馬加鞭的加以支持。 這個RPC框架是基於HTTP協議實現的，底層使用到了Netty框架的支持。

　　（2）Thrift是Facebook的一個開源項目，主要是一個跨語言的服務開發框架。它有一個代碼生成器來對它所定義的IDL定義文件自動生成服務代碼框架。用戶只要在其之前進行二次開發就行，對於底層的RPC通訊等都是透明的。不過這個對於用戶來說的話需要學習特定領域語言這個特性，還是有一定成本的。

　　（3）Dubbo是阿里集團開源的一個極為出名的RPC框架，在很多互聯網公司和企業應用中廣泛使用。協議和序列化框架都可以插拔是及其鮮明的特色。同樣 的遠程接口是基於Java Interface，並且依托於spring框架方便開發。可以方便的打包成單一文件，獨立進程運行，和現在的微服務概念一致。

三、HTTP

　　其實在很久以前，我對於企業開發的模式一直定性為HTTP接口開發，也就是我們常說的restful風格的服務接口。的確，對於在接口不多、系統與系統交互較少的情況下，解決信息孤島初期常使用的一種通信手段；優點就是簡單、直接、開發方便。利用現成的http協議進行傳輸。我們記得之前本科實習在公司做后台開發的時候，主要就是進行接口的開發，還要寫一大份接口文檔，嚴格地標明輸入輸出是什么？說清楚每一個接口的請求方法，以及請求參數需要注意的事項等。比如下面這個例子：POST http://www.httpexample.com/restful/buyer/info/share
　　接口可能返回一個JSON字符串或者是XML文檔。然后客戶端再去處理這個返回的信息，從而可以比較快速地進行開發。但是對於大型企業來說，內部子系統較多、接口非常多的情況下，RPC框架的好處就顯示出來了，首先就是長鏈接，不必每次通信都要像http一樣去3次握手什么的，減少了網絡開銷；其次就是RPC框架一般都有注冊中心，有豐富的監控管理；發布、下線接口、動態擴展等，對調用方來說是無感知、統一化的操作。

四、總結

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

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

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

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

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

       RPC是一種技術的概念名詞。 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 解耦 至於為什么，當你用到的時候，你就會體會。

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

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