RPC原理及實現 RPC原理及實現

轉『RPC原理及實現』

1 簡介

RPC 的主要功能目標是讓構建分佈式計算（應用）更容易，在提供強大的遠程調用能力時不損失本地調用的語義簡潔性。爲實現該目標，RPC 框架需提供一種透明調用機制讓使用者沒必要顯式的區分本地調用和遠程調用。

2 調用分類

RPC 調用分如下兩種：

• 同步調用

  客戶方等待調用執行完成並返回結果。

• 異步調用

  客戶方調用後不用等待執行結果返回，但依然能夠經過回調通知等方式獲取返回結果。 若客戶方不關心調用返回結果，則變成單向異步調用，單向調用不用返回結果。

異步和同步的區分在因而否等待服務端執行完成並返回結果。

3 結構拆解

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

RPC 服務端接收器 RpcAcceptor 接收客戶端的調用請求，一樣使用 RpcProtocol 執行協議解碼（decode）。 解碼後的調用信息傳遞給 RpcProcessor 去控制處理調用過程，最後再委託調用給 RpcInvoker 去實際執行並返回調用結果。

4 組件職責

上面咱們進一步拆解了 RPC 實現結構的各個組件組成部分，下面咱們詳細說明下每一個組件的職責劃分。

1. RpcServer

   負責導出（export）遠程接口

2. RpcClient

   負責導入（import）遠程接口的代理實現

3. RpcProxy

   遠程接口的代理實現

4. RpcInvoker

   客戶方實現：負責編碼調用信息和發送調用請求到服務方並等待調用結果返回

   服務方實現：負責調用服務端接口的具體實現並返回調用結果

5. RpcProtocol

   負責協議編/解碼

6. RpcConnector

   負責維持客戶方和服務方的鏈接通道和發送數據到服務方

7. RpcAcceptor

   負責接收客戶方請求並返回請求結果

8. RpcProcessor

   負責在服務方控制調用過程，包括管理調用線程池、超時時間等

9. RpcChannel

   數據傳輸通道

5 實現分析

在進一步拆解了組件並劃分了職責以後，這裏以在 java 平臺實現該 RPC 框架概念模型爲例，詳細分析下實現中須要考慮的因素。

5.1 導出遠程接口

導出遠程接口的意思是指只有導出的接口能夠供遠程調用，而未導出的接口則不能。 在 java 中導出接口的代碼片斷可能以下：

DemoService demo   = new ...; RpcServer server = new ...; server.export(DemoService.class, demo, options); 

咱們能夠導出整個接口，也能夠更細粒度一點只導出接口中的某些方法，如：

// 只導出 DemoService 中籤名爲 hi(String s) 的方法 server.export(DemoService.class, demo, "hi", new Class<?>[] { String.class }, options); 

java 中還有一種比較特殊的調用就是多態，也就是一個接口可能有多個實現，那麼遠程調用時到底調用哪一個？ 這個本地調用的語義是經過 jvm 提供的引用多態性隱式實現的，那麼對於 RPC 來講跨進程的調用就無法隱式實現了。 若是前面 DemoService 接口有 2 個實現，那麼在導出接口時就須要特殊標記不一樣的實現，如：

DemoService demo   = new ...; DemoService demo2 = new ...; RpcServer server = new ...; server.export(DemoService.class, demo, options); server.export("demo2", DemoService.class, demo2, options); 

上面 demo2 是另外一個實現，咱們標記爲 demo2 來導出， 那麼遠程調用時也須要傳遞該標記才能調用到正確的實現類，這樣就解決了多態調用的語義。

5.2 導入遠程接口與客戶端代理

導入相對於導出遠程接口，客戶端代碼爲了可以發起調用必需要得到遠程接口的方法或過程定義。目前，大部分跨語言平臺 RPC 框架採用根據 IDL 定義經過 code generator 去生成 stub 代碼，這種方式下實際導入的過程就是經過代碼生成器在編譯期完成的。 我所使用過的一些跨語言平臺 RPC 框架如 CORBAR、WebService、ICE、Thrift 均是此類方式。

代碼生成的方式對跨語言平臺 RPC 框架而言是必然的選擇，而對於同一語言平臺的 RPC 則能夠經過共享接口定義來實現。 在 java 中導入接口的代碼片斷可能以下：

RpcClient client = new ...; DemoService demo = client.refer(DemoService.class); demo.hi("how are you?"); 

