深入理解RPC——你看或沒看見 它都在那里

隨著企業(yè) IT 服務(wù)的不斷發(fā)展，單臺(tái)服務(wù)器逐漸無法承受用戶日益增長的請求壓力時(shí)，就需要多臺(tái)服務(wù)器聯(lián)合起來構(gòu)成「服務(wù)集群」共同對外提供服務(wù)。同時(shí)業(yè)務(wù)服務(wù)會(huì)隨著產(chǎn)品需求的增多越來越腫，架構(gòu)上必須進(jìn)行服務(wù)拆分，一個(gè)完整的大型服務(wù)會(huì)被打散成很多很多獨(dú)立的小服務(wù)，每個(gè)小服務(wù)會(huì)由獨(dú)立的進(jìn)程去管理來對外提供服務(wù)，這就是「微服務(wù)」。

當(dāng)用戶的請求到來時(shí)，我們需要將用戶的請求分散到多個(gè)服務(wù)去各自處理，然后又需要將這些子服務(wù)的結(jié)果匯總起來呈現(xiàn)給用戶。那么服務(wù)之間該使用何種方式進(jìn)行交互就是需要解決的核心問題。RPC 就是為解決服務(wù)之間信息交互而發(fā)明和存在的。

什么是 RPC ？

RPC (Remote Procedure Call)即遠(yuǎn)程過程調(diào)用，是分布式系統(tǒng)常見的一種通信方法，已經(jīng)有 40 多年歷史。當(dāng)兩個(gè)物理分離的子系統(tǒng)需要建立邏輯上的關(guān)聯(lián)時(shí)，RPC 是牽線搭橋的常見技術(shù)手段之一。除 RPC 之外，常見的多系統(tǒng)數(shù)據(jù)交互方案還有分布式消息隊(duì)列、HTTP 請求調(diào)用、數(shù)據(jù)庫和分布式緩存等。

其中 RPC 和 HTTP 調(diào)用是沒有經(jīng)過中間件的，它們是端到端系統(tǒng)的直接數(shù)據(jù)交互。HTTP 調(diào)用其實(shí)也可以看成是一種特殊的 RPC，只不過傳統(tǒng)意義上的 RPC 是指長連接數(shù)據(jù)交互，而 HTTP 一般是指即用即走的短鏈接。

RPC 在我們熟知的各種中間件中都有它的身影。Nginx/Redis/MySQL/Dubbo/Hadoop/Spark/Tensorflow 等重量級開源產(chǎn)品都是在 RPC 技術(shù)的基礎(chǔ)上構(gòu)建出來的，我們這里說的 RPC 指的是廣義的 RPC，也就是分布式系統(tǒng)的通信技術(shù)。RPC 在技術(shù)中的地位好比我們身邊的空氣，它無處不在，但是又有很多人根本不知道它的存在。

Nginx 與 RPC

Ngnix 是互聯(lián)網(wǎng)企業(yè)使用最為廣泛的代理服務(wù)器。它可以為后端分布式服務(wù)提供負(fù)載均衡的功能，它可以將后端多個(gè)服務(wù)地址聚合為單個(gè)地址來對外提供服務(wù)。如圖，Django 是 Python 技術(shù)棧最流行的 Web 框架。

Nginx 和后端服務(wù)之間的交互在本質(zhì)上也可以理解為 RPC 數(shù)據(jù)交互。也許你會(huì)爭辯說 Nginx 和后端服務(wù)之間使用的是 HTTP 協(xié)議，走的是短連接，嚴(yán)格上不能算是 RPC 調(diào)用。

你說的沒錯(cuò)，不過 Nginx 和后端服務(wù)之間還可以走其它的協(xié)議，比如 uwsgi 協(xié)議、fastcgi 協(xié)議等，這兩個(gè)協(xié)議都是采用了比 HTTP 協(xié)議更加節(jié)省流量的二進(jìn)制協(xié)議。如上圖所示，uWSGI 是著名的 Python 容器，使用它可以啟動(dòng) uwsgi 協(xié)議的服務(wù)器對外提供服務(wù)。

