RPCRemoteProcedureCall即遠(yuǎn)程過程調(diào)用_第1頁
RPCRemoteProcedureCall即遠(yuǎn)程過程調(diào)用_第2頁
RPCRemoteProcedureCall即遠(yuǎn)程過程調(diào)用_第3頁
RPCRemoteProcedureCall即遠(yuǎn)程過程調(diào)用_第4頁
RPCRemoteProcedureCall即遠(yuǎn)程過程調(diào)用_第5頁
已閱讀5頁,還剩3頁未讀, 繼續(xù)免費(fèi)閱讀

下載本文檔

版權(quán)說明:本文檔由用戶提供并上傳,收益歸屬內(nèi)容提供方,若內(nèi)容存在侵權(quán),請進(jìn)行舉報或認(rèn)領(lǐng)

文檔簡介

1、為什么說程序員到了不得不掌握RPC的時候了!原文標(biāo)題:深入理解RPCRPC在企業(yè)服務(wù)中的核心價值隨著企業(yè)IT服務(wù)的不斷發(fā)展,單臺服務(wù)器逐漸無法承受用戶日益增長的請求壓力時,就需要多臺服務(wù)器聯(lián)合起來構(gòu)成服務(wù)集群共同對外提供服務(wù)。同時業(yè)務(wù)服務(wù)會隨著產(chǎn)品需求的增多越來越月中,架構(gòu)上必須進(jìn)行服務(wù)拆分,一個完整的大型服務(wù)會被打散成很多很多獨(dú)立的小服務(wù),每個小服務(wù)會由獨(dú)立的進(jìn)程去管理來對外提供服務(wù),這就是微服務(wù)。當(dāng)用戶的請求到來時,我們需要將用戶的請求分散到多個服務(wù)去各自處理,然后又需要將這些子服務(wù)的結(jié)果匯總起來呈現(xiàn)給用戶。那么服務(wù)之間該使用何種方式進(jìn)行交互就是需要解決的核心問題。RPC就是為解決服務(wù)之間

2、信息交互而發(fā)明和存在的。一、什么是RPC?RPC(RemoteProcedureCall)即遠(yuǎn)程過程調(diào)用,是分布式系統(tǒng)常見的一種通信方法,已經(jīng)有40多年歷史。當(dāng)兩個物理分離的子系統(tǒng)需要建立邏輯上的關(guān)聯(lián)時,RPC是牽線搭橋的常見技術(shù)手段之一。除RPC之外,常見的多系統(tǒng)數(shù)據(jù)交互方案還有分布式消息隊列、HTTP請求調(diào)用、數(shù)據(jù)庫和分布式緩存等。碼洞其中RPC和HTTP調(diào)用是沒有經(jīng)過中間件的,它們是端到端系統(tǒng)的直接數(shù)據(jù)交互。HTTP調(diào)用其實也可以看成是一種特殊的RPC,只不過傳統(tǒng)意義上的RPC是指長連接數(shù)據(jù)交互,而HTTP一般是指即用即走的短鏈接。RPC在我們熟知的各種中間件中都有它的身影。Nginx/

3、Redis/MySQL/Dubbo/Hadoop/Spark/Tensorflow等重量級開源產(chǎn)品都是在RPC技術(shù)的基礎(chǔ)上構(gòu)建出來的,我們這里說的RPC指的是廣義的RPC,也就是分布式系統(tǒng)的通信技術(shù)。RPC在技術(shù)中的地位好比我們身邊的空氣,它無處不在,但是又有很多人根本不知道它的存在。二、Nginx與RPCNgnix是互聯(lián)網(wǎng)企業(yè)使用最為廣泛的代理服務(wù)器。它可以為后端分布式服務(wù)提供負(fù)載均衡的功能,它可以將后端多個服務(wù)地址聚合為單個地址來對外提供服務(wù)。如圖,Django是Python技術(shù)棧最流行的Web框架。Nginx和后端服務(wù)之間的交互在本質(zhì)上也可以理解為RPC數(shù)據(jù)交互。也許你會爭辯說Nginx