在 java 中 import 是關鍵字，因此代碼片斷中咱們用 refer 來表達導入接口的意思。 這裏的導入方式本質也是一種代碼生成技術，只不過是在運行時生成，比靜態編譯期的代碼生成看起來更簡潔些。 java 裏至少提供了兩種技術來提供動態代碼生成，一種是 jdk 動態代理，另一種是字節碼生成。 動態代理相比字節碼生成使用起來更方便，但動態代理方式在性能上是要遜色於直接的字節碼生成的，而字節碼生成在代碼可讀性上要差不少。 二者權衡起來，我的認爲犧牲一些性能來得到代碼可讀性和可維護性顯得更重要。

5.3 協議編解碼

客戶端代理在發起調用前須要對調用信息進行編碼，這就要考慮須要編碼些什麼信息並以什麼格式傳輸到服務端才能讓服務端完成調用。 出於效率考慮，編碼的信息越少越好（傳輸數據少），編碼的規則越簡單越好（執行效率高）。 咱們先看下須要編碼些什麼信息：

1. 調用編碼

   接口方法：包括接口名、方法名

   方法參數：包括參數類型、參數值

   調用屬性：包括調用屬性信息，例如調用附件隱式參數、調用超時時間等

2. 返回編碼

   返回結果：接口方法中定義的返回值

   返回碼：異常返回碼

   返回異常信息：調用異常信息

除了以上這些必須的調用信息，咱們可能還須要一些元信息以方便程序編解碼以及將來可能的擴展。 這樣咱們的編碼消息裏面就分紅了兩部分，一部分是元信息、另外一部分是調用的必要信息。 若是設計一種 RPC 協議消息的話，元信息咱們把它放在協議消息頭中，而必要信息放在協議消息體中。 下面給出一種概念上的 RPC 協議消息設計格式：

1. 消息頭

   magic : 協議魔數，爲解碼設計

   header size: 協議頭長度，爲擴展設計

   version : 協議版本，爲兼容設計

   st : 消息體序列化類型

   hb : 心跳消息標記，爲長鏈接傳輸層心跳設計

   ow : 單向消息標記，

   rp : 響應消息標記，不置位默認是請求消息

   status code: 響應消息狀態碼

   reserved : 爲字節對齊保留

   message id : 消息 id

   body size : 消息體長度

2. 消息體

   採用序列化編碼，常見有如下格式

   xml : 如 webservie SOAP

   json : 如 JSON-RPC

   binary: 如 thrift; hession; kryo 等

   格式肯定後編解碼就簡單了，因爲頭長度必定因此咱們比較關心的就是消息體的序列化方式。 序列化咱們關心三個方面：

   序列化和反序列化的效率，越快越好。

   序列化後的字節長度，越小越好。

   序列化和反序列化的兼容性，接口參數對象若增長了字段，是否兼容。

5.4 傳輸服務

協議編碼以後，天然就是須要將編碼後的 RPC 請求消息傳輸到服務方，服務方執行後返回結果消息或確認消息給客戶方。 RPC 的應用場景實質是一種可靠的請求應答消息流，和 HTTP 相似。 所以選擇長鏈接方式的 TCP 協議會更高效，與 HTTP 不一樣的是在協議層面咱們定義了每一個消息的惟一 id，所以能夠更容易的複用鏈接。

既然使用長鏈接，那麼第一個問題是到底 client 和 server 之間須要多少根鏈接？ 實際上單鏈接和多鏈接在使用上沒有區別，對於數據傳輸量較小的應用類型，單鏈接基本足夠。 單鏈接和多鏈接最大的區別在於，每根鏈接都有本身私有的發送和接收緩衝區， 所以大數據量傳輸時分散在不一樣的鏈接緩衝區會獲得更好的吞吐效率。 因此，若是你的數據傳輸量不足以讓單鏈接的緩衝區一直處於飽和狀態的話，那麼使用多鏈接並不會產生任何明顯的提高，反而會增長鏈接管理的開銷。

鏈接是由 client 端發起創建並維持。 若是 client 和 server 之間是直連的，那麼鏈接通常不會中斷（固然物理鏈路故障除外）。 若是 client 和 server 鏈接通過一些負載中轉設備，有可能鏈接一段時間不活躍時會被這些中間設備中斷。 爲了保持鏈接有必要定時爲每一個鏈接發送心跳數據以維持鏈接不中斷。 心跳消息是 RPC 框架庫使用的內部消息，在前文協議頭結構中也有一個專門的心跳位， 就是用來標記心跳消息的，它對業務應用透明。

5.5 執行調用

