何爲http？何爲RPC？

RPC（即Remote Procedure Call，遠程過程調用）和HTTP（HyperText Transfer Protocol，超文本傳輸協議）他們最本質的區別，就是RPC主要工做在TCP協議之上，而HTTP服務主要是工做在HTTP協議之上，咱們都知道HTTP協議是在傳輸層協議TCP之上的，因此效率來看的話，RPC固然是要更勝一籌。

一、RPC服務

（1）RPC架構
      先說說RPC服務的基本架構吧。一個完整的RPC架構裏面包含了四個核心的組件，分別是Client ,Server,Client Stub以及Server Stub，這個Stub你們能夠理解爲存根。分別說說這幾個組件：
    1)客戶端（Client），服務的調用方。
    2)服務端（Server），真正的服務提供者。
    3)客戶端存根，存放服務端的地址消息，再將客戶端的請求參數打包成網絡消息，而後經過網絡遠程發送給服務方。
    4)服務端存根，接收客戶端發送過來的消息，將消息解包，並調用本地的方法。

      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服務

（1）HTTP接口
      相比RPC，HTTP接口開發也就是咱們常說的RESTful風格的服務接口。的確，對於在接口很少、系統與系統交互較少的狀況下，解決信息孤島初期常使用的一種通訊手段；優勢就是簡單、直接、開發方便。利用現成的http協議進行傳輸。作後臺接口開發的時候，須要寫一份接口文檔，嚴格地標明輸入輸出是什麼？說清楚每個接口的請求方法，以及請求參數須要注意的事項等。
      好比這個例子：POST http://www.httpexample.com/restful/buyer/info/share
      接口可能返回一個JSON字符串或者是XML文檔。而後客戶端再去處理這個返回的信息，從而能夠比較快速地進行開發。可是對於大型企業來講，內部子系統較多、接口很是多的狀況下，RPC框架的好處就顯示出來了，首先就是長連接，沒必要每次通訊都要像http同樣去3次握手什麼的，減小了網絡開銷；其次就是RPC框架通常都有註冊中心，有豐富的監控管理；發佈、下線接口、動態擴展等，對調用方來講是無感知、統一化的操做。

（2）restful：
      對應的中文是rest式的;Restful web service是一種常見的rest的應用,是遵照了rest風格的web服務;rest式的web服務是一種ROA(The Resource-Oriented Architecture)(面向資源的架構)。爲何會出現Restful？
    1）在Restful以前的操做：
    http://127.0.0.1/user/query   GET  根據用戶id查詢用戶數據
    http://127.0.0.1/user/save    POST 新增用戶
    http://127.0.0.1/user/update POST 修改用戶信息
    http://127.0.0.1/user/delete  GET/POST 刪除用戶信息
    2）RESTful用法：
    http://127.0.0.1/user  GET  根據用戶id查詢用戶數據
    http://127.0.0.1/user  POST 新增用戶
    http://127.0.0.1/user  PUT 修改用戶信息
    http://127.0.0.1/user  DELETE 刪除用戶信息
    以前的操做是沒有問題的,大神認爲是有問題的,有什麼問題呢?你每次請求的接口或者地址,都在作描述,例如查詢的時候用了query,新增的時候用了save,其實徹底沒有這個必要,我使用了get請求,就是查詢.使用post請求,就是新增的請求,個人意圖很明顯,徹底沒有必要作描述,這就是爲何有了restful。

三、總結

    RPC服務和HTTP服務仍是存在不少的不一樣點的，通常來講，RPC服務主要是針對大型企業的，而HTTP服務主要是針對小企業的，由於RPC效率更高，而HTTP服務開發迭代會更快。總之，選用什麼樣的框架不是按照市場上流行什麼而決定的，而是要對整個項目進行完整地評估，從而在仔細比較兩種開發框架對於整個項目的影響，最後再決定什麼纔是最適合這個項目的。必定不要爲了使用RPC而每一個項目都用RPC，而是要因地制宜，具體狀況具體分析。