服務之間的呼叫 HTTP代替RPC？

安全劍客發表於2020-02-21
HTTPRPC
RPC(Remote Procedure Call)—遠端過程呼叫，它是一種通過網路從遠端計算機程式上請求服務，而不需要了解底層網路技術的協議。

服務之間的呼叫 HTTP代替RPC？服務之間的呼叫 HTTP代替RPC？

什麼是 RPC?

RPC(Remote Procedure Call)—遠端過程呼叫，它是一種通過網路從遠端計算機程式上請求服務，而不需要了解底層網路技術的協議。比如兩個不同的服務 A、B 部署在兩臺不同的機器上，那麼服務 A 如果想要呼叫服務 B 中的某個方法該怎麼辦呢?使用 HTTP請求 當然可以，但是可能會比較慢而且一些優化做的並不好。 RPC 的出現就是為了解決這個問題。

RPC原理是什麼?

服務之間的呼叫 HTTP代替RPC？服務之間的呼叫 HTTP代替RPC？

服務之間的呼叫為啥不直接用 HTTP 而用 RPC？

服務消費方(client)呼叫以本地呼叫方式呼叫服務;

client stub接收到呼叫後負責將方法、引數等組裝成能夠進行網路傳輸的訊息體;

client stub找到服務地址，並將訊息傳送到服務端;

server stub收到訊息後進行解碼;

server stub根據解碼結果呼叫本地的服務;

本地服務執行並將結果返回給server stub;

server stub將返回結果打包成訊息併傳送至消費方;

client stub接收到訊息，並進行解碼;

服務消費方得到最終結果。

下面再貼一個網上的時序圖：

服務之間的呼叫 HTTP代替RPC？服務之間的呼叫 HTTP代替RPC？

服務之間的呼叫為啥不直接用 HTTP 而用 RPC？

RPC 解決了什麼問題?

從上面對 RPC 介紹的內容中，概括來講RPC 主要解決了：讓分散式或者微服務系統中不同服務之間的呼叫像本地呼叫一樣簡單。

常見的 RPC 框架總結?

RMI(JDK自帶)： JDK自帶的RPC，有很多侷限性，不推薦使用。

Dubbo: Dubbo是 阿里巴巴公司開源的一個高效能優秀的服務框架，使得應用可通過高效能的 RPC 實現服務的輸出和輸入功能，可以和 Spring框架無縫整合。目前 Dubbo 已經成為 Spring Cloud Alibaba 中的官方元件。

gRPC ：gRPC是可以在任何環境中執行的現代開源高效能RPC框架。它可以通過可插拔的支援來有效地連線資料中心內和跨資料中心的服務，以實現負載平衡，跟蹤，執行狀況檢查和身份驗證。它也適用於分散式計算的最後一英里，以將裝置，移動應用程式和瀏覽器連線到後端服務。

Hessian： Hessian是一個輕量級的remotingonhttp工具，使用簡單的方法提供了RMI的功能。 相比WebService，Hessian更簡單、快捷。採用的是二進位制RPC協議，因為採用的是二進位制協議，所以它很適合於傳送二進位制資料。

Thrift： Apache Thrift是Facebook開源的跨語言的RPC通訊框架，目前已經捐獻給Apache基金會管理，由於其跨語言特性和出色的效能，在很多網際網路公司得到應用，有能力的公司甚至會基於thrift研發一套分散式服務框架，增加諸如服務註冊、服務發現等功能。

RPC 只是一種設計而已

RPC 只是一種概念、一種設計，就是為了解決 不同服務之間的呼叫問題, 它一般會包含有 傳輸協議 和 序列化協議 這兩個。

實現 RPC 的可以傳輸協議可以直接建立在 TCP 之上，也可以建立在 HTTP 協議之上。大部分 RPC 框架都是使用的 TCP 連線(gRPC使用了HTTP2)。

HTTP 和 TCP

可能現在很多對計算機網路不太熟悉的朋友已經被搞蒙了，要想真正搞懂，還需要來簡單複習一下計算機網路基礎知識：

我們通常談計算機網路的五層協議的體系結構是指：應用層、傳輸層、網路層、資料鏈路層、物理層。

應用層(application-layer)的任務是通過應用程式間的互動來完成特定網路應用。HTTP 屬於應用層協議，它會基於TCP/IP通訊協議來傳遞資料(HTML 檔案, 圖片檔案, 查詢結果等)。HTTP協議工作於客戶端-服務端架構為上。瀏覽器作為HTTP客戶端通過 URL 向HTTP服務端即WEB伺服器傳送所有請求。Web伺服器根據接收到的請求後，向客戶端傳送響應資訊。HTTP協議建立在 TCP 協議之上。

運輸層(transport layer)的主要任務就是負責向兩臺主機程式之間的通訊提供通用的資料傳輸服務。TCP是傳輸層協議，主要解決資料如何在網路中傳輸。相比於UDP,TCP 提供的是面向連線的，可靠的資料傳輸服務。

主要關鍵就在 HTTP 使用的 TCP 協議，和我們自定義的 TCP 協議在報文上的區別。

http1.1協議的 TCP 報文包含太多在傳輸過程中可能無用的資訊：

HTTP/1.0 200 OK  
Content-Type: text/plain 
Content-Length: 137582 
Expires: Thu, 05 Dec 1997 16:00:00 GMT 
Last-Modified: Wed, 5 August 1996 15:55:28 GMT 
Server: Apache 0.84 
 
 
 Hello World

使用自定義 TCP 協議進行傳輸就會避免上面這個問題，極大地減輕了傳輸資料的開銷。 這也就是為什麼通常會採用自定義 TCP 協議的 RPC 來進行進行服務呼叫的真正原因。除此之外，成熟的 RPC 框架還提供好了“服務自動註冊與發現”、"智慧負載均衡"、“視覺化的服務治理和運維”、“執行期流量排程”等等功能，這些也算是選擇 RPC 進行服務註冊和發現的一方面原因吧!

一個常見的錯誤觀點

很多文章中還會提到說 HTTP 協議相較於自定義 TCP 報文協議，增加的開銷在於連線的建立與斷開，但是這個觀點已經被否認，下面擷取自某乎中一個回答：

首先要否認一點 HTTP 協議相較於自定義 TCP 報文協議，增加的開銷在於連線的建立與斷開。HTTP 協議是支援連線池複用的，也就是建立一定數量的連線不斷開，並不會頻繁的建立和銷燬連線。二一要說的是 HTTP 也可以使用 Protobuf 這種二進位制編碼協議對內容進行編碼，因此二者最大的區別還是在傳輸協議上。

題外話

除此之外，還需要注意的一點是 Spring Cloud Netflix 並沒有使用 RPC 框架來進行不同服務之間的呼叫，而是使用 HTTP 協議進行呼叫的，速度雖然不比 RPC ,但是使用 HTTP 協議也會帶來其他很多好處(這一點，可以自行查閱相關資料瞭解)。

原文地址： https://www.linuxprobe.com/http-rpc.html

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/31559985/viewspace-2676573/，如需轉載，請註明出處，否則將追究法律責任。

相關文章