client stub 所作的事情僅僅是編碼消息並傳輸給服務方，而真正調用過程發生在服務方。 server stub 從前文的結構拆解中咱們細分了 RpcProcessor 和 RpcInvoker 兩個組件， 一個負責控制調用過程，一個負責真正調用。這裏咱們仍是以 java 中實現這兩個組件爲例來分析下它們到底須要作什麼？

java 中實現代碼的動態接口調用目前通常經過反射調用。 除了原生的 jdk 自帶的反射，一些第三方庫也提供了性能更優的反射調用， 所以 RpcInvoker 就是封裝了反射調用的實現細節。

調用過程的控制須要考慮哪些因素，RpcProcessor 須要提供什麼樣地調用控制服務呢？ 下面提出幾點以啓發思考：

1. 效率提高

   每一個請求應該儘快被執行，所以咱們不能每請求來再建立線程去執行，須要提供線程池服務。

2. 資源隔離

   當咱們導出多個遠程接口時，如何避免單一接口調用佔據全部線程資源，而引起其餘接口執行阻塞。

3. 超時控制

   當某個接口執行緩慢，而 client 端已經超時放棄等待後，server 端的線程繼續執行此時顯得毫無心義。

5.6 異常處理

不管 RPC 怎樣努力把遠程調用假裝的像本地調用，但它們依然有很大的不一樣點，並且有一些異常狀況是在本地調用時絕對不會碰到的。在說異常處理以前，咱們先比較下本地調用和 RPC調用的一些差別：

1. 本地調用必定會執行，而遠程調用則不必定，調用消息可能由於網絡緣由並未發送到服務方。

2. 本地調用只會拋出接口聲明的異常，而遠程調用還會拋出 RPC 框架運行時的其餘異常。

3. 本地調用和遠程調用的性能可能差距很大，這取決於 RPC 固有消耗所佔的比重。

正是這些區別決定了使用 RPC 時須要更多考量。 當調用遠程接口拋出異常時，異常多是一個業務異常， 也多是 RPC 框架拋出的運行時異常（如：網絡中斷等）。 業務異常代表服務方已經執行了調用，可能由於某些緣由致使未能正常執行， 而 RPC 運行時異常則有可能服務方根本沒有執行，對調用方而言的異常處理策略天然須要區分。

因爲 RPC 固有的消耗相對本地調用高出幾個數量級，本地調用的固有消耗是納秒級，而 RPC 的固有消耗是在毫秒級。 那麼對於過於輕量的計算任務就並不合適導出遠程接口由獨立的進程提供服務， 只有花在計算任務上時間遠遠高於 RPC 的固有消耗才值得導出爲遠程接口提供服務。

6 如何調用他人的遠程服務

因爲各服務部署在不一樣機器，服務間的調用免不了網絡通訊過程，服務消費方每調用一個服務都要寫一坨網絡通訊相關的代碼，不只複雜並且極易出錯。

若是有一種方式能讓咱們像調用本地服務同樣調用遠程服務，而讓調用者對網絡通訊這些細節透明，那麼將大大提升生產力，好比服務消費方在執行helloWorldService.sayHello(「test」)時，實質上調用的是遠端的服務。這種方式其實就是RPC（Remote Procedure Call Protocol），在各大互聯網公司中被普遍使用，如阿里巴巴的hsf、dubbo（開源）、Facebook的thrift（開源）、Google grpc（開源）、Twitter的finagle等。

要讓網絡通訊細節對使用者透明，咱們天然須要對通訊細節進行封裝，咱們先看下一個RPC調用的流程：

1）服務消費方（client）調用以本地調用方式調用服務；

2）client stub接收到調用後負責將方法、參數等組裝成可以進行網絡傳輸的消息體；

3）client stub找到服務地址，並將消息發送到服務端；

4）server stub收到消息後進行解碼；

5）server stub根據解碼結果調用本地的服務；

6）本地服務執行並將結果返回給server stub；

7）server stub將返回結果打包成消息併發送至消費方；

8）client stub接收到消息，並進行解碼；

9）服務消費方獲得最終結果。

RPC的目標就是要2~8這些步驟都封裝起來，讓用戶對這些細節透明。

6.1 怎麼作到透明化遠程服務調用

怎麼封裝通訊細節才能讓用戶像以本地調用方式調用遠程服務呢？對java來講就是使用代理！java代理有兩種方式：1） jdk 動態代理；2）字節碼生成。儘管字節碼生成方式實現的代理更爲強大和高效，但代碼不易維護，大部分公司實現RPC框架時仍是選擇動態代理方式。

