本文源自一次面試官的提問：說說你對(duì)于RPC框架的了解，你知道哪些RPC框架，以及為什么RPC歷經(jīng)幾十年還能不斷推出新的框架。

我覺得這個(gè)問題很有意思。在IT界RPC真的是一個(gè)“奇葩”，奇葩在每過一段時(shí)間都會(huì)有新的RPC框架出現(xiàn)，網(wǎng)絡(luò)上仍然在不斷爭(zhēng)論哪個(gè)RPC框架更好，而這些RPC框架還有很多還是大廠的杰作，大廠們仿佛樂此不疲。

要知道RPC的歷史可以追溯到1990年代初期，那時(shí)候“開放軟件基金會(huì)”(Open Software Foundation，OSF)和業(yè)界主流的計(jì)算機(jī)廠商一期指定了名為分布式計(jì)算環(huán)境（Distributed Computing Environment）的分布式技術(shù)體系，當(dāng)時(shí)就定出了一個(gè)遠(yuǎn)程服務(wù)調(diào)用的規(guī)范(Remote Procedure Call,RPC)，這個(gè)規(guī)定被稱為DCE/RPC，后來Sun公司又開發(fā)出來一個(gè)ONC RPC,在這個(gè)時(shí)期基本上確定了RPC的很多概念和技術(shù)關(guān)注點(diǎn)，其中有很多解決思路，即使到了今天仍然有巨大的借鑒意義。

和RPC同期的很多技術(shù)或者框架很多都已經(jīng)淹沒在歷史之中了，連當(dāng)初盛極一時(shí)的EJB，現(xiàn)在已經(jīng)幾乎沒人使用了，但是RPC卻煥發(fā)了新的活力。

為什么歷經(jīng)三十多年，RPC還能不斷推陳出新，被抽推崇呢？我認(rèn)真思考這個(gè)問題的原因，有了一些不知是否成熟的想法，于是便記錄下來。

再談?wù)凴PC的理解

RPC（Remote Procedure Call，遠(yuǎn)程過程調(diào)用），是一種通信協(xié)議，用于不同計(jì)算機(jī)之間的遠(yuǎn)程通信。它允許應(yīng)用程序通過網(wǎng)絡(luò)調(diào)用遠(yuǎn)程計(jì)算機(jī)上的服務(wù)或函數(shù)，并獲取返回結(jié)果。RPC隱藏了底層網(wǎng)絡(luò)通信的細(xì)節(jié)，使得遠(yuǎn)程調(diào)用就像本地調(diào)用一樣簡(jiǎn)單和透明。

在RPC中，通常有一個(gè)客戶端和一個(gè)服務(wù)器端?？蛻舳税l(fā)起遠(yuǎn)程調(diào)用請(qǐng)求，服務(wù)器端接收請(qǐng)求并執(zhí)行相應(yīng)的操作，然后將結(jié)果返回給客戶端。RPC可以跨越不同的編程語言和操作系統(tǒng)，使得分布式系統(tǒng)中的不同組件能夠進(jìn)行相互通信和協(xié)作。

RPC的實(shí)現(xiàn)通常包括以下關(guān)鍵組件：

1. 定義接口：RPC通過定義接口描述遠(yuǎn)程服務(wù)的方法和參數(shù)，通常使用IDL（Interface Definition Language）來定義接口規(guī)范，例如使用Protocol Buffers、Thrift或gRPC等。
2. 序列化與反序列化：在遠(yuǎn)程調(diào)用過程中，需要將方法參數(shù)和返回值序列化為字節(jié)流進(jìn)行傳輸，然后在對(duì)端進(jìn)行反序列化。這樣可以確?？缇W(wǎng)絡(luò)傳輸?shù)臄?shù)據(jù)能夠被正確地重建和解析。
3. 通信協(xié)議：RPC使用不同的通信協(xié)議進(jìn)行數(shù)據(jù)傳輸，如HTTP、TCP、UDP等。通信協(xié)議負(fù)責(zé)在客戶端和服務(wù)器之間建立連接，并進(jìn)行數(shù)據(jù)的可靠傳輸。
4. 遠(yuǎn)程調(diào)用管理：RPC框架通常提供遠(yuǎn)程調(diào)用的管理功能，包括請(qǐng)求的路由、負(fù)載均衡、故障恢復(fù)等。這些功能確保請(qǐng)求能夠被正確地路由到相應(yīng)的服務(wù)節(jié)點(diǎn)，并能夠應(yīng)對(duì)節(jié)點(diǎn)故障或網(wǎng)絡(luò)中斷的情況。
5. 安全性和認(rèn)證：由于RPC涉及跨網(wǎng)絡(luò)通信，安全性和認(rèn)證是重要考慮因素。RPC框架通常提供身份驗(yàn)證、加密傳輸和訪問控制等機(jī)制，以保護(hù)數(shù)據(jù)的機(jī)密性和完整性。