uwsgi 通訊協(xié)議在 Python 語言體系里使用非常普遍，如果一個(gè)企業(yè)內(nèi)部使用 Python 語言棧搭建 Web 服務(wù)，那么他們在生產(chǎn)環(huán)境部署 Python 應(yīng)用的時(shí)候不是在使用 HTTP 協(xié)議就是在使用 uwsgi 協(xié)議來和 Nginx 之間建立通訊。

Fastcgi 協(xié)議在 PHP 語言體系里非常常見，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，一般包括一個(gè) NameNode 和多個(gè) DataNode，NameNode 和 DataNode 之間就是通過一種稱為 Hadoop RPC 的二進(jìn)制協(xié)議進(jìn)行通訊。

TensorFlow 與 RPC

在人工智能領(lǐng)域，RPC 也很重要，著名的 TensorFlow 框架如果需要處理上億的數(shù)據(jù)，就需要依靠分布式計(jì)算力，需要集群化，當(dāng)多個(gè)分布式節(jié)點(diǎn)需要集體智慧時(shí)，就必須引入 RPC 技術(shù)進(jìn)行通訊。Tensorflow Cluster 的 RPC 通訊框架使用了 Google 內(nèi)部自研的 gRPC 框架。

HTTP 調(diào)用其實(shí)也是一種特殊的 RPC

HTTP1.0 協(xié)議時(shí)，HTTP 調(diào)用還只能是短鏈接調(diào)用，一個(gè)請求來回之后連接就會(huì)關(guān)閉。HTTP1.1 在 HTTP1.0 協(xié)議的基礎(chǔ)上進(jìn)行了改進(jìn)，引入了 KeepAlive 特性可以保持 HTTP 連接長時(shí)間不斷開，以便在同一個(gè)連接之上進(jìn)行多次連續(xù)的請求，進(jìn)一步拉近了 HTTP 和 RPC 之間的距離。

當(dāng) HTTP 協(xié)議進(jìn)化到 2.0 之后，Google 開源了一個(gè)建立在 HTTP2.0 協(xié)議之上的通信框架直接取名為 gRPC，也就是 Google RPC，這時(shí) HTTP 和 RPC 之間已經(jīng)沒有非常明顯的界限了。所以在后文我們不再明確強(qiáng)調(diào) RPC 和 HTTP 請求調(diào)用之間的細(xì)微區(qū)別了，直接統(tǒng)一稱之為 RPC。

HTTP VS RPC （普通話 VS 方言）

HTTP 與 RPC 的關(guān)系就好比普通話與方言的關(guān)系。要進(jìn)行跨企業(yè)服務(wù)調(diào)用時(shí)，往往都是通過 HTTP API，也就是普通話，雖然效率不高，但是通用，沒有太多溝通的學(xué)習(xí)成本。但是在企業(yè)內(nèi)部還是 RPC 更加高效，同一個(gè)企業(yè)公用一套方言進(jìn)行高效率的交流，要比通用的 HTTP 協(xié)議來交流更加節(jié)省資源。整個(gè)中國有非常多的方言，正如有很多的企業(yè)內(nèi)部服務(wù)各有自己的一套交互協(xié)議一樣。雖然國家一直在提倡使用普通話交流，但是這么多年過去了，你回一趟家鄉(xiāng)探個(gè)親什么的就會(huì)發(fā)現(xiàn)身邊的人還是流行說方言。

如果再深入一點(diǎn)說，普通話本質(zhì)上也是一種方言，只不過它是官方的方言，使用最為廣泛的方言，相比而言其它方言都是小語種，小語種之中也會(huì)有幾個(gè)使用比較廣泛比較特色的方言占比也會(huì)比較大。這就好比開源 RPC 協(xié)議中 Protobuf 和 Thrift 一樣，它們兩應(yīng)該是 RPC 協(xié)議中使用最為廣泛的兩個(gè)。