下面簡單介紹下動態代理怎麼實現咱們的需求。咱們須要實現RPCProxyClient代理類，代理類的invoke方法中封裝了與遠端服務通訊的細節，消費方首先從RPCProxyClient得到服務提供方的接口，當執行helloWorldService.sayHello(「test」)方法時就會調用invoke方法。

public class RPCProxyClient implements java.lang.reflect.InvocationHandler{ private Object obj; public RPCProxyClient(Object obj){ this.obj=obj; } /**  * 獲得被代理對象;  */ public static Object getProxy(Object obj){ return java.lang.reflect.Proxy.newProxyInstance(obj.getClass().getClassLoader(), obj.getClass().getInterfaces(), new RPCProxyClient(obj)); } /**  * 調用此方法執行  */ public Object invoke(Object proxy, Method method, Object[] args) throws Throwable { //結果參數; Object result = new Object(); // ...執行通訊相關邏輯 // ... return result; } } public class Test { public static void main(String[] args) { HelloWorldService helloWorldService = (HelloWorldService)RPCProxyClient.getProxy(HelloWorldService.class); helloWorldService.sayHello("test"); } } 

6.2 怎麼對消息進行編碼和解碼

1. 肯定消息數據結構

   上節講了invoke裏須要封裝通訊細節，而通訊的第一步就是要肯定客戶端和服務端相互通訊的消息結構。客戶端的請求消息結構通常須要包括如下內容：

   1）接口名稱

   在咱們的例子裏接口名是「HelloWorldService」，若是不傳，服務端就不知道調用哪一個接口了；

   2）方法名

   一個接口內可能有不少方法，若是不傳方法名服務端也就不知道調用哪一個方法；

   3）參數類型&參數值

   參數類型有不少，好比有bool、int、long、double、string、map、list，甚至如struct（class）；以及相應的參數值；

   4）超時時間

   5）requestID

   標識惟一請求id，在下面一節會詳細描述requestID的用處。

   同理，服務端返回的消息結構通常包括如下內容。

   1）返回值

   2）狀態code

   3）requestID

2. 序列化

   一旦肯定了消息的數據結構後，下一步就是要考慮序列化與反序列化了。

   什麼是序列化？序列化就是將數據結構或對象轉換成二進制串的過程，也就是編碼的過程。

   什麼是反序列化？將在序列化過程當中所生成的二進制串轉換成數據結構或者對象的過程。

   爲何須要序列化？轉換爲二進制串後纔好進行網絡傳輸嘛！爲何須要反序列化？將二進制轉換爲對象纔好進行後續處理！

   現現在序列化的方案愈來愈多，每種序列化方案都有優勢和缺點，它們在設計之初有本身獨特的應用場景，那到底選擇哪一種呢？從RPC的角度上看，主要看三點：1）通用性，好比是否能支持Map等複雜的數據結構；2）性能，包括時間複雜度和空間複雜度，因爲RPC框架將會被公司幾乎全部服務使用，若是序列化上能節約一點時間，對整個公司的收益都將很是可觀，同理若是序列化上能節約一點內存，網絡帶寬也能省下很多；3）可擴展性，對互聯網公司而言，業務變化快，若是序列化協議具備良好的可擴展性，支持自動增長新的業務字段，刪除老的字段，而不影響老的服務，這將大大提供系統的健壯性。

