五分鐘學後端技術：如何學習Java工程師必須掌握的RPC

宣告

本文轉自 https://developer.51cto.com/art/201906/597963.htm

什麼是RPC

RPC（Remote Procedure Call）：遠端過程呼叫，它是一種通過網路從遠端計算機程式上請求服務，而不需要了解底層網路技術的思想。

RPC 是一種技術思想而非一種規範或協議，常見 RPC 技術和框架有：

• 應用級的服務框架：阿里的 Dubbo/Dubbox、Google gRPC、Spring Boot/Spring Cloud。
• 遠端通訊協議：RMI、Socket、SOAP(HTTP XML)、REST(HTTP JSON)。
• 通訊框架：MINA 和 Netty。

目前流行的開源 RPC 框架還是比較多的，有阿里巴巴的 Dubbo、Facebook 的 Thrift、Google 的 gRPC、Twitter 的 Finagle 等。

常用的RPC框架

• gRPC：是 Google 公佈的開源軟體，基於最新的 HTTP 2.0 協議，並支援常見的眾多程式語言。RPC 框架是基於 HTTP 協議實現的，底層使用到了 Netty 框架的支援。
• Thrift：是 Facebook 的開源 RPC 框架，主要是一個跨語言的服務開發框架。 使用者只要在其之上進行二次開發就行，應用對於底層的 RPC 通訊等都是透明的。不過這個對於使用者來說需要學習特定領域語言這個特性，還是有一定成本的。
• Dubbo：是阿里集團開源的一個極為出名的 RPC 框架，在很多網際網路公司和企業應用中廣泛使用。協議和序列化框架都可以插拔是極其鮮明的特色。

完整的 RPC 框架

在一個典型 RPC 的使用場景中，包含了服務發現、負載、容錯、網路傳輸、序列化等元件，其中“RPC 協議”就指明瞭程式如何進行網路傳輸和序列化。

圖 1：完整 RPC 架構圖

如下是 Dubbo 的設計架構圖，分層清晰，功能複雜：

圖 2：Dubbo 架構圖

RPC 核心功能

RPC 的核心功能是指實現一個 RPC 最重要的功能模組，就是上圖中的”RPC 協議”部分：

圖 3：RPC 核心功能

一個 RPC 的核心功能主要有 5 個部分組成，分別是：客戶端、客戶端 Stub、網路傳輸模組、服務端 Stub、服務端等。

圖 4：RPC 核心功能圖

下面分別介紹核心 RPC 框架的重要組成：

• 客戶端（Client）：服務呼叫方。
• 客戶端存根（Client Stub）：存放服務端地址資訊，將客戶端的請求引數資料資訊打包成網路訊息，再通過網路傳輸傳送給服務端。
• 服務端存根（Server Stub）：接收客戶端傳送過來的請求訊息並進行解包，然後再呼叫本地服務進行處理。
• 服務端（Server）：服務的真正提供者。
• Network Service：底層傳輸，可以是 TCP 或 HTTP。

Python 自帶 RPC Demo

Server.py：

fromSimpleXMLRPCServer importSimpleXMLRPCServer
deffun_add(a,b):
totle = a + b
returntotle
if__name__ == '__main__':
s = SimpleXMLRPCServer(( '0.0.0.0', 8080)) #開啟xmlrpcserver
s.register_function(fun_add) #註冊函式fun_add
print"server is online..."
s.serve_forever #開啟迴圈等待

Client.py：

fromxmlrpclib importServerProxy #匯入xmlrpclib的包
s = ServerProxy( "http://172.171.5.205:8080") #定義xmlrpc客戶端
prints.fun_add( 2, 3) #呼叫伺服器端的函式

開啟服務端：

開啟客戶端：

Wireshark 抓包分析過程

客戶端去往服務端：

• 客戶端 IP：172.171.4.176
• 服務端 IP：172.171.5.95

通訊使用 HTTP 協議，XML 檔案傳輸格式。傳輸的欄位包括：方法名 methodName，兩個引數 2，3。

圖 5：Request 抓包

服務端返回結果，欄位返回值 Value，結果是 5：

圖 6：Response 抓包

在這兩次網路傳輸中使用了 HTTP 協議，建立 HTTP 協議之間有 TCP 三次握手，斷開 HTTP 協議時有 TCP 四次揮手。

圖 7：基於 HTTP 協議的 RPC 連線過程

詳細呼叫過程

Python 自帶 RPC 的 Demo 小程式的實現過程，流程和分工角色可以用下圖來表示：

