HTTP接口和RPC接口都是生產上常用的接口，顧名思義，HTTP接口使用基于HTTP協議的URL傳參調用，而RPC接口則基于遠程過程調用。
RPC（即Remote Procedure Call，遠程過程調用）和HTTP（HyperText Transfer Protocol，超文本傳輸協議），兩者前者是一種方法，后者則是一種協議。兩者都常用于實現服務，在這個層面最本質的區別是RPC服務主要工作在TCP協議之上（也可以在HTTP協議），而HTTP服務工作在HTTP協議之上。由于HTTP協議基于TCP協議，所以RPC服務天然比HTTP更輕量，效率更勝一籌。
兩者都是基于網絡實現的，從這一點上，都是基于Client/Server架構。
RPC（Remote Procedure Call）服務
RPC服務基本架構包含了四個核心的組件，分別是Client、Server、Clent Stub以及Server Stub。
- Client （客戶端）：服務調用方。
- Server（服務端）：服務提供方。
- Client Stub（客戶端存根）：存放服務端的地址消息，負責將客戶端的請求參數打包成網絡消息，然后通過網絡發送給服務提供方。
- Server Stub（服務端存根）：接收客戶端發送的消息，再將客戶端請求參數打包成網絡消息，然后通過網絡遠程發送給服務方。
RPC效率優勢明顯，在實際開發中，客戶端和服務端在技術方案中約定客戶端的調用參數和服務端的返回參數之后就可以各自開發，任何客戶端只要按照接口定義的規范發送入參都可以調用該RPC服務，服務端也能按接口定義的規范出參返回計算結果。這樣既實現了客戶端和服務端之間的解耦，也使得RPC接口可以在多個項目中重復利用。
RPC調用分為同步方式和異步方式。同步調用即客戶端等待調用完成并返回結果；異步調用即客戶端不等待調用執行完成返回結果，變成單向調用或者通過回調函數等待接收到返回結果的通知。
流行的RPC框架
目前流行的RPC框架有很多，下面介紹常見的三種。
- gRPC： gRPC是google公布的開源項目，基于HTTP2.0協議，并支持常見的眾多編程語言。HTTP 2.0協議是基于二進制的HTTP協議的升級版本，gRPC底層使用?.NETty框架。
- Thrift： Thrift是Facebook的一個開源項目，主要是一個跨語言的服務開發框架。它有一個代碼生成器來對它所定義的IDL文件自動生成服務代碼框架。Thrift對于底層的RPC通訊都是透明的，用戶只需要對其進行二次開發即可，省去了一系列重復的前置基礎開發工作。
- Dubbo： Dubbo是阿里集團開源的一個極為出名的RPC框架，在很多互聯網公司和企業應用中廣泛使用。協議和序列化框架都可以插拔是及其鮮明的特色。
HTTP服務
通過HTTP URL調用的服務，瀏覽器訪問本質上也算HTTP服務，不同的是需要客戶端瀏覽器渲染服務端返回的結果。
HTTP服務開發即開發ERESTful風格的服務接口。在接口不多、系統之間交互較少的情況下，是一種信息傳遞的常用通信手段。
HTTP接口的優點是簡單、直接、開發方便，利用現成的HTTP協議進行傳輸。在服務開發的時候，約定一個接口文檔，嚴格定義輸入和輸出，明確每一個接口的請求方法和需要的請求參數及其格式。
在內部子系統較多、接口較多的情況下，RPC框架的好處就凸顯出現了，首先是長連接，不必每次通信都要像HTTP那樣三次握手，減少了網絡開銷；其次是RPC框架一般都有注冊中心，有豐富的監控發布方法；RPC接口的發布、下線、動態擴展等對調用方是無感知的、統一化的操作。
Restful
Restful web service是一種常見的rest應用，統一用于命名遵循rest風格的web服務。Restful服務是一種ROA（Resource-Oriented Architecture，面向資源的架構）。舉一個例子就可以理解了：
Restful出現之前的HTTP接口：
- 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 刪除用戶信息
Restful式HTTP接口:
- 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 刪除用戶信息
RPC接口和HTTP接口的區別與聯系
RPC接口即相當于調用本地接口一樣調用遠程服務的接口；HTTP接口是基于http協議的post接口和get接口（等等，2.0版本協議子支持更多）。
傳輸協議
- RPC：可以基于TCP協議，也可以基于HTTP協議。
- HTTP：基于HTTP協議。
傳輸效率
- RPC：使用自定義的TCP協議，可以讓請求報文體積更小，或者使用HTTP2.0協議，也可以很好地減少報文體積，提高傳輸效率。
- HTTP：如果時基于HTTP1.1的協議，請求中會包含很多無用的內容；如果是基于HTTP2.0，那么簡單地封裝一下還是可以作為一個RPC使用的，這時標準RPC框架更多是服務治理。
性能消耗
- RPC：可以基于thrift實現高效的二進制傳輸
- HTTP：大部分是通過json實現的，字節大小和序列化耗時都比thrift要更消耗性能
負載均衡
- RPC：基本都自帶了負載均衡策略
- HTTP：需要配置Nginx，HAProxy實現
服務治理（下游服務新增，重啟，下線時如何不影響上游調用者）
- RPC：能做到自動通知，不影響上游
- HTTP：需要事先通知，修改Nginx/HAProxy配置
RPC主要用于公司內部服務調用，性能消耗低，傳輸效率高，服務治理方便。HTTP主要用于對外的異構環境，瀏覽器調用，App接口調用，第三方接口調用等等。
RPC和HTTP都可以用于實現遠程過程調用，如何選擇？
- 從速度上看，RPC比HTTP更快，雖然底層都是TCP，但是http協議的信息往往比較臃腫，不過可以采用gzip壓縮
- 從難度上看，RPC實現較為復雜，http相對簡單
- 從靈活性上看，HTTP更勝一籌，因為它不關心實現細節，跨平臺，跨語言
兩者有不同的使用場景：
- 如果對效率要求更高，并且開發過程使用統一的技術棧，那么RPC還是不錯的
- 如果需要更加靈活，跨語言、跨平臺，顯然HTTP更合適
再插一句，最近新興的微服務概念更加強調獨立、自治、靈活，而RPC限制較多。因此微服務框架中，一般都會采用HTTP的Restful服務，像在公司內部使用hsf協議，對接外部系統使用微服務。
參考文獻
- https://www.cnblogs.com/Dong-Ge/articles/9577019.html
- https://www.jianshu.com/p/9ccdea882688
- https://www.cnblogs.com/111testing/p/11297037.html
來源：blog.csdn.net/Solo95/article/detAIls/122640662