4、和后端服務(wù)之間使用的是HTTP協(xié)議,走的是短連接,嚴(yán)格上不能算是RPC調(diào)用你說的沒錯,不過Nginx和后端服務(wù)之間還可以走其它的協(xié)議,比如uwsgi協(xié)議、fastcgi協(xié)議等,這兩個協(xié)議都是采用了比HTTP協(xié)議更加節(jié)省流量的二進(jìn)制協(xié)議。如上圖所示,uWSGI是著名的Python容器,使用它可以啟動uwsgi協(xié)議的服務(wù)器對外提供服務(wù)。uwsgi通訊協(xié)議在Python語言體系里使用非常普遍,如果一個企業(yè)內(nèi)部使用Python語言棧搭建Web服務(wù),那么他們在生產(chǎn)環(huán)境部署Python應(yīng)用的時候不是在使用HTTP協(xié)議就是在使用uwsgi協(xié)議來和Nginx之間建立通訊。Fastcgi協(xié)議在PHP語言體系里非

5、常常見,Nginx和PHP-fpm進(jìn)程之間一般較常使用Fastcgi協(xié)議進(jìn)行通訊。三、Hadoop與RPC在大數(shù)據(jù)技術(shù)領(lǐng)域,RPC也占據(jù)了非常重要的地位。大數(shù)據(jù)領(lǐng)域廣泛應(yīng)用了非常多的分布式技術(shù),分布式意味著節(jié)點(diǎn)的物理隔離,隔離意味著需要通信,通信意味著RPC的存在。大數(shù)據(jù)需要通信的量比業(yè)務(wù)系統(tǒng)更加龐大,所以在數(shù)據(jù)通信優(yōu)化上做的更深。比如最常見的Hadoop文件系統(tǒng)hdfs,一般包括一個NameNode和多個DataNode,NameNode和DataNode之間就是通過一種稱為HadoopRPC的二進(jìn)制協(xié)議進(jìn)行通訊。四、TensorFlow與RPC在人工智能領(lǐng)域,RPC也很重要,著名的Tens

6、orFlow框架如果需要處理上億的數(shù)據(jù),就需要依靠分布式計算力,需要集群化,當(dāng)多個分布式節(jié)點(diǎn)需要集體智慧時,就必須引入RPC技術(shù)進(jìn)行通訊。TensorflowCluster的RPC通訊框架使用了Google內(nèi)部自研的gRPC框架。workers五、HTTP調(diào)用其實也是一種特殊的RPCHTTP1.0協(xié)議時,HTTP調(diào)用還只能是短鏈接調(diào)用,一個請求來回之后連接就會關(guān)閉。HTTP1.1在HTTP1.0協(xié)議的基礎(chǔ)上進(jìn)行了改進(jìn),引入了KeepAlive特性可以保持HTTP連接長時間不斷開,以便在同一個連接之上進(jìn)行多次連續(xù)的請求,進(jìn)一步拉近了HTTP和RPC之間的距離。PersistentConnecti

7、on當(dāng)HTTP協(xié)議進(jìn)化到2.0之后,Google開源了一個建立在HTTP2.0協(xié)議之上的通信框架直接取名為gRPC,也就是GoogleRPC,這時HTTP和RPC之間已經(jīng)沒有非常明顯的界限了。所以在后文我們不再明確強(qiáng)調(diào)RPC和HTTP請求調(diào)用之間的細(xì)微區(qū)別了,直接統(tǒng)一稱之為RPC。六、HTTPVSRPC(普通話VS方言)HTTP與RPC的關(guān)系就好比普通話與方言的關(guān)系。要進(jìn)行跨企業(yè)服務(wù)調(diào)用時,往往都是通過HTTPAPI,也就是普通話,雖然效率不高,但是通用,沒有太多溝通的學(xué)習(xí)成本。但是在企業(yè)內(nèi)部還是RPC更加高效,同一個企業(yè)公用一套方言進(jìn)行高效率的交流,要比通用的HTTP協(xié)議來交流更加節(jié)省資源。

