揭秘RPC框架-核心組件

一個基本的RCP框架至少包括四個方面的內容：通信模型、序列化機制、遠程服務本地代理以及服務發布者。在前面文章揭秘RPC框架--實現原理，我們通過一個簡單實現舉例分析了實現RPC的關鍵步驟。本文將繼續講解RPC中相關要點。

一、通信模型

1.1長連接or短連接

假設通信的為A機器與B機器，A與B之間有通信模型，在Java中一般基於BIO或NIO。大部分的RPC框架都使用長連接進行內部通信，如下特點

（1）節省資源

長連接只在首次創建時或者鏈路斷連重連才創建鏈路，鏈路創建成功，服務提供者與消費者通過心跳和業務消息維繫鏈路，多消息復用同一鏈路。

（2）降低時延

遠程服務調用，網路時延是關鍵指標之一，相對於一次簡單的服務調用，鏈路的重建通常消耗耗時更多。

1.2 BIO or NIO

在JDK1.4推出JAVA NIO（非阻塞IO）之前，基於java的所有socket通信都採用了同步阻塞模式（BIO）請求-應答模式, 性能和可靠性受限，NIO SocketChannel 對應BIO Socket類，NIO ServerSocketChannel對應BIO ServerSocket類，IO多路復用技術 –將多個IO阻塞復用到同一個select阻塞上，一個多路復用器Selector可以同時輪詢多個Channel，JDK1.5_update10版本使用epoll替代了傳統的select/poll, 因此沒有最大連接句柄1024/2048的限制，通信框架選擇更高效的NIO

1.3自研還是選擇開源NIO

NIO類庫和API繁雜； 需要非常熟悉多線程和網路編程模型；可靠性能力需要開發人員自行維護，比如如何處理斷連重連、網路擁塞等；JDK NIO BUG，如epoll bug，導致Selector空輪詢-->100%CPU ,雖然JDK1.6,1.7聲稱修復了，但是還是沒有完全杜絕，集成開源的NIO框架代替自研方案，即Netty框架 – 功能強大，定製能力強，性能高，成熟穩定，社區活躍，各行業成功商用。

1.4鏈路有效性探測

確定當前鏈路可用，對方活著並且能夠正常接收和發送消息，解決鏈路的可靠性問題，心跳檢測機制包含三方面：

（1）TCP層面的心跳檢測

TCP的Keep-Alive機制，作用域是整個TCP協議棧

（2）協議層面的心跳檢測

主要存在於長連接協議中，如SMPP協議

（3）應用層面的心跳檢測

主要由各業務產品通過約定方式定時給對方發送心跳消息實現

tcp+hessian序列化是公司pigeon默認的通信方式，如果有業務場景需要實現其他非java語言作為客戶端來調用pigeon服務，需要了解pigeon發送消息和接收消息的協議格式，使用場景：a）一般的服務調用需要發出請求和接收響應b）為了維持正常的tcp連接，還需要定期發送心跳消息和接收心跳響應消息，建議3秒發送一次，並接收響應，如果心跳未正常返回，需要客戶端本地摘除這個服務端節點，在後續路由選擇時不再選擇不正常的節點。

Pigeon的心跳機制（屬於Ping-Pong型心跳）主要由客戶端周期性的發起心跳檢測，服務端接受心跳檢測並響應的形式。根據服務端的響應情況，判斷鏈路的健康狀態。心跳線程，目的是保持客戶端與可用的服務端之間的連接，客戶端發起，服務端響應，1.5s超時，每3s發送一次，連續5次不成功則考慮摘除該服務端，是否摘除是判斷服務端有20%以上的節點可用就可以摘除該不用的節點，摘除後會放入重連線程

二、序列化

2.1選型

遠程通信，需要將對象轉換成二進位碼流進行網路傳輸，不同的序列化框架，支持的數據類型，數據包大小，異常類型及性能都不同，不同的序列化技術方案，如xml, json, java,protobuf, hessian等。序列化目的：內存對象可以傳輸到其他地方（文件或者網路）。序列化需考慮的方面：

a: 性能（序列化和反序列化的速度）

b: 可讀性

c: 序列化後的對象大小

d: 兼容性（調用方和被調用方對象版本不一致時的反應）java/hessian只針對欄位序列化，不針對方法序列化

e: 是否支持複雜對象

f: 編寫方便

三、遠程服務本地代理

主要關注如何將本地調用封裝為遠程過程調用，一般是基於JDK的動態代理模式

四、服務發布者

主要是對遠程服務進行發布、服務定位與調用

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！