圖 8：RPC 呼叫詳細流程圖

一次 RPC 呼叫流程如下：

• 服務消費者（Client 客戶端）通過本地呼叫的方式呼叫服務。
• 客戶端存根（Client Stub）接收到呼叫請求後負責將方法、入參等資訊序列化（組裝）成能夠進行網路傳輸的訊息體。
• 客戶端存根（Client Stub）找到遠端的服務地址，並且將訊息通過網路傳送給服務端。
• 服務端存根（Server Stub）收到訊息後進行解碼（反序列化操作）。
• 服務端存根（Server Stub）根據解碼結果呼叫本地的服務進行相關處理
• 服務端(Server)本地服務業務處理。
• 處理結果返回給服務端存根（Server Stub）。
• 服務端存根（Server Stub）序列化結果。
• 服務端存根（Server Stub）將結果通過網路傳送至消費方。
• 客戶端存根（Client Stub）接收到訊息，並進行解碼（反序列化）。
• 服務消費方得到最終結果。

RPC 核心之功能實現

RPC 的核心功能主要由 5 個模組組成，如果想要自己實現一個 RPC，最簡單的方式要實現三個技術點，分別是：

• 服務定址
• 資料流的序列化和反序列化
• 網路傳輸

服務定址

服務定址可以使用 Call ID 對映。在本地呼叫中，函式體是直接通過函式指標來指定的，但是在遠端呼叫中，函式指標是不行的，因為兩個程式的地址空間是完全不一樣的。

所以在 RPC 中，所有的函式都必須有自己的一個 ID。這個 ID 在所有程式中都是唯一確定的。

客戶端在做遠端過程呼叫時，必須附上這個 ID。然後我們還需要在客戶端和服務端分別維護一個函式和Call ID的對應表。

當客戶端需要進行遠端呼叫時，它就查一下這個表，找出相應的 Call ID，然後把它傳給服務端，服務端也通過查表，來確定客戶端需要呼叫的函式，然後執行相應函式的程式碼。

實現方式 服務註冊中心。

要呼叫服務，首先你需要一個服務註冊中心去查詢對方服務都有哪些例項。Dubbo 的服務註冊中心是可以配置的，官方推薦使用 Zookeeper。

實現案例：
RMI（Remote Method Invocation，遠端方法呼叫）也就是 RPC 本身的實現方式。

圖 9：RMI 架構圖

Registry(服務發現)：
藉助 JNDI 釋出並呼叫了 RMI服務。實際上，JNDI 就是一個登錄檔，服務端將服務物件放入到登錄檔中，客戶端從登錄檔中獲取服務物件。

RMI 服務在服務端實現之後需要註冊到 RMI Server 上，然後客戶端從指定的 RMI 地址上 Lookup 服務，呼叫該服務對應的方法即可完成遠端方法呼叫。

Registry 是個很重要的功能，當服務端開發完服務之後，要對外暴露，如果沒有服務註冊，則客戶端是無從呼叫的，即使服務端的服務就在那裡。

序列化和反序列化

客戶端怎麼把引數值傳給遠端的函式呢？在本地呼叫中，我們只需要把引數壓到棧裡，然後讓函式自己去棧裡讀就行。

但是在遠端過程呼叫時，客戶端跟服務端是不同的程式，不能通過記憶體來傳遞引數。

這時候就需要客戶端把引數先轉成一個位元組流，傳給服務端後，再把位元組流轉成自己能讀取的格式。

• 將二進位制流轉換成物件的過程叫做反序列化

這個過程叫序列化和反序列化。同理，從服務端返回的值也需要序列化反序列化的過程。

主流序列化協議優缺點對比

JSON

優點
1 簡單易用開發成本低
2 跨語言
3 輕量級資料交換
4 非冗長性（對比xml標籤簡單括號閉環）

缺點
1 體積大，影響高併發
2 無版本檢查，自己做相容
3 片段的建立和驗證過程比一般的XML複雜
4 缺乏名稱空間導致資訊混合

總結：最簡單最通用的應用協議，使用廣泛，開發效率高，效能相對較低，維護成本較高。

Protobuf

Protobuf是一種以有效並可擴充套件的格式編碼結構化資料的方式。

優點
1 跨語言，可自定義資料結構。
2 欄位被編號，新新增的欄位不影響老結構。解決了向後相容問題。
3 自動化生成程式碼，簡單易用。
4 二進位制訊息，效率高，效能高。
5 Netty等框架整合了該協議，提供了編×××提高開發效率。