8、整個中國有非常多的方言,正如有很多的企業(yè)內(nèi)部服務(wù)各有自己的一套交互協(xié)議一樣。雖然國家一直在提倡使用普通話交流,但是這么多年過去了,你回一趟家鄉(xiāng)探個親什么的就會發(fā)現(xiàn)身邊的人還是流行說方言。如果再深入一點(diǎn)說,普通話本質(zhì)上也是一種方言,只不過它是官方的方言,使用最為廣泛的方言,相比而言其它方言都是小語種,小語種之中也會有幾個使用比較廣泛比較特色的方言占比也會比較大。這就好比開源RPC協(xié)議中Protobuf和Thrift一樣,它們兩應(yīng)該是RPC協(xié)議中使用最為廣泛的兩個。七、換個角度看世界如果兩個子系統(tǒng)沒有在網(wǎng)絡(luò)上進(jìn)行分離,而是運(yùn)行在同一個操作系統(tǒng)實例之上的兩個進(jìn)程時,它們之間的通信手段還可以更加豐富。

9、除了以上提到的幾種分布式解決方案之外,還有共享內(nèi)存、信號量、文件系統(tǒng)、內(nèi)核消息隊列、管道等,本質(zhì)上都是通過操作系統(tǒng)內(nèi)核機(jī)制來進(jìn)行數(shù)據(jù)和消息的交互而無須經(jīng)過網(wǎng)絡(luò)協(xié)議棧。但在現(xiàn)代企業(yè)服務(wù)中,這種單機(jī)應(yīng)用已經(jīng)非常少見了,因為單機(jī)應(yīng)用意味著單點(diǎn)故障一一“一人摔跤全家跌倒”。業(yè)務(wù)子系統(tǒng)往往都需要經(jīng)物理網(wǎng)絡(luò)棧進(jìn)行隔離,因此分布式解決方案在要求高可用無間斷服務(wù)的企業(yè)環(huán)境里便大有作為,這也讓RPC迎來自己大放異彩的時代。前文提到的分布式子系統(tǒng)交互方案,除了RPC技術(shù)之外還有數(shù)據(jù)庫、消息隊列和緩存。但其實這三者本質(zhì)上是RPC技術(shù)的一個應(yīng)用組合。我們可以將數(shù)據(jù)庫服務(wù)理解為下面這張圖:可以看出,子系統(tǒng)和數(shù)據(jù)庫之間的交互也是通過RPC進(jìn)行的,只不過這里是三個子系統(tǒng)之間復(fù)雜的組合消息交互罷了。如果再深入進(jìn)去,你會發(fā)現(xiàn),這里的數(shù)據(jù)庫不是那種單機(jī)數(shù)據(jù)庫,而是具備主從復(fù)制功能的數(shù)據(jù)庫,比如MySQL0在互聯(lián)網(wǎng)企業(yè)里一般都會使用這種主從讀寫分離的數(shù)據(jù)庫。一個業(yè)務(wù)子系統(tǒng)將數(shù)據(jù)寫往主庫,主庫再將數(shù)據(jù)同步到從庫,然后另一個業(yè)務(wù)子系統(tǒng)又從從庫里將數(shù)據(jù)取出來。這時又可以進(jìn)一步將它們看成是

溫馨提示

  • 1. 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請下載最新的WinRAR軟件解壓。
  • 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請聯(lián)系上傳者。文件的所有權(quán)益歸上傳用戶所有。
  • 3. 本站RAR壓縮包中若帶圖紙,網(wǎng)頁內(nèi)容里面會有圖紙預(yù)覽,若沒有圖紙預(yù)覽就沒有圖紙。
  • 4. 未經(jīng)權(quán)益所有人同意不得將文件中的內(nèi)容挪作商業(yè)或盈利用途。
  • 5. 人人文庫網(wǎng)僅提供信息存儲空間,僅對用戶上傳內(nèi)容的表現(xiàn)方式做保護(hù)處理,對用戶上傳分享的文檔內(nèi)容本身不做任何修改或編輯,并不能對任何下載內(nèi)容負(fù)責(zé)。
  • 6. 下載文件中如有侵權(quán)或不適當(dāng)內(nèi)容,請與我們聯(lián)系,我們立即糾正。
  • 7. 本站不保證下載資源的準(zhǔn)確性、安全性和完整性, 同時也不承擔(dān)用戶因使用這些下載資源對自己和他人造成任何形式的傷害或損失。

評論

0/150

提交評論