于是乎，你可以看到接口定義的方式可以不同、序列化和反序列化的機(jī)制可以不同、通信的協(xié)議可以不同、路由和安全方面的建設(shè)可以不同，這就給了各類RPC框架有非常大的想象空間，每個(gè)RPC框架都可以有自己獨(dú)特的方面。

所以我們看到有各種各樣我們所熟知的框架出現(xiàn)：

• CORBA（Common Object Request Broker Architecture，OMG）
• JAVA RMI（Sun/Oracle）
• Thrift（Facebook/Apache）
• Dubbo（阿里巴巴/Apache）
• gRPC（google）
• Motan1/2（新浪）
• Finagle（Twitter）
• brpc（百度/Apache）
• .NET Remoting（微軟）
• Arvo（Hadoop）

他們有的主要支持C++，有的主要支持Java，有的支持各類語言，有的以簡(jiǎn)單見長(zhǎng)，有的則以性能取勝，各有特色。

要深入了解RPC，需要追溯一下RPC的發(fā)展史。

RPC的發(fā)展史

RPC的發(fā)展歷史可以追溯到上世紀(jì)80年代，主要分為以下階段：

1. 早期階段： 在早期階段，RPC的概念開始出現(xiàn)并得到了實(shí)踐。最早的RPC實(shí)現(xiàn)包括Sun Microsystems的NFS（Network File System）和Apollo Systems的NCS（Network Computing System），它們都是為了在分布式系統(tǒng)中實(shí)現(xiàn)遠(yuǎn)程調(diào)用而設(shè)計(jì)的，這個(gè)階段是分布式技術(shù)的萌芽時(shí)期。
2. 基于傳統(tǒng)協(xié)議的RPC出現(xiàn)： 隨著網(wǎng)絡(luò)技術(shù)的發(fā)展，RPC的概念開始在不同的領(lǐng)域得到應(yīng)用。許多基于傳統(tǒng)協(xié)議的RPC實(shí)現(xiàn)出現(xiàn)，如DCE RPC（Distributed Computing Environment RPC）和CORBA（Common Object Request Broker Architecture）。這些實(shí)現(xiàn)使用了自定義的IDL（Interface Definition Language）和協(xié)議，以實(shí)現(xiàn)跨平臺(tái)、跨語言的遠(yuǎn)程調(diào)用，這個(gè)時(shí)期的RPC協(xié)議應(yīng)用還不廣泛，性能存在較大的問題。
3. Web服務(wù)和SOAP： 隨著Web的興起，RPC的關(guān)注點(diǎn)逐漸轉(zhuǎn)向Web服務(wù)。Web服務(wù)使用SOAP（Simple Object Access Protocol）作為通信協(xié)議，通過XML進(jìn)行數(shù)據(jù)傳輸。SOAP基于HTTP和XML，使得跨網(wǎng)絡(luò)的遠(yuǎn)程調(diào)用更加方便。SOAP提供了基于WSDL（Web Services Description Language）的接口定義和基于UDDI（Universal Description, Discovery, and Integration）的服務(wù)發(fā)現(xiàn)，SOAP可以認(rèn)為是RPC的一種案例，這階段還出現(xiàn)了XML-RPC，后來也漸漸淘汰了。
4. REST和Web API時(shí)代： 隨著Web的演進(jìn)，基于REST（Representational State Transfer）的Web API成為了一種更簡(jiǎn)潔、輕量級(jí)的遠(yuǎn)程調(diào)用方式。RESTful API使用HTTP協(xié)議，通過URL和HTTP方法（如GET、POST、PUT、DELETE）來表達(dá)資源的操作。RESTful API的普及使得基于HTTP的RPC變得更加流行，并廣泛應(yīng)用于Web開發(fā)和移動(dòng)應(yīng)用程序。
5. 現(xiàn)代RPC框架： 進(jìn)入21世紀(jì)，出現(xiàn)了許多現(xiàn)代化的RPC框架，如gRPC、Apache Thrift、Apache Dubbo等。這些框架提供了更高效、更強(qiáng)大的RPC能力，并支持多種編程語言和平臺(tái)。它們通常采用二進(jìn)制協(xié)議（如Protocol Buffers）和高性能的網(wǎng)絡(luò)通信技術(shù)（如HTTP/2、TCP）來提升性能和效率。

隨著技術(shù)的不斷演進(jìn)和需求的變化，RPC的發(fā)展也在不斷推進(jìn)，協(xié)議在變化，通信網(wǎng)絡(luò)技術(shù)也在變化，發(fā)展到現(xiàn)代RPC框架則提供了更多的功能和特性，使得分布式系統(tǒng)的開發(fā)更加便捷和高效。

