面試準備——rpc面試題

https://www.jianshu.com/p/28e48e5f9c73

1 什麼是 RPC ？

• RPC (Remote Procedure Call)即遠程過程調用，是分佈式系統常見的一種通訊方法。它容許程序調用另外一個地址空間（一般是共享網絡的另外一臺機器上）的過程或函數，而不用程序員顯式編碼這個遠程調用的細節。
• 除 RPC 以外，常見的多系統數據交互方案還有分佈式消息隊列、HTTP 請求調用、數據庫和分佈式緩存等。
• 其中 RPC 和 HTTP 調用是沒有通過中間件的，它們是端到端系統的直接數據交互。

簡單的說

• RPC就是從一臺機器（客戶端）上經過參數傳遞的方式調用另外一臺機器（服務器）上的一個函數或方法（能夠統稱爲服務）並獲得返回的結果。
• RPC會隱藏底層的通信細節（不須要直接處理Socket通信或Http通信）。
• 客戶端發起請求，服務器返回響應（相似於Http的工做方式）RPC在使用形式上像調用本地函數（或方法）同樣去調用遠程的函數（或方法）。

2 爲何咱們要用RPC?

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

3 RPC須要解決的三個問題

RPC要達到的目標：遠程調用時，要可以像本地調用同樣方便，讓調用者感知不到遠程調用的邏輯。

• Call ID映射。咱們怎麼告訴遠程機器咱們要調用哪一個函數呢？在本地調用中，函數體是直接經過函數指針來指定的，咱們調用具體函數，編譯器就自動幫咱們調用它相應的函數指針。可是在遠程調用中，是沒法調用函數指針的，由於兩個進程的地址空間是徹底不同。因此，在RPC中，全部的函數都必須有本身的一個ID。這個ID在全部進程中都是惟一肯定的。客戶端在作遠程過程調用時，必須附上這個ID。而後咱們還須要在客戶端和服務端分別維護一個 {函數 <--> Call ID} 的對應表。二者的表不必定須要徹底相同，但相同的函數對應的Call ID必須相同。當客戶端須要進行遠程調用時，它就查一下這個表，找出相應的Call ID，而後把它傳給服務端，服務端也經過查表，來肯定客戶端須要調用的函數，而後執行相應函數的代碼。
• 序列化和反序列化。客戶端怎麼把參數值傳給遠程的函數呢？在本地調用中，咱們只須要把參數壓到棧裏，而後讓函數本身去棧裏讀就行。可是在遠程過程調用時，客戶端跟服務端是不一樣的進程，不能經過內存來傳遞參數。甚至有時候客戶端和服務端使用的都不是同一種語言（好比服務端用C++，客戶端用Java或者Python）。這時候就須要客戶端把參數先轉成一個字節流，傳給服務端後，再把字節流轉成本身能讀取的格式。這個過程叫序列化和反序列化。同理，從服務端返回的值也須要序列化反序列化的過程。
• 網絡傳輸。遠程調用每每是基於網絡的，客戶端和服務端是經過網絡鏈接的。全部的數據都須要經過網絡傳輸，所以就須要有一個網絡傳輸層。網絡傳輸層須要把Call ID和序列化後的參數字節流傳給服務端，而後再把序列化後的調用結果傳回客戶端。只要能完成這二者的，均可以做爲傳輸層使用。所以，它所使用的協議實際上是不限的，能完成傳輸就行。儘管大部分RPC框架都使用TCP協議，但其實UDP也能夠，而gRPC乾脆就用了HTTP2。Java的Netty也屬於這層的東西。

4 實現高可用RPC框架須要考慮到的問題

• 既然系統採用分佈式架構，那一個服務勢必會有多個實例，要解決如何獲取實例的問題。因此須要一個服務註冊中心，好比在Dubbo中，就可使用Zookeeper做爲註冊中心，在調用時，從Zookeeper獲取服務的實例列表，再從中選擇一個進行調用；
• 如何選擇實例呢？就要考慮負載均衡，例如dubbo提供了4種負載均衡策略；
• 若是每次都去註冊中心查詢列表，效率很低，那麼就要加緩存；
• 客戶端總不能每次調用完都等着服務端返回數據，因此就要支持異步調用；
• 服務端的接口修改了，老的接口還有人在用，這就須要版本控制；
• 服務端總不能每次接到請求都立刻啓動一個線程去處理，因而就須要線程池；

5 理論結構模型

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

RPC 服務端接收器RpcAcceptor接收客戶端的調用請求，一樣使用RpcProtocol執行協議解碼（decode）。

解碼後的調用信息傳遞給RpcProcessor去控制處理調用過程，最後再委託調用給RpcInvoker去實際執行並返回調用結果。

主流的RPC框架

服務治理型

• dubbo：是阿里巴巴公司開源的一個Java高性能優秀的服務框架，使得應用可經過高性能的 RPC 實現服務的輸出和輸入功能，能夠和 Spring框架無縫集成。dubbo 已經與12年年末中止維護升級。
• dubbox：是噹噹團隊基於dubbo升級的一個版本。是一個分佈式的服務架構，可直接用於生產環境做爲SOA服務框架。dubbox資源連接
• motan：是新浪微博開源的一個Java框架。它誕生的比較晚，起於2013年，2016年5月開源。Motan 在微博平臺中已經普遍應用，天天爲數百個服務完成近千億次的調用。motan資源連接