缺點
1 二進位制格式，可讀性差（抓包dump後的資料很難看懂）
2 物件冗餘，欄位很多，生成的類較大，佔用空間。
3 預設不具備動態特性（可以通過動態定義生成訊息型別或者動態編譯支援）

總結：簡單快速上手，高效相容性強，維護成本較高。

Thrift（Facebook）

優點
1 序列化和RPC支援一站式解決，比pb更方便
2 跨語言，IDL介面定義語言，自動生成多語言檔案
3 省流量，體積較小
4 包含完整的客戶端/服務端堆疊，可快速實現RPC
5 為服務端提供了多種工作模式，如執行緒池模型、非阻塞模型

缺點
1 早期版本問題較大，0.7以前有相容性問題
2 不支援雙通道
3 rpc方法非執行緒安全，伺服器容易被掛死，需要序列化。
4 預設不具備動態特性（可以通過動態定義生成訊息型別或者動態編譯支援）
5 開發環境、編譯較麻煩

總結：跨語言、實現簡單，初次使用較麻煩，需要避免使用問題和場景限制。

網路傳輸

網路傳輸：
遠端呼叫往往用在網路上，客戶端和服務端是通過網路連線的。

所有的資料都需要通過網路傳輸，因此就需要有一個網路傳輸層。網路傳輸層需要把 Call ID 和序列化後的引數位元組流傳給服務端，然後再把序列化後的呼叫結果傳回客戶端。

只要能完成這兩者的，都可以作為傳輸層使用。因此，它所使用的協議其實是不限的，能完成傳輸就行。

儘管大部分 RPC 框架都使用 TCP 協議，但其實 UDP 也可以，而 gRPC 乾脆就用了 HTTP2。

TCP 的連線是最常見的，簡要分析基於 TCP 的連線：

通常 TCP 連線可以是按需連線（需要呼叫的時候就先建立連線，呼叫結束後就立馬斷掉），也可以是長連線（客戶端和伺服器建立起連線之後保持長期持有，不管此時有無資料包的傳送，可以配合心跳檢測機制定期檢測建立的連線是否存活有效），多個遠端過程呼叫共享同一個連線。

所以，要實現一個 RPC 框架，只需要把以下三點實現了就基本完成了：

• Call ID 對映：可以直接使用函式字串，也可以使用整數 ID。對映表一般就是一個雜湊表。
• 序列化反序列化：可以自己寫，也可以使用 Protobuf 或者 FlatBuffers 之類的。
• 網路傳輸庫：可以自己寫 Socket，或者用 Asio，ZeroMQ，Netty 之類。

RPC 核心之網路傳輸協議

在第三節中說明了要實現一個 RPC，需要選擇網路傳輸的方式。

圖 10：網路傳輸

在 RPC 中可選的網路傳輸方式有多種，可以選擇 TCP 協議、UDP 協議、HTTP 協議。

每一種協議對整體的效能和效率都有不同的影響，如何選擇一個正確的網路傳輸協議呢？首先要搞明白各種傳輸協議在 RPC 中的工作方式。

基於 TCP 協議的 RPC 呼叫

由服務的呼叫方與服務的提供方建立 Socket 連線，並由服務的呼叫方通過 Socket 將需要呼叫的介面名稱、方法名稱和引數序列化後傳遞給服務的提供方，服務的提供方反序列化後再利用反射呼叫相關的方法。

最後將結果返回給服務的呼叫方，整個基於 TCP 協議的 RPC 呼叫大致如此。

但是在例項應用中則會進行一系列的封裝，如 RMI 便是在 TCP 協議上傳遞可序列化的 Java 物件。

基於 HTTP 協議的 RPC 呼叫

該方法更像是訪問網頁一樣，只是它的返回結果更加單一簡單。

其大致流程為：
由服務的呼叫者向服務的提供者傳送請求，這種請求的方式可能是 GET、POST、PUT、DELETE 等中的一種，服務的提供者可能會根據不同的請求方式做出不同的處理，或者某個方法只允許某種請求方式。

而呼叫的具體方法則是根據 URL 進行方法呼叫，而方法所需要的引數可能是對服務呼叫方傳輸過去的 XML 資料或者 JSON 資料解析後的結果，最後返回 JOSN 或者 XML 的資料結果。

由於目前有很多開源的 Web 伺服器，如 Tomcat，所以其實現起來更加容易，就像做 Web 專案一樣。