   目前國內各大互聯網公司普遍使用hessian、protobuf、thrift、avro等成熟的序列化解決方案來搭建RPC框架，這些都是久經考驗的解決方案。

6.3 通訊

消息數據結構被序列化爲二進制串後，下一步就要進行網絡通訊了。目前有兩種IO通訊模型：1）BIO；2）NIO。通常RPC框架須要支持這兩種IO模型。

如何實現RPC的IO通訊框架？1）使用java nio方式自研，這種方式較爲複雜，並且頗有可能出現隱藏bug，見過一些互聯網公司使用這種方式；2）基於mina，mina在早幾年比較火熱，不過這些年版本更新緩慢；3）基於netty，如今不少RPC框架都直接基於netty這一IO通訊框架，好比阿里巴巴的HSF、dubbo，Twitter的finagle等。

6.4 消息裏爲何要帶有requestID

若是使用netty的話，通常會用channel.writeAndFlush()方法來發送消息二進制串，這個方法調用後對於整個遠程調用(從發出請求到接收到結果)來講是一個異步的，即對於當前線程來講，將請求發送出來後，線程就能夠日後執行了，至於服務端的結果，是服務端處理完成後，再以消息的形式發送給客戶端的。因而這裏出現如下兩個問題：

1）怎麼讓當前線程「暫停」，等結果回來後，再向後執行？

2）若是有多個線程同時進行遠程方法調用，這時創建在client server之間的socket鏈接上會有不少雙方發送的消息傳遞，先後順序也多是隨機的，server處理完結果後，將結果消息發送給client，client收到不少消息，怎麼知道哪一個消息結果是原先哪一個線程調用的？

以下圖所示，線程A和線程B同時向client socket發送請求requestA和requestB，socket前後將requestB和requestA發送至server，而server可能將responseA先返回，儘管requestA請求到達時間更晚。咱們須要一種機制保證responseA丟給ThreadA，responseB丟給ThreadB。

怎麼解決呢？

1）client線程每次經過socket調用一次遠程接口前，生成一個惟一的ID，即requestID（requestID必需保證在一個Socket鏈接裏面是惟一的），通常經常使用AtomicLong從0開始累計數字生成惟一ID；

2）將處理結果的回調對象callback，存放到全局ConcurrentHashMap裏面put(requestID, callback)；

3）當線程調用channel.writeAndFlush()發送消息後，緊接着執行callback的get()方法試圖獲取遠程返回的結果。在get()內部，則使用synchronized獲取回調對象callback的鎖，再先檢測是否已經獲取到結果，若是沒有，而後調用callback的wait()方法，釋放callback上的鎖，讓當前線程處於等待狀態。

4）服務端接收到請求並處理後，將response結果（此結果中包含了前面的requestID）發送給客戶端，客戶端socket鏈接上專門監聽消息的線程收到消息，分析結果，取到requestID，再從前面的ConcurrentHashMap裏面get(requestID)，從而找到callback對象，再用synchronized獲取callback上的鎖，將方法調用結果設置到callback對象裏，再調用callback.notifyAll()喚醒前面處於等待狀態的線程。

public Object get() { synchronized (this) { // 旋鎖 while (!isDone) { // 是否有結果了 wait(); //沒結果是釋放鎖，讓當前線程處於等待狀態 } } } private void setDone(Response res) { this.res = res; isDone = true; synchronized (this) { //獲取鎖，由於前面wait()已經釋放了callback的鎖了 notifyAll(); // 喚醒處於等待的線程 } } 

7 如何發佈本身的服務

如何讓別人使用咱們的服務呢？有同窗說很簡單嘛，告訴使用者服務的IP以及端口就能夠了啊。確實是這樣，這裏問題的關鍵在因而自動告知仍是人肉告知。

人肉告知的方式：若是你發現你的服務一臺機器不夠，要再添加一臺，這個時候就要告訴調用者我如今有兩個ip了，大家要輪詢調用來實現負載均衡；調用者咬咬牙改了，結果某天一臺機器掛了，調用者發現服務有一半不可用，他又只能手動修改代碼來刪除掛掉那臺機器的ip。現實生產環境固然不會使用人肉方式。

有沒有一種方法能實現自動告知，即機器的增添、剔除對調用方透明，調用者再也不須要寫死服務提供方地址？固然能夠，現現在zookeeper被普遍用於實現服務自動註冊與發現功能！

簡單來說，zookeeper能夠充當一個服務註冊表（Service Registry），讓多個服務提供者造成一個集羣，讓服務消費者經過服務註冊表獲取具體的服務訪問地址（ip+端口）去訪問具體的服務提供者。以下圖所示：

具體來講，zookeeper就是個分佈式文件系統，每當一個服務提供者部署後都要將本身的服務註冊到zookeeper的某一路徑上: /{service}/{version}/{ip:port}, 好比咱們的HelloWorldService部署到兩臺機器，那麼zookeeper上就會建立兩條目錄：分別爲/HelloWorldService/1.0.0/100.19.20.01:16888 /HelloWorldService/1.0.0/100.19.20.02:16888。

zookeeper提供了「心跳檢測」功能，它會定時向各個服務提供者發送一個請求（實際上創建的是一個 socket 長鏈接），若是長期沒有響應，服務中心就認爲該服務提供者已經「掛了」，並將其剔除，好比100.19.20.02這臺機器若是宕機了，那麼zookeeper上的路徑就會只剩/HelloWorldService/1.0.0/100.19.20.01:16888。

服務消費者會去監聽相應路徑（/HelloWorldService/1.0.0），一旦路徑上的數據有任務變化（增長或減小），zookeeper都會通知服務消費方服務提供者地址列表已經發生改變，從而進行更新。

更爲重要的是zookeeper 與生俱來的容錯容災能力（好比leader選舉），能夠確保服務註冊表的高可用性。