服務之間的調用爲啥不直接用 HTTP 而用 RPC？

時間 2020-01-04

標籤服務之間調用爲啥直接 http rpc 欄目 HTTP/TCP 简体版

原文原文鏈接

什麼是 RPC?RPC原理是什麼?

什麼是 RPC？

RPC（Remote Procedure Call）—遠程過程調用，它是一種經過網絡從遠程計算機程序上請求服務，而不須要了解底層網絡技術的協議。好比兩個不一樣的服務 A、B 部署在兩臺不一樣的機器上，那麼服務 A 若是想要調用服務 B 中的某個方法該怎麼辦呢？使用 HTTP請求固然能夠，可是可能會比較慢並且一些優化作的並很差。 RPC 的出現就是爲了解決這個問題。html

RPC原理是什麼？

服務消費方（client）調用以本地調用方式調用服務；
client stub接收到調用後負責將方法、參數等組裝成可以進行網絡傳輸的消息體；
client stub找到服務地址，並將消息發送到服務端；
server stub收到消息後進行解碼；
server stub根據解碼結果調用本地的服務；
本地服務執行並將結果返回給server stub；
server stub將返回結果打包成消息併發送至消費方；
client stub接收到消息，並進行解碼；
服務消費方獲得最終結果。

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

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研發一套分佈式服務框架，增長諸如服務註冊、服務發現等功能。

既有 HTTP ,爲啥用 RPC 進行服務調用?

###RPC 只是一種設計而已app

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

<html>
  <body>Hello World</body>
</html>

使用自定義 TCP 協議進行傳輸就會避免上面這個問題，極大地減輕了傳輸數據的開銷。 這也就是爲何一般會採用自定義 TCP 協議的 RPC 來進行進行服務調用的真正緣由。除此以外，成熟的 RPC 框架還提供好了「服務自動註冊與發現」、"智能負載均衡"、「可視化的服務治理和運維」、「運行期流量調度」等等功能，這些也算是選擇 RPC 進行服務註冊和發現的一方面緣由吧！

一個常見的錯誤觀點

不少文章中還會提到說 HTTP 協議相較於自定義 TCP 報文協議，增長的開銷在於鏈接的創建與斷開，可是這個觀點已經被否定，下面截取自某乎中一個回答：

首先要否定一點 HTTP 協議相較於自定義 TCP 報文協議，增長的開銷在於鏈接的創建與斷開。HTTP 協議是支持鏈接池複用的，也就是創建必定數量的鏈接不斷開，並不會頻繁的建立和銷燬鏈接。二一要說的是 HTTP 也可使用 Protobuf 這種二進制編碼協議對內容進行編碼，所以兩者最大的區別仍是在傳輸協議上。