兩種方式對比

基於 TCP 的協議實現的 RPC 呼叫，由於 TCP 協議處於協議棧的下層，能夠更加靈活地對協議欄位進行定製，減少網路開銷，提高效能，實現更大的吞吐量和併發數。

但是需要更多關注底層複雜的細節，實現的代價更高。同時對不同平臺，如安卓，iOS 等，需要重新開發出不同的工具包來進行請求傳送和相應解析，工作量大，難以快速響應和滿足使用者需求。

基於 HTTP 協議實現的 RPC 則可以使用 JSON 和 XML 格式的請求或響應資料。

而 JSON 和 XML 作為通用的格式標準（使用 HTTP 協議也需要序列化和反序列化，不過這不是該協議下關心的內容，成熟的 Web 程式已經做好了序列化內容），開源的解析工具已經相當成熟，在其上進行二次開發會非常便捷和簡單。

但是由於 HTTP 協議是上層協議，傳送包含同等內容的資訊，使用 HTTP 協議傳輸所佔用的位元組數會比使用 TCP 協議傳輸所佔用的位元組數更高。

因此在同等網路下，通過 HTTP 協議傳輸相同內容，效率會比基於 TCP 協議的資料效率要低，資訊傳輸所佔用的時間也會更長，當然壓縮資料，能夠縮小這一差距。

使用 RabbitMQ 的 RPC 架構

在 OpenStack 中服務與服務之間使用 RESTful API 呼叫，而在服務內部則使用 RPC 呼叫各個功能模組。

正是由於使用了 RPC 來解耦服務內部功能模組，使得 OpenStack 的服務擁有擴充套件性強，耦合性低等優點。

OpenStack 的 RPC 架構中，加入了訊息佇列 RabbitMQ，這樣做的目的是為了保證 RPC 在訊息傳遞過程中的安全性和穩定性。

下面分析 OpenStack 中使用 RabbitMQ 如何實現 RPC 的呼叫。

RabbitMQ 簡介

以下摘錄自知乎：

對於初學者，舉一個飯店的例子來解釋這三個分別是什麼吧。不是百分百恰當，但是應該足以解釋這三者的區別。

RPC：
假設你是一個飯店裡的服務員，顧客向你點菜，但是你不會做菜，所以你採集了顧客要點什麼之後告訴後廚去做顧客點的菜，這叫 RPC(remote procedure call)，因為廚房的廚師相對於服務員而言是另外一個人(在計算機的世界裡就是 Remote 的機器上的一個程式)。廚師做好了的菜就是RPC的返回值。

任務佇列和訊息佇列：
本質都是佇列，所以就只舉一個任務佇列的例子。假設這個飯店在高峰期顧客很多，而廚師只有很少的幾個，所以服務員們不得不把單子按下單順序放在廚房的桌子上，供廚師們一個一個做，這一堆單子就是任務佇列，廚師們每做完一個菜，就從桌子上的訂單裡再取出一個單子繼續做菜。

角色分擔如下圖：

圖 11：RabbitMQ 在 RPC 中角色

使用 RabbitMQ 的好處：

• 同步變非同步：可以使用執行緒池將同步變成非同步，但是缺點是要自己實現執行緒池，並且強耦合。使用訊息佇列可以輕鬆將同步請求變成非同步請求。
• 低內聚高耦合：解耦，減少強依賴。
• 流量削峰：通過訊息佇列設定請求最大值，超過閥值的拋棄或者轉到錯誤介面。
• 網路通訊效能提高：TCP 的建立和銷燬開銷大，建立 3 次握手，銷燬 4 次分手，高峰時成千上萬條的連結會造成資源的巨大浪費，而且作業系統每秒處理 TCP 的數量也是有數量限制的，必定造成效能瓶頸。 RabbitMQ 採用通道通訊，不採用 TCP 直接通訊。一條執行緒一條通道，多條執行緒多條通道，公用一個 TCP 連線。 一條 TCP 連線可以容納無限條通道（硬碟容量足夠的話），不會造成效能瓶頸。

RabbitMQ 的三種型別的交換器

RabbitMQ 使用 Exchange（交換機）和 Queue（佇列）來實現訊息佇列。

在 RabbitMQ 中一共有三種交換機型別，每一種交換機型別都有很鮮明的特徵。

基於這三種交換機型別，OpenStack 完成兩種 RPC 的呼叫方式。首先簡單介紹三種交換機。

圖 12：RabbitMQ 架構圖