RPC歷經(jīng)數(shù)十年而不衰的原因?

現(xiàn)在可以嘗試回答這個(gè)問題了，首先第一點(diǎn)我覺得應(yīng)該是分布式系統(tǒng)的需求。

1、分布式系統(tǒng)的需求

單體應(yīng)用時(shí)代，摩爾定律盛行，單個(gè)應(yīng)用就能大部分解決業(yè)務(wù)需求，壓根不涉及RPC，隨著互聯(lián)網(wǎng)的迅速發(fā)展和應(yīng)用的擴(kuò)大，單體應(yīng)用無法滿足業(yè)務(wù)需要，對(duì)于分布式系統(tǒng)的需求越來越強(qiáng)烈。

分布式系統(tǒng)中的各個(gè)組件需要進(jìn)行跨網(wǎng)絡(luò)的通信和協(xié)作，RPC作為一種重要的通信協(xié)議，能夠滿足分布式系統(tǒng)的需求，提供高效、可靠的遠(yuǎn)程調(diào)用機(jī)制。隨著分布式系統(tǒng)規(guī)模的不斷擴(kuò)大和復(fù)雜性的增加，新的RPC框架不斷涌現(xiàn)，以滿足不同場(chǎng)景下的需求。

SOA、微服務(wù)、service mesh這些技術(shù)相繼出現(xiàn)，這些分布式架構(gòu)都少不了RPC這個(gè)重要的組件，于是產(chǎn)生了各種各樣，適配不同場(chǎng)景的RPC框架。

2、RPC相關(guān)技術(shù)的演進(jìn)

隨著計(jì)算機(jī)技術(shù)和網(wǎng)絡(luò)技術(shù)的不斷進(jìn)步，RPC的實(shí)現(xiàn)方式和性能也在不斷提升。新的RPC框架往往借鑒和采用了先進(jìn)的技術(shù)，如高性能的網(wǎng)絡(luò)通信協(xié)議（如HTTP/2、gRPC的基于HTTP/2的傳輸），高效的序列化和反序列化機(jī)制（如Protocol Buffers），以及負(fù)載均衡、故障恢復(fù)等機(jī)制的優(yōu)化。這些新技術(shù)的應(yīng)用使得RPC框架更加高效、可靠，并具備更好的可擴(kuò)展性和彈性。

一旦協(xié)議、網(wǎng)絡(luò)、安全、故障恢復(fù)能機(jī)制有新的進(jìn)展，勢(shì)必就會(huì)帶來RPC框架的更新。

3、多語言的支持

RPC框架通常支持多種編程語言，使得不同語言編寫的應(yīng)用程序能夠進(jìn)行跨語言的遠(yuǎn)程調(diào)用。這對(duì)于大型分布式系統(tǒng)的開發(fā)非常重要，因?yàn)椴煌膱F(tuán)隊(duì)和組織可能使用不同的編程語言開發(fā)各自的組件,新的RPC框架通常會(huì)擴(kuò)展語言支持，以滿足多樣化的開發(fā)需求。

我們發(fā)現(xiàn)每個(gè)時(shí)代都會(huì)迸發(fā)出一些新的開發(fā)語言，比如現(xiàn)在云原生時(shí)代，Go和Rust語言就大受歡迎，那么支持Go語言和Rust語言的RPC框架就會(huì)出現(xiàn)，這也是RPC的一個(gè)活力源頭所在。

4、不同場(chǎng)景的需求

不同的應(yīng)用場(chǎng)景對(duì)RPC框架提出了各種需求，例如高并發(fā)、低延遲、可擴(kuò)展性、安全性等。新的RPC框架通常會(huì)根據(jù)不同場(chǎng)景的需求進(jìn)行針對(duì)性的優(yōu)化和功能擴(kuò)展，以滿足特定的應(yīng)用需求。

特別是一些大廠，內(nèi)部業(yè)務(wù)復(fù)雜，對(duì)于RPC有一些獨(dú)特的需求，另外也需要匹配內(nèi)部的技術(shù)棧，這樣子就常常造出了新輪子。

其實(shí)RPC確實(shí)挺有意思的，展現(xiàn)了技術(shù)的持久生命力，另外別看RPC就那幾個(gè)組件，實(shí)際自己編寫一個(gè)就知道了，需要注意的技術(shù)細(xì)節(jié)實(shí)在是太多了，也是一個(gè)非常鍛煉人的活計(jì)，如果能夠自己獨(dú)立寫一個(gè)功能比較豐富、高性能的RPC框架出來的話，我想編程能力至少應(yīng)該能算是登堂入室了。