Dubbo 系列(四) 什麼是RPC

這段時間一直在接觸dubbo相關的知識,也想整體整理一下dubbo,很懂東西官網上面已經寫的很清楚了,很多技術的東西,還是的自己實踐一下,自己整理一下,纔能有自己的收穫,今天想從頭開始梳理一下什麼dubbo這個曾經被遺棄,現在又被重新迴歸阿帕奇頂級開源項目的框架,很多東西都慘開dubbo官網
地址:http://dubbo.apache.org/zh-cn/index.html

1. 什麼是RPC?

RPC（Remote Procedure Call）:遠程過程調用,他是一種通過網絡,從遠程計算機程序上請求的服務,而不需要了解底層網絡技術的協議,也就是說兩臺服務器,A B,一個應用部署在A服務器上,想要調用B服務器上應用調用的方法,由於不在同一個內存空間,不能直接調用,需要使用網絡來表達調用的語義和傳達調用的數據.

RPC協議假定某些傳輸協議的存在,如TCP或者UDP,爲通訊程序攜帶信息數據,在OSI網絡通訊模型中,RPC跨越了傳輸層和應用層,RPC使得開發包括網絡分佈式多程序在內的應用程序更加容易,現在業界有很多優秀的開源RPC框架,例如SpringCloud 和dubbo Thrift等

2.RPC起源

RPC 這個概念術語在上世紀 80 年代由 Bruce Jay Nelson 提出。這裏我們追溯下當初開發 RPC 的原動機是什麼？在 Nelson 的論文 “Implementing Remote Procedure Calls” 中他提到了幾點：

• 簡單：RPC 概念的語義十分清晰和簡單，這樣建立分佈式計算就更容易。
• 高效：過程調用看起來十分簡單而且高效。
• 通用：在單機計算中過程往往是不同算法部分間最重要的通信機制。

通俗一點說:就是一般程序員對於本地的過程調用很熟悉，那麼我們把 RPC 作成和本地調用完全類似，那麼就更容易被接受，使用起來毫無障礙。Nelson 的論文發表於 30 年前，其觀點今天看來確實高瞻遠矚，今天我們使用的 RPC 框架基本就是按這個目標來實現的。

3.RPC 結構

Nelson 的論文中指出實現 RPC 的程序包括 5 個部分：

1. User
2. User-stub
3. RPCRuntime
4. Server-stub
5. Server
   network
   
   這裏 user 就是 client 端，當 user 想發起一個遠程調用時,它實際是通過本地調用 user-stub。user-stub 負責將調用的接口、方法和參數通過約定的協議規範進行編碼並通過本地的 RPCRuntime 實例傳輸到遠端的實例。遠端 RPCRuntime 實例收到請求後交給 server-stub 進行解碼後發起本地端調用,調用結果再返回給 user 端。

以上是粗粒度的 RPC 實現概念結構，接下來我們進一步細化它應該由哪些組件構成，如下圖所示。

1.RpcServer 負責導出遠程接口
2.RpcClient 負責導入（import）遠程接口的代理實現
3.RpcProxy 遠程接口的代理實現
4.RpcInvoker
客戶端實現: 負責編碼調用信息和發送調用請求到服務方,並且等待調用結束返回,
客戶方實現: 負責調用服務端接口的具體實現並返回調用結果
5.RpcProtocol 負責協議編/解碼
6.RpcConnector 負責維持客戶方和服務方的連接通道和發送數據到服務方
7.RpcAcceptor 負責接收客戶方請求並返回請求結果
8.RpcProcessor 負責在服務方控制調用過程，包括管理調用線程池、超時時間等
9.RpcChannel 數據傳輸通道

RPC 服務方通過 RpcServer 去導出（export）遠程接口方法，而客戶方通過 RpcClient 去引入（import）遠程接口方法。客戶方像調用本地方法一樣去調用遠程接口方法，RPC 框架提供接口的代理實現，實際的調用將委託給代理RpcProxy 。代理封裝調用信息並將調用轉交給RpcInvoker 去實際執行。在客戶端的RpcInvoker 通過連接器RpcConnector 去維持與服務端的通道RpcChannel，並使用RpcProtocol 執行協議編碼（encode）並將編碼後的請求消息通過通道發送給服務方。

RPC 服務端接收器 RpcAcceptor 接收客戶端的調用請求，同樣使用RpcProtocol 執行協議解碼（decode）。解碼後的調用信息傳遞給RpcProcessor 去控制處理調用過程，最後再委託調用給RpcInvoker 去實際執行並返回調用結果。如下是各個部分的詳細職責：

4.RPC工作原理

rpc的設計有client,Client stub，Network ，Server stub，Server構成。其中Client就是用來調用服務的,Cient stub是用來把調用的方法和參數序列化的（因爲要在網絡中傳輸，必須要把對象轉變成字節），Network用來傳輸這些信息到Server stub， Server stub用來把這些信息反序列化的，Server就是服務的提供者，最終調用的就是Server提供的方法。

1.Client像調用本地服務似的調用遠程服務

2.Client stub接收到調用後，將方法、參數序列化

3.戶端通過sockets將消息發送到服務端

4.Server stub 收到消息後進行解碼（將消息對象反序列化）

5.Server stub 根據解碼結果調用本地的服務

6.本地服務執行(對於服務端來說是本地執行)並將結果返回給Server stub

7.Server stub將返回結果打包成消息（將結果消息對象序列化）

8.服務端通過sockets將消息發送到客戶端

9.Client stub接收到結果消息，並進行解碼（將結果消息反序列化）

10.客戶端得到最終結果。

RPC 調用分以下兩種：
1.同步調用:客戶方等待調用執行完成並返回結果。
2.異步調用:客戶方調用後不用等待執行結果返回，但依然可以通過回調通知等方式獲取返回結果。若客戶方不關心調用返回結果，則變成單向異步調用，單向調用不用返回結果。

5.RPC 能幹什麼?

RPC 的主要功能目標是讓構建分佈式計算（應用）更容易，在提供強大的遠程調用能力時不損失本地調用的語義簡潔性,爲實現該目標，RPC 框架需提供一種透明調用機制，讓使用者不必顯式的區分本地調用和遠程調用，在之前給出的一種實現結構，基於 stub 的結構來實現。下面我們將具體細化 stub 結構的實現。

• 可以做到分佈式，現代化的微服務
• 部署靈活
• 解耦服務
• 擴展性強

RPC的目的是讓你在本地調用遠程的方法，而對你來說這個調用是透明的，你並不知道這個調用的方法是部署哪裏。通過RPC能解耦服務，這纔是使用RPC的真正目的。

總結

這篇文章介紹了 RPC 的一些基本原理，相信到這裏您已經對 RPC 有了一定理解。其實發現實現一個 RPC 不算難，難的是實現一個高性能高可靠的RPC框架。比如，既然是分佈式了，那麼一個服務可能有多個實例，你在調用時，要如何獲取這些實例的地址呢？這時候就需要一個服務註冊中心，比如在Dubbo中，就可以使用Zookeeper作爲註冊中心，在調用時，從Zookeeper獲取服務的實例列表，再從中選擇一個進行調用。那麼選哪個調用好呢？這時候就需要負載均衡了，於是你又得考慮如何實現複雜均衡，比如Dubbo就提供了好幾種負載均衡策略。

參考官網:https://dubbo.apache.org/en-us/