建站
咨詢
售后
建站咨詢
新聞中心
RPC(Remote Procedure Call)：遠程過程調(diào)用，它是一種通過網(wǎng)絡從遠程計算機程序上請求服務，而不需要了解底層網(wǎng)絡技術的思想。
創(chuàng)新互聯(lián)公司是專業(yè)的偏關網(wǎng)站建設公司，偏關接單;提供網(wǎng)站設計、網(wǎng)站建設,網(wǎng)頁設計,網(wǎng)站設計,建網(wǎng)站,PHP網(wǎng)站建設等專業(yè)做網(wǎng)站服務;采用PHP框架,可快速的進行偏關網(wǎng)站開發(fā)網(wǎng)頁制作和功能擴展;專業(yè)做搜索引擎喜愛的網(wǎng)站,專業(yè)的做網(wǎng)站團隊,希望更多企業(yè)前來合作!
RPC 是一種技術思想而非一種規(guī)范或協(xié)議，常見 RPC 技術和框架有：
目前流行的開源 RPC 框架還是比較多的，有阿里巴巴的 Dubbo、Facebook 的 Thrift、Google 的 gRPC、Twitter 的 Finagle 等。
RPC原理是什么?
服務之間的調(diào)用為啥不直接用 HTTP 而用 RPC？
服務消費方(client)調(diào)用以本地調(diào)用方式調(diào)用服務;
client stub接收到調(diào)用后負責將方法、參數(shù)等組裝成能夠進行網(wǎng)絡傳輸?shù)南Ⅲw;
client stub找到服務地址，并將消息發(fā)送到服務端;
server stub收到消息后進行解碼;
server stub根據(jù)解碼結(jié)果調(diào)用本地的服務;
本地服務執(zhí)行并將結(jié)果返回給server stub;
server stub將返回結(jié)果打包成消息并發(fā)送至消費方;
client stub接收到消息，并進行解碼;
服務消費方得到最終結(jié)果。
下面再貼一個網(wǎng)上的時序圖：
服務之間的調(diào)用為啥不直接用 HTTP 而用 RPC？
RPC 解決了什么問題?
從上面對 RPC 介紹的內(nèi)容中，概括來講RPC 主要解決了：讓分布式或者微服務系統(tǒng)中不同服務之間的調(diào)用像本地調(diào)用一樣簡單。
常見的 RPC 框架總結(jié)?
RMI(JDK自帶)： JDK自帶的RPC，有很多局限性，不推薦使用。
Dubbo: Dubbo是 阿里巴巴公司開源的一個高性能優(yōu)秀的服務框架，使得應用可通過高性能的 RPC 實現(xiàn)服務的輸出和輸入功能，可以和 Spring框架無縫集成。目前 Dubbo 已經(jīng)成為 Spring Cloud Alibaba 中的官方組件。
gRPC ：gRPC是可以在任何環(huán)境中運行的現(xiàn)代開源高性能RPC框架。它可以通過可插拔的支持來有效地連接數(shù)據(jù)中心內(nèi)和跨數(shù)據(jù)中心的服務，以實現(xiàn)負載平衡，跟蹤，運行狀況檢查和身份驗證。它也適用于分布式計算的最后一英里，以將設備，移動應用程序和瀏覽器連接到后端服務。
Hessian： Hessian是一個輕量級的remotingonhttp工具，使用簡單的方法提供了RMI的功能。 相比WebService，Hessian更簡單、快捷。采用的是二進制RPC協(xié)議，因為采用的是二進制協(xié)議，所以它很適合于發(fā)送二進制數(shù)據(jù)。
Thrift： Apache Thrift是Facebook開源的跨語言的RPC通信框架，目前已經(jīng)捐獻給Apache基金會管理，由于其跨語言特性和出色的性能，在很多互聯(lián)網(wǎng)公司得到應用，有能力的公司甚至會基于thrift研發(fā)一套分布式服務框架，增加諸如服務注冊、服務發(fā)現(xiàn)等功能。
RPC 只是一種設計而已
RPC 只是一種概念、一種設計，就是為了解決 不同服務之間的調(diào)用問題, 它一般會包含有 傳輸協(xié)議 和 序列化協(xié)議 這兩個。
實現(xiàn) RPC 的可以傳輸協(xié)議可以直接建立在 TCP 之上，也可以建立在 HTTP 協(xié)議之上。大部分 RPC 框架都是使用的 TCP 連接(gRPC使用了HTTP2)。
HTTP 和 TCP
可能現(xiàn)在很多對計算機網(wǎng)絡不太熟悉的朋友已經(jīng)被搞蒙了，要想真正搞懂，還需要來簡單復習一下計算機網(wǎng)絡基礎知識：
我們通常談計算機網(wǎng)絡的五層協(xié)議的體系結(jié)構是指：應用層、傳輸層、網(wǎng)絡層、數(shù)據(jù)鏈路層、物理層。
應用層(application-layer)的任務是通過應用進程間的交互來完成特定網(wǎng)絡應用。HTTP 屬于應用層協(xié)議，它會基于TCP/IP通信協(xié)議來傳遞數(shù)據(jù)(HTML 文件, 圖片文件, 查詢結(jié)果等)。HTTP協(xié)議工作于客戶端-服務端架構為上。瀏覽器作為HTTP客戶端通過 URL 向HTTP服務端即WEB服務器發(fā)送所有請求。Web服務器根據(jù)接收到的請求后，向客戶端發(fā)送響應信息。HTTP協(xié)議建立在 TCP 協(xié)議之上。
運輸層(transport layer)的主要任務就是負責向兩臺主機進程之間的通信提供通用的數(shù)據(jù)傳輸服務。TCP是傳輸層協(xié)議，主要解決數(shù)據(jù)如何在網(wǎng)絡中傳輸。相比于UDP,TCP 提供的是面向連接的，可靠的數(shù)據(jù)傳輸服務。
主要關鍵就在 HTTP 使用的 TCP 協(xié)議，和我們自定義的 TCP 協(xié)議在報文上的區(qū)別。
http1.1協(xié)議的 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 協(xié)議進行傳輸就會避免上面這個問題，極大地減輕了傳輸數(shù)據(jù)的開銷。 這也就是為什么通常會采用自定義 TCP 協(xié)議的 RPC 來進行進行服務調(diào)用的真正原因。除此之外，成熟的 RPC 框架還提供好了“服務自動注冊與發(fā)現(xiàn)”、”智能負載均衡”、“可視化的服務治理和運維”、“運行期流量調(diào)度”等等功能，這些也算是選擇 RPC 進行服務注冊和發(fā)現(xiàn)的一方面原因吧!
一個常見的錯誤觀點
很多文章中還會提到說 HTTP 協(xié)議相較于自定義 TCP 報文協(xié)議，增加的開銷在于連接的建立與斷開，但是這個觀點已經(jīng)被否認，下面截取自某乎中一個回答：
首先要否認一點 HTTP 協(xié)議相較于自定義 TCP 報文協(xié)議，增加的開銷在于連接的建立與斷開。HTTP 協(xié)議是支持連接池復用的，也就是建立一定數(shù)量的連接不斷開，并不會頻繁的創(chuàng)建和銷毀連接。二一要說的是 HTTP 也可以使用 Protobuf 這種二進制編碼協(xié)議對內(nèi)容進行編碼，因此二者最大的區(qū)別還是在傳輸協(xié)議上。
題外話
除此之外，還需要注意的一點是 Spring Cloud Netflix 并沒有使用 RPC 框架來進行不同服務之間的調(diào)用，而是使用 HTTP 協(xié)議進行調(diào)用的，速度雖然不比 RPC ,但是使用 HTTP 協(xié)議也會帶來其他很多好處(這一點，可以自行查閱相關資料了解)。
名稱欄目：服務之間調(diào)用RPC的原因是什么？
地址分享：http://www.5511xx.com/article/ccooeop.html
