# 什么是 RPC？ # Republic of People of China 咳咳。。。。下面進入正題。。。。。 # RPC介紹 遠程過程調用（Remote Procedure Call，縮寫為 RPC）是一個計算機通信協議。 該協議允許運行于一臺計算機的程序調用另一臺計算機的子程序，而程序員無需額外地為這個交互作用編程。 如果涉及的軟件采用面向對象編程，那么遠程過程調用亦可稱作遠程調用或遠程方法調用，比如 Java RMI。 有關RPC的想法至少可以追溯到1976年以“信使報”（Courier）的名義使用。RPC首次在UNIX平臺上普及的執行工具程序是SUN公司的RPC（現在叫ONC RPC）。它被用作SUN的NFC的主要部件。ONC RPC今天仍在服務器上被廣泛使用。 另一個早期UNIX平臺的工具是“阿波羅”計算機網絡計算系統（NCS），它很快就用做OSF的分布計算環境（DCE）中的DCE/RPC的基礎，并補充了DCOM。 遠程過程調用是一個分布式計算的客戶端-服務器（Client/Server）的例子，它簡單而又廣受歡迎。 遠程過程調用總是由客戶端對服務器發出一個執行若干過程請求，并用客戶端提供的參數。執行結果將返回給客戶端。 由于存在各式各樣的變體和細節差異，對應地派生了各式遠程過程調用協議，而且它們并不互相兼容。 為了允許不同的客戶端均能訪問服務器，許多標準化的 RPC 系統應運而生了。其中大部分采用接口描述語言（Interface Description Language，IDL），方便跨平臺的遠程過程調用。 有些實現擴展了遠程調用的模型，實現了雙向的服務調用，但是不管怎樣，調用過程還是由一個客戶端發起，服務器端提供響應，基本模型沒有變化。 服務的調用過程為： 1. client調用client stub，這是一次本地過程調用 2. client stub將參數打包成一個消息，然后發送這個消息。打包過程也叫做 marshalling 3. client所在的系統將消息發送給server 4. server的的系統將收到的包傳給server stub 5. server stub解包得到參數。 解包也被稱作 unmarshalling 6. 最后server stub調用服務過程. 返回結果按照相反的步驟傳給client ***** # 深入理解RPC——你看或沒看見 它都在那里 ## 什么是 RPC ？ RPC (Remote Procedure Call)即遠程過程調用，是分布式系統常見的一種通信方法，已經有 40 多年歷史。當兩個物理分離的子系統需要建立邏輯上的關聯時，RPC 是牽線搭橋的常見技術手段之一。除 RPC 之外，常見的多系統數據交互方案還有分布式消息隊列、HTTP 請求調用、數據庫和分布式緩存等。  其中 RPC 和 HTTP 調用是沒有經過中間件的，它們是端到端系統的直接數據交互。HTTP 調用其實也可以看成是一種特殊的 RPC，只不過傳統意義上的 RPC 是指長連接數據交互，而 HTTP 一般是指即用即走的短鏈接。 RPC 在我們熟知的各種中間件中都有它的身影。Nginx/Redis/MySQL/Dubbo/Hadoop/Spark/Tensorflow 等重量級開源產品都是在 RPC 技術的基礎上構建出來的，我們這里說的 RPC 指的是廣義的 RPC，也就是分布式系統的通信技術。RPC 在技術中的地位好比我們身邊的空氣，它無處不在，但是又有很多人根本不知道它的存在。 ## Nginx 與 RPC Ngnix 是互聯網企業使用最為廣泛的代理服務器。它可以為后端分布式服務提供負載均衡的功能，它可以將后端多個服務地址聚合為單個地址來對外提供服務。如圖，Django 是 Python 技術棧最流行的 Web 框架。  Nginx 和后端服務之間的交互在本質上也可以理解為 RPC 數據交互。也許你會爭辯說 Nginx 和后端服務之間使用的是 HTTP 協議，走的是短連接，嚴格上不能算是 RPC 調用。  你說的沒錯，不過 Nginx 和后端服務之間還可以走其它的協議，比如 uwsgi 協議、fastcgi 協議等，這兩個協議都是采用了比 HTTP 協議更加節省流量的二進制協議。如上圖所示，uWSGI 是著名的 Python 容器，使用它可以啟動 uwsgi 協議的服務器對外提供服務。 uwsgi 通訊協議在 Python 語言體系里使用非常普遍，如果一個企業內部使用 Python 語言棧搭建 Web 服務，那么他們在生產環境部署 Python 應用的時候不是在使用 HTTP 協議就是在使用 uwsgi 協議來和 Nginx 之間建立通訊。  Fastcgi 協議在 PHP 語言體系里非常常見，Nginx 和 PHP-fpm 進程之間一般較常使用 Fastcgi 協議進行通訊。 ## Hadoop 與 RPC 在大數據技術領域，RPC 也占據了非常重要的地位。大數據領域廣泛應用了非常多的分布式技術，分布式意味著節點的物理隔離，隔離意味著需要通信，通信意味著 RPC 的存在。大數據需要通信的量比業務系統更加龐大，所以在數據通信優化上做的更深。  比如最常見的 Hadoop 文件系統 hdfs，一般包括一個 NameNode 和多個 DataNode，NameNode 和 DataNode 之間就是通過一種稱為 Hadoop RPC 的二進制協議進行通訊。 ## TensorFlow 與 RPC 在人工智能領域，RPC 也很重要，著名的 TensorFlow 框架如果需要處理上億的數據，就需要依靠分布式計算力，需要集群化，當多個分布式節點需要集體智慧時，就必須引入 RPC 技術進行通訊。Tensorflow Cluster 的 RPC 通訊框架使用了 Google 內部自研的 gRPC 框架。  ## HTTP 調用其實也是一種特殊的 RPC HTTP1.0 協議時，HTTP 調用還只能是短鏈接調用，一個請求來回之后連接就會關閉。HTTP1.1 在 HTTP1.0 協議的基礎上進行了改進，引入了 KeepAlive 特性可以保持 HTTP 連接長時間不斷開，以便在同一個連接之上進行多次連續的請求，進一步拉近了 HTTP 和 RPC 之間的距離。  當 HTTP 協議進化到 2.0 之后，Google 開源了一個建立在 HTTP2.0 協議之上的通信框架直接取名為 gRPC，也就是 Google RPC，這時 HTTP 和 RPC 之間已經沒有非常明顯的界限了。所以在后文我們不再明確強調 RPC 和 HTTP 請求調用之間的細微區別了，直接統一稱之為 RPC。  ## HTTP VS RPC （普通話 VS 方言） HTTP 與 RPC 的關系就好比普通話與方言的關系。要進行跨企業服務調用時，往往都是通過 HTTP API，也就是普通話，雖然效率不高，但是通用，沒有太多溝通的學習成本。但是在企業內部還是 RPC 更加高效，同一個企業公用一套方言進行高效率的交流，要比通用的 HTTP 協議來交流更加節省資源。整個中國有非常多的方言，正如有很多的企業內部服務各有自己的一套交互協議一樣。雖然國家一直在提倡使用普通話交流，但是這么多年過去了，你回一趟家鄉探個親什么的就會發現身邊的人還是流行說方言。 如果再深入一點說，普通話本質上也是一種方言，只不過它是官方的方言，使用最為廣泛的方言，相比而言其它方言都是小語種，小語種之中也會有幾個使用比較廣泛比較特色的方言占比也會比較大。這就好比開源 RPC 協議中 Protobuf 和 Thrift 一樣，它們兩應該是 RPC 協議中使用最為廣泛的兩個。 在此我向大家推薦一個Java高級群?：**725633148**里面會分享一些資深架構師錄制的視頻錄像：（有Spring，MyBatis，Netty源碼分析，高并發、高性能、分布式、微服務架構的原理，JVM性能優化、分布式架構）等這些成為架構師必備的知識體系 進群馬上免費領取，目前受益良多！ ## 換個角度看世界 如果兩個子系統沒有在網絡上進行分離，而是運行在同一個操作系統實例之上的兩個進程時，它們之間的通信手段還可以更加豐富。除了以上提到的幾種分布式解決方案之外，還有共享內存、信號量、文件系統、內核消息隊列、管道等，本質上都是通過操作系統內核機制來進行數據和消息的交互而無須經過網絡協議棧。 但在現代企業服務中，這種單機應用已經非常少見了，因為單機應用意味著單點故障 —— “一人摔跤全家跌倒”。業務子系統往往都需要經物理網絡棧進行隔離，因此分布式解決方案在要求高可用無間斷服務的企業環境里便大有作為，這也讓 RPC 迎來自己大放異彩的時代。 前文提到的分布式子系統交互方案，除了 RPC 技術之外還有數據庫、消息隊列和緩存。但其實這三者本質上是 RPC 技術的一個應用組合。我們可以將數據庫服務理解為下面這張圖：  可以看出，子系統和數據庫之間的交互也是通過 RPC 進行的，只不過這里是三個子系統之間復雜的組合消息交互罷了。如果再深入進去，你會發現，這里的數據庫不是那種單機數據庫，而是具備主從復制功能的數據庫，比如 MySQL。在互聯網企業里一般都會使用這種主從讀寫分離的數據庫。一個業務子系統將數據寫往主庫，主庫再將數據同步到從庫，然后另一個業務子系統又從從庫里將數據取出來。這時又可以進一步將它們看成是四個子系統之間進行的更加復雜的 RPC 數據交互。  ## 小結 現在，讀者應該可以深刻理解 RPC 在互聯網企業技術中的重要地位。從技術復雜性角度，也應該可以明白為什么說對 RPC 技術的理解水平是評判一個程序員是不是高級程序員的重要標準之一。