一文帶你搞懂RPC核心原理

1、RPC的做用

1. 屏蔽遠程調用跟本地調用的區別，讓咱們感受就是調用項目內的方法。
2. 隱藏底層網絡通訊的複雜性，讓咱們更專一於業務邏輯。

2、完整的RPC涉及到的核心點

編解碼、序列化和反序列、請求協議、樁生成(動態代理、反射執行)。

3、RPC使用過程須要注意什麼問題

1. 避免多米諾骨牌效應，因此要根據服務能力提早協商限流
2. 調用服務異常時，要考慮降級、重試等措施。
3. 核心的服務不能強依賴非核心的服務，避免核心服務由於非核心服務異常而不可用。

4、RPC協議

在傳輸過程當中，RPC並不會把請求參數的全部二進制數據總體一會兒發送到對端機器上，中間可能會拆分紅多個數據包，也有可能合併成其餘請求的數據包。RPC協議就是爲了"正確進行裝包和拆包"而生的，好比使用長度限制或者標識設定邊界。

其中，協議包括固定部分、協議頭內容和協議體內容，固定部分常包括協議長度、協議標識、序列化方式、業務消息ID、消息類型，協議頭內容用來進行擴展的，保證協議可平滑升級，協議體一般包括請求接口方法、請求的業務參數值和業務擴展屬性。其中，協議頭內容單獨定義出來，是爲了不將其信息放到協議體中，致使協議體負載過重。

5、序列化和反序列化須要注意什麼

編解碼組件應該考慮安全性、版本升級的兼容性、跨語言支持性、存儲空間佔用、網絡傳輸效率、可讀性。

複雜的接口定義可能會致使序列化異常，爲了減小發生的機率，應該儘可能使用原生類型，還有不要使用過深的繼承關係或者依賴關係，最後是避免序列化對象過大。

6、動態代理

RPC自動給接口生成一個代理類，咱們在項目中注入接口後，運行時實際綁定的是這個代理類。

JDK默認的代理功能是有必定的侷限性的，它要求被代理的類只能是接口。由於生成的代理類會繼承Proxy類，但Java是不支持多重繼承的。

7、如何設計靈活的RPC框架

將變化部分封裝在插件裏面，才能達到快速靈活擴展的目的，本質就是微內核架構，好比規則引擎架構。

微內核的核心技術點有插件管理、插件鏈接、插件通訊。插件管理也稱爲插件註冊表，用來述插件模塊信息、如何加載、加載時機等等；插件鏈接是指插件按照核心系統的規範實現後如何鏈接到系統上，好比使用依賴注入；插件通訊則是用來協調沒有關聯關係的插件，好比請求上下文Pipline。

8、服務註冊選型

1. DNS輪詢。解析緩存可能致使沒法及時響應服務提供者的變動。
2. DNS負載均衡。須要搭建四層負載均衡器，也就意味着它存在單點壓力隱患。另外，支持負載均衡算法不夠靈活，後端的實例節點還須要手動維護。
3. Zookeeper節點服務。大量的服務提供者頻繁變動會致使Zookeeper服務負載太高甚至宕機。
4. 基於消息總線的最終一致性的註冊中心。某個註冊中心節點推送消息到消息總線，消息總線生成新版本號的數據，再通知其餘註冊中心和服務提供者更新本地緩存。

9、如何識別服務節點存活狀況

服務方的狀態一般有三種，分別爲健康狀態、亞健康狀態、死亡狀態，其中，亞健康狀態下鏈接是成功的可是心跳請求連續失敗。不過，心跳探測一般還會結合業務可用率來判斷狀態，這樣能夠及時發現心跳探測間歇性失敗的問題。

具體的健康檢查分類有靜態方法和動態方法。

靜態方法：基於服務消費者自己調用來判斷服務節點是否可用，更加實時更加準確，並且當註冊中心或者網絡出現問題時，基本不受影響。這種方式使用更加廣泛。

動態方法：服務提供者向註冊中心上報心跳信息，而後更新註冊列表並同步到服務消費者，同時結合心跳開關保護和服務節點摘取保護機制(好比控制比例)進行存活判斷優化。

10、路由策略

路由策略就是服務提供者集羣列表篩選規則，好比根據來源IP或者請求參數控制請求，經常使用於灰度發佈的風險控制，還可用於同機房調用優先調度、讀寫分離、黑白名單控制。

11、異常重試