①廣播式交換器型別（Fanout）

該類交換器不分析所接收到訊息中的 Routing Key，預設將訊息轉發到所有與該交換器繫結的佇列中去。

圖 13：廣播式交換機

②直接式交換器型別（Direct）

該類交換器需要精確匹配 Routing Key 與 Binding Key，如訊息的 Routing Key = Cloud，那麼該條訊息只能被轉發至 Binding Key = Cloud 的訊息佇列中去。

圖 14：直接式交換機

③主題式交換器（Topic Exchange）

該類交換器通過訊息的 Routing Key 與 Binding Key 的模式匹配，將訊息轉發至所有符合繫結規則的佇列中。

Binding Key 支援萬用字元，其中“*”匹配一個片語，“#”匹配多個片語（包括零個）。

圖 15：主題式交換機

注：以上四張圖片來自部落格園，如有侵權，請聯絡作者： https://www.cnblogs.com/dwlsxj/p/RabbitMQ.html。

當生產者傳送訊息 Routing Key=F.C.E 的時候，這時候只滿足 Queue1，所以會被路由到 Queue 中。

如果 Routing Key=A.C.E 這時候會被同時路由到 Queue1 和 Queue2 中，如果 Routing Key=A.F.B 時，這裡只會傳送一條訊息到 Queue2 中。

Nova 基於 RabbitMQ 實現兩種 RPC 呼叫：

• RPC.CALL（呼叫）
• RPC.CAST（通知）

其中 RPC.CALL 基於請求與響應方式，RPC.CAST 只是提供單向請求，兩種 RPC 呼叫方式在 Nova 中均有典型的應用場景。

RPC.CALL

RPC.CALL 是一種雙向通訊流程，即 RabbitMQ 接收訊息生產者生成的系統請求訊息，訊息消費者經過處理之後將系統相應結果反饋給呼叫程式。

圖 16：RPC.CALL 原理圖

一個使用者通過 Dashboard 建立一個虛擬機器，介面經過訊息封裝後傳送給 NOVA-API。

NOVA-API 作為訊息生產者，將該訊息以 RPC.CALL 方式通過 Topic 交換器轉發至訊息佇列。

此時，Nova-Compute 作為訊息消費者，接收該資訊並通過底層虛擬化軟體執行相應虛擬機器的啟動程式。

待使用者虛擬機器成功啟動之後，Nova-Compute 作為訊息生產者通過 Direct 交換器和響應的訊息佇列將虛擬機器啟動成功響應訊息反饋給 Nova-API。

此時 Nova-API 作為訊息消費者接收該訊息並通知使用者虛擬機器啟動成功。

RPC.CALL 工作原理如下圖：

圖 17：RPC.CALL 具體實現圖

工作流程：

• 客戶端建立 Message 時指定 reply_to 佇列名、correlation_id 標記呼叫者。
• 通過佇列，服務端收到訊息。呼叫函式處理，然後返回。
• 返回的佇列是 reply_to 指定的佇列，並攜帶 correlation_id。
• 返回訊息到達客戶端，客戶端根據 correlation_id 判斷是哪一個函式的呼叫返回。

如果有多個執行緒同時進行遠端方法呼叫，這時建立在 Client Server 之間的 Socket 連線上會有很多雙方傳送的訊息傳遞，前後順序也可能是隨機的。

Server 處理完結果後，將結果訊息傳送給 Client，Client 收到很多訊息，怎麼知道哪個訊息結果是原先哪個執行緒呼叫的？

Client 執行緒每次通過 Socket 呼叫一次遠端介面前，生成一個唯一的 ID，即 Request ID（Request ID必需保證在一個 Socket 連線裡面是唯一的），一般常常使用 AtomicLong 從 0 開始累計數字生成唯一 ID。

RPC.CAST

RPC.CAST 的遠端呼叫流程與 RPC.CALL 類似，只是缺少了系統訊息響應流程。

一個 Topic 訊息生產者傳送系統請求訊息到 Topic 交換器，Topic 交換器根據訊息的 Routing Key 將訊息轉發至共享訊息佇列。

與共享訊息佇列相連的所有 Topic 消費者接收該系統請求訊息，並把它傳遞給響應的服務端進行處理。

其呼叫流程如圖所示：

圖 18：RPC.CAST 原理圖

連線設計

RabbitMQ 實現的 RPC 對網路的一般設計思路：消費者是長連線，傳送者是短連線。但可以自由控制長連線和短連線。