在此我向大家推薦一個(gè) Java高級群 ： 725633148   里面會(huì)分享一些資深架構(gòu)師錄制的視頻錄像：（有 Spring，MyBatis，Netty源碼分析，高并發(fā)、高性能、分布式、微服務(wù)架構(gòu)的原理，JVM性能優(yōu)化、分布式架構(gòu)）等這些成為架構(gòu)師必備的知識體系 進(jìn)群馬上免費(fèi)領(lǐng)取，目前受益良多！

換個(gè)角度看世界

如果兩個(gè)子系統(tǒng)沒有在網(wǎng)絡(luò)上進(jìn)行分離，而是運(yùn)行在同一個(gè)操作系統(tǒng)實(shí)例之上的兩個(gè)進(jìn)程時(shí)，它們之間的通信手段還可以更加豐富。除了以上提到的幾種分布式解決方案之外，還有共享內(nèi)存、信號量、文件系統(tǒng)、內(nèi)核消息隊(duì)列、管道等，本質(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)非常少見了，因?yàn)閱螜C(jī)應(yīng)用意味著單點(diǎn)故障 —— “一人摔跤全家跌倒”。業(yè)務(wù)子系統(tǒng)往往都需要經(jīng)物理網(wǎng)絡(luò)棧進(jìn)行隔離，因此分布式解決方案在要求高可用無間斷服務(wù)的企業(yè)環(huán)境里便大有作為，這也讓 RPC 迎來自己大放異彩的時(shí)代。

前文提到的分布式子系統(tǒng)交互方案，除了 RPC 技術(shù)之外還有數(shù)據(jù)庫、消息隊(duì)列和緩存。但其實(shí)這三者本質(zhì)上是 RPC 技術(shù)的一個(gè)應(yīng)用組合。我們可以將數(shù)據(jù)庫服務(wù)理解為下面這張圖：

可以看出，子系統(tǒng)和數(shù)據(jù)庫之間的交互也是通過 RPC 進(jìn)行的，只不過這里是三個(gè)子系統(tǒng)之間復(fù)雜的組合消息交互罷了。如果再深入進(jìn)去，你會(huì)發(fā)現(xiàn)，這里的數(shù)據(jù)庫不是那種單機(jī)數(shù)據(jù)庫，而是具備主從復(fù)制功能的數(shù)據(jù)庫，比如 MySQL。在互聯(lián)網(wǎng)企業(yè)里一般都會(huì)使用這種主從讀寫分離的數(shù)據(jù)庫。一個(gè)業(yè)務(wù)子系統(tǒng)將數(shù)據(jù)寫往主庫，主庫再將數(shù)據(jù)同步到從庫，然后另一個(gè)業(yè)務(wù)子系統(tǒng)又從從庫里將數(shù)據(jù)取出來。這時(shí)又可以進(jìn)一步將它們看成是四個(gè)子系統(tǒng)之間進(jìn)行的更加復(fù)雜的 RPC 數(shù)據(jù)交互。

小結(jié)

現(xiàn)在，讀者應(yīng)該可以深刻理解 RPC 在互聯(lián)網(wǎng)企業(yè)技術(shù)中的重要地位。從技術(shù)復(fù)雜性角度，也應(yīng)該可以明白為什么說對 RPC 技術(shù)的理解水平是評判一個(gè)程序員是不是高級程序員的重要標(biāo)準(zhǔn)之一。

在下一節(jié)，我們將對 RPC 的交互原理進(jìn)行深入的學(xué)習(xí)，先把地基打牢，再開始實(shí)戰(zhàn)開發(fā)。

思考題

請讀者思考一下，在平時(shí)的后端開發(fā)中，還有哪些地方用到了「類 RPC」技術(shù)？