當業務具備冪等性保證時才能讓RPC框架幫助咱們進行重試，一般藉助路由策略實現，當鏈接異常或者業務白名單異常時就進行重試，從新選擇一個新的服務節點進行調用，直到重試最大次數門檻，或者已經達到超時時間設定。

12、優雅關閉

服務對象在關閉過程當中，會拒絕新的請求，同時根據引用計數器等待正在處理的請求所有結束以後纔會真正關閉。另外，爲了不一直等待形成應用沒法正常退出，還須要在整個ShutdownHook裏面加上超時控制。

十3、優雅啓動

優雅啓動是指不要讓應用剛啓動成功就接收正常量級的請求，此時數據可能還未徹底準備好，容易形成請求超時。

常見的作法有啓動預熱和延遲暴露。啓動預熱的意思就是藉助路由策略根據實例註冊時間動態調整權重，剛啓動的應用緩慢放大流量接收的佔比。而延遲暴露則是應用啓動完成後，先經過Hook鉤子機制執行預熱邏輯後再執行註冊上報。

十4、服務依賴檢查

啓動時對引用的服務提供者進行存活檢查，若是不存活快速失敗，避免上線後才暴露問題。

十5、邏輯分組

穩定性保障中很重要的一點就是自適應保護，好比經過隔離失敗保證提供給核心服務的接口可用，更具體的落地方案有路由分組，不一樣級別的系統調用不一樣的分組，從而達到隔離的目的。不過對於服務使用者來講，可調用的列表減小了，這種狀況下RPC框架最好提供主、備分組的邏輯，當主分組所有不可用後，再使用備分組。

十6、動態分組

使用邏輯分組進行流量隔離時，若是某些分組的服務使用方流量突增，提供方緊急擴容不現實，一來及時性差二來麻煩。針對這種狀況，咱們能夠經過註冊中心的控制檯動態修改已有分組配置，進行替換或者追加，曲線求國地增長了服務使用方的可以使用實例列表。

十7、異步調用

客戶端調用服務端後直接返回的再也不是結果，而是CompletableFuture對象。當客戶端收到服務端發送過來的響應以後，RPC框架自動地調用先前的CompletableFuture對象的complete方法，也就是將返回值注入到異步模型中，從而完成異步通知。

十8、RPC安全體系

RPC通訊通常爲內網服務間通訊，因此它的安全問題能夠簡化爲認證受權問題、僞造註冊問題。針對前者，咱們能夠經過受權平臺管理調用方列表，調用方申請調用權限經過後生成與其標識相對應的令牌。而後每次調用都經過上下文隱式傳遞這些認證參數，提供方接着進行Hash校驗，經過才放行。而針對僞造註冊隱患的解決方案是不容許多個應用同時註冊相同的服務。

十9、快速定位問題

RPC 框架自身以及服務提供方的業務邏輯實現，都應該對異常進行合理地封裝，包裝排查問題所須要的重要信息，好比接口簽名信息、客戶端和服務端的IP、異常信息。同時還要對各類異常作好分類標識，好比業務線程池耗盡，Netty鏈接異常，Netty數據傳輸異常，限流異常等等。若是想更加高效排查鏈路問題，就得處理好埋點和傳遞。

二10、定時處理

咱們能夠利用時間輪機制優雅完成異步請求超時、啓動超時、心跳探測等等功能。時間輪相似生活中的時鐘，它只會輪循第一層時間槽的任務，當遍歷完成後纔將更高層的任務從新分佈到第一層，而後從新遍歷。這樣遍歷時就不會額外遍歷其餘暫時不會執行到的槽，避免浪費CPU能力。

二11、流量回放

開源界支持流量回放的軟件有不少，好比TcpCopy，可是都須要運維手工操做。有了RPC框架後，操做姿式就不同了，RPC框架能夠收集請求數據，而後假裝成一個服務調用者，請求改造後須要迴歸驗證或者促銷時須要壓促的服務提供者。

二12、泛化調用

在不一樣開發語言場景中或者網關場景中，調用者沒法解析服務提供者的接口私服JAR包信息，那此時調用就須要RPC框架進行兼容。調用者只須要指定接口、方法、參數類型、參數值，就能夠完成一次調用，這種調用方式稱爲Generic泛化調用。

BLOG地址：www.liangsonghua.com

關注微信公衆號：松花皮蛋的黑板報，獲取更多精彩！

公衆號介紹：分享在京東工做的技術感悟，還有JAVA技術和業內最佳實踐，大部分都是務實的、能看懂的、可復現的