一般消費者是長連線，隨時準備接收處理訊息；而且涉及到 RabbitMQ Queues、Exchange 的 auto-deleted 等沒特殊需求沒必要做短連線。傳送者可以使用短連線，不會長期佔住埠號，節省埠資源。

Nova 中 RPC 程式碼設計：

簡單對比 RPC 和 Restful API

RESTful API 架構

REST 最大的幾個特點為：資源、統一介面、URI 和無狀態。

①資源

所謂”資源”，就是網路上的一個實體，或者說是網路上的一個具體資訊。它可以是一段文字、一張圖片、一首歌曲、一種服務，就是一個具體的實在。

②統一介面

RESTful 架構風格規定，資料的元操作，即 CRUD(Create，Read，Update 和 Delete，即資料的增刪查改)操作，分別對應於 HTTP 方法：GET 用來獲取資源，POST 用來新建資源（也可以用於更新資源），PUT 用來更新資源，DELETE 用來刪除資源，這樣就統一了資料操作的介面，僅通過 HTTP 方法，就可以完成對資料的所有增刪查改工作。

③URL

可以用一個 URI（統一資源定位符）指向資源，即每個 URI 都對應一個特定的資源。

要獲取這個資源，訪問它的 URI 就可以，因此 URI 就成了每一個資源的地址或識別符。

④無狀態

所謂無狀態的，即所有的資源，都可以通過 URI 定位，而且這個定位與其他資源無關，也不會因為其他資源的變化而改變。有狀態和無狀態的區別，舉個簡單的例子說明一下。

如查詢員工的工資，如果查詢工資是需要登入系統，進入查詢工資的頁面，執行相關操作後，獲取工資的多少，則這種情況是有狀態的。

因為查詢工資的每一步操作都依賴於前一步操作，只要前置操作不成功，後續操作就無法執行。

如果輸入一個 URI即可得到指定員工的工資，則這種情況是無狀態的，因為獲取工資不依賴於其他資源或狀態。

且這種情況下，員工工資是一個資源，由一個 URI與之對應，可以通過 HTTP 中的 GET 方法得到資源，這是典型的 RESTful 風格。

RPC 和 Restful API 對比

面對物件不同：

• RPC 更側重於動作。
• REST 的主體是資源。

RESTful 是面向資源的設計架構，但在系統中有很多物件不能抽象成資源，比如登入，修改密碼等而 RPC 可以通過動作去操作資源。所以在操作的全面性上 RPC 大於 RESTful。

傳輸效率：

• RPC 效率更高。RPC，使用自定義的 TCP 協議，可以讓請求報文體積更小，或者使用 HTTP2 協議，也可以很好的減少報文的體積，提高傳輸效率。

複雜度：

• RPC 實現複雜，流程繁瑣。
• REST 呼叫及測試都很方便。

RPC 實現（參見第一節）需要實現編碼，序列化，網路傳輸等。而 RESTful 不要關注這些，RESTful 實現更簡單。

靈活性：

• HTTP 相對更規範，更標準，更通用，無論哪種語言都支援 HTTP 協議。
• RPC 可以實現跨語言呼叫，但整體靈活性不如 RESTful。

總結

RPC 主要用於公司內部的服務呼叫，效能消耗低，傳輸效率高，實現複雜。

HTTP 主要用於對外的異構環境，瀏覽器介面呼叫，App 介面呼叫，第三方介面呼叫等。

RPC 使用場景（大型的網站，內部子系統較多、介面非常多的情況下適合使用 RPC）：

• 長連結。不必每次通訊都要像 HTTP 一樣去 3 次握手，減少了網路開銷。
• 註冊釋出機制。RPC 框架一般都有註冊中心，有豐富的監控管理；釋出、下線介面、動態擴充套件等，對呼叫方來說是無感知、統一化的操作。
• 安全性，沒有暴露資源操作。
• 微服務支援。就是最近流行的服務化架構、服務化治理，RPC 框架是一個強力的支撐。

參考文章

https://developer.51cto.com/art/201906/597963.htm

http://www.mamicode.com/info-detail-2443824.html

部落格

Java技術倉庫《Java程式設計師複習指南》

https://github.com/h2pl/Java-Tutorial

整合全網優質Java學習內容，幫助你從基礎到進階系統化複習Java

面試指南

全網最熱的Java面試指南，共200多頁，非常實用，不管是用於複習還是準備面試都是不錯的。
在公眾號【Java技術江湖】回覆“PDF”即可免費領取。