網絡-RPC

網絡-RPC

轉載聲明

本文大量內容系轉載自以下文章,有刪改,並參考其他文檔資料加入了一些內容:

1 RPC原理

1.1 簡介

RPC(Remote Procedure Call)—遠程過程調用,它是一種通過網絡從遠程計算機程序上請求服務,而不需要了解底層網絡技術的協議。

比如兩個不同的服務 A、B 部署在兩臺不同的機器上,那麼服務 A 如果想要調用服務 B 中的某個方法該怎麼辦呢?使用 HTTP請求 當然可以,但是可能會比較慢而且一些優化做的並不好。RPC 的出現就是爲了解決這個問題。

1.2 原理

在這裏插入圖片描述
如上圖,RPC中一次Client到Server的請求流程如下:

  1. 服務消費方(client)調用以本地調用方式調用服務;
  2. client stub接收到調用後負責將方法、參數等組裝成能夠進行網絡傳輸的消息體;
  3. client stub找到服務地址,並將消息發送到服務端;
  4. server stub收到消息後進行解碼;
  5. server stub根據解碼結果調用本地的服務;
  6. 本地服務執行並將結果返回給server stub;
  7. server stub將返回結果打包成消息併發送至消費方;
  8. client stub接收到消息,並進行解碼;
  9. 服務調用方得到最終結果。

再以時序圖方式看看流程:
在這裏插入圖片描述

1.3 RPC 解決了什麼問題?

讓分佈式或者微服務系統中不同服務之間的調用像調用本地方法一樣簡單。

1.4 常見的 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研發一套分佈式服務框架,增加諸如服務註冊、服務發現等功能。

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

1.5.1 原因

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

實現 RPC 的傳輸協議可以直接建立在 TCP 之上,也可以建立在 HTTP 協議之上。

大部分 RPC 框架都是使用的 TCP 連接(gRPC使用了HTTP2)。

1.5.2 HTTP和TCP使用分析

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

  • 工作在應用層的HTTP
    應用層(application-layer)的任務是通過應用進程間的交互來完成特定網絡應用。HTTP 屬於應用層協議,它會基於TCP/IP通信協議來傳遞數據(HTML 文件, 圖片文件, 查詢結果等)。HTTP協議工作於客戶端-服務端架構爲上。

    瀏覽器作爲HTTP客戶端通過 URL 向HTTP服務端即WEB服務器發送所有請求。Web服務器根據接收到的請求後,向客戶端發送響應信息。

    注意:HTTP協議建立在 TCP 協議之上。

  • 工作在傳輸層的TCP協議
    主要解決數據如何在網絡中傳輸。運輸層(transport layer)的主要任務就是負責向兩臺主機進程之間的通信提供通用的數據傳輸服務。相比於UDP,TCP 提供的是面向連接的,可靠的數據傳輸服務。

  • HTTP 使用的 TCP 協議,和我們自定義的 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 這種二進制編碼協議對內容進行編碼,因此二者最大的區別還是在傳輸協議上。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章