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

我覺得這個問題很有意思。在IT界RPC真的是一個“奇葩”，奇葩在每過一段時間都會有新的RPC框架出現，網絡上仍然在不斷爭論哪個RPC框架更好，而這些RPC框架還有很多還是大廠的杰作，大廠們仿佛樂此不疲。

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

和RPC同期的很多技術或者框架很多都已經淹沒在歷史之中了，連當初盛極一時的EJB，現在已經幾乎沒人使用了，但是RPC卻煥發了新的活力。

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

再談談RPC的理解

RPC（Remote Procedure Call，遠程過程調用），是一種通信協議，用于不同計算機之間的遠程通信。它允許應用程序通過網絡調用遠程計算機上的服務或函數，并獲取返回結果。RPC隱藏了底層網絡通信的細節，使得遠程調用就像本地調用一樣簡單和透明。

在RPC中，通常有一個客戶端和一個服務器端。客戶端發起遠程調用請求，服務器端接收請求并執行相應的操作，然后將結果返回給客戶端。RPC可以跨越不同的編程語言和操作系統，使得分布式系統中的不同組件能夠進行相互通信和協作。

RPC的實現通常包括以下關鍵組件：

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

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

所以我們看到有各種各樣我們所熟知的框架出現：

• 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，有的支持各類語言，有的以簡單見長，有的則以性能取勝，各有特色。

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

RPC的發展史

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

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

隨著技術的不斷演進和需求的變化，RPC的發展也在不斷推進，協議在變化，通信網絡技術也在變化，發展到現代RPC框架則提供了更多的功能和特性，使得分布式系統的開發更加便捷和高效。

RPC歷經數十年而不衰的原因?

現在可以嘗試回答這個問題了，首先第一點我覺得應該是分布式系統的需求。

1、分布式系統的需求

單體應用時代，摩爾定律盛行，單個應用就能大部分解決業務需求，壓根不涉及RPC，隨著互聯網的迅速發展和應用的擴大，單體應用無法滿足業務需要，對于分布式系統的需求越來越強烈。

分布式系統中的各個組件需要進行跨網絡的通信和協作，RPC作為一種重要的通信協議，能夠滿足分布式系統的需求，提供高效、可靠的遠程調用機制。隨著分布式系統規模的不斷擴大和復雜性的增加，新的RPC框架不斷涌現，以滿足不同場景下的需求。

SOA、微服務、service mesh這些技術相繼出現，這些分布式架構都少不了RPC這個重要的組件，于是產生了各種各樣，適配不同場景的RPC框架。

2、RPC相關技術的演進

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

一旦協議、網絡、安全、故障恢復能機制有新的進展，勢必就會帶來RPC框架的更新。

3、多語言的支持

RPC框架通常支持多種編程語言，使得不同語言編寫的應用程序能夠進行跨語言的遠程調用。這對于大型分布式系統的開發非常重要，因為不同的團隊和組織可能使用不同的編程語言開發各自的組件,新的RPC框架通常會擴展語言支持，以滿足多樣化的開發需求。

我們發現每個時代都會迸發出一些新的開發語言，比如現在云原生時代，Go和Rust語言就大受歡迎，那么支持Go語言和Rust語言的RPC框架就會出現，這也是RPC的一個活力源頭所在。

4、不同場景的需求

不同的應用場景對RPC框架提出了各種需求，例如高并發、低延遲、可擴展性、安全性等。新的RPC框架通常會根據不同場景的需求進行針對性的優化和功能擴展，以滿足特定的應用需求。

特別是一些大廠，內部業務復雜，對于RPC有一些獨特的需求，另外也需要匹配內部的技術棧，這樣子就常常造出了新輪子。

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