思考一個問題:為什么需要 RPC 服務?
在傳統的開發模式中,我們通常將系統的各個服務部署在單臺機器,隨著服務的擴展,這種方式已經完全無法滿足系統大規模的擴展需要,分布式系統由此誕生,在分布式系統中,最重要就是各個服務之間的 RPC 調用。
RPC 全稱 Remote Procedure Call——遠程過程調用,它是一種通過網絡從遠程計算機程序上請求服務,而不需要了解底層網絡技術的方式。簡單一點就是:通過一定協議和方法使得調用遠程計算機上的服務,就像調用本地服務一樣。
通常來說,RPC 的實現方式有很多,可以基于常見的 HTTP 協議,也可以在TCP上層封裝自定義協議,常見的 Web Service 就是基于 HTTP 協議的 RPC,HTTP 協議的優點是具有良好的跨平臺性,特別適合異構系統較多的公司,但是由于 HTTP 報頭較為冗長,性能較差,基于 TCP 協議的 RPC 可以建立長連接,速度和效率明顯,但是難度和復雜程度很高。
RPC 的誕生讓構建分布式應用更容易,極大的擴大系統的可擴展性,容錯性。為復雜業務邏輯的系統進行服務化改造和高可用性升級提供了可能。
RPC 調用分類
RPC 調用的分類方式有很多種。
從通信協議層面可以分為:
基于 HTTP 協議的 RPC;
基于二進制協議的 RPC;
基于 TCP 協議的 RPC。
從是否跨平臺可分為:
單語言 RPC,如 RMI, Remoting;
跨平臺 RPC,如 google protobuffer, restful json,http XML。
從調用過程來看,可以分為同步通信RPC和異步通信RPC:
同步 RPC:指的是客戶端發起調用后,必須等待調用執行完成并返回結果;
異步 RPC:指客戶方調用后不關心執行結果返回,如果客戶端需要結果,可用通過提供異步 callback 回調獲取返回信息。大部分 RPC 框架都同時支持這兩種方式的調用。
RPC 框架結構
一個完整的 RPC 框架的架構主要模塊如圖所示。
RPC 服務方的主要職責是提供服務,供客戶端調用訪問,服務端會通過一個接收器接受客戶端的調用請求,根據相應的 RPC 協議進行解碼獲取調用方法以及相關參數,當調用完成后,服務器端通過后臺處理模塊處理完成并將結果返回給客戶端。
對于客戶端來說,服務調用完全透明,像調用本地服務一樣調用遠程方法,客戶端調用服務時候通過一個遠程連接和服務端建立通道,并通過相應的協議進行編碼,將調用的方法和相關參數發送給服務方。
上 手 篇
RPC 模塊詳解
下面我們根據上面的RPC的架構圖,對圖中的各個模塊進行拆解,并解釋每個模塊的作用。
服務端(Server):RPC 服務的提供者,負責將 RPC 服務導出;
客戶端 (Client):RPC 服務的消費者,負責調用 RPC 服務;
代理(Proxy):通過動態代理,提供對遠程接口的代理實現;
執行器(Invoker):對于客戶端:主要負責服務調用的編碼,調用請求發送和等待結果返回;對于服務方:負責處理調用邏輯并返回調用結果;
協議管理(Protocol):協議管理組件,負責整個 RPC 通信協議的編/解碼;
連接端口(Connector):負責維持客戶方和服務方的長連接通道;
后臺處理(Processor):負責整個調用服務中的管理調度,包括線程池,分發,異常處理等;
連接通道(Channel):客戶端和服務器端的數據傳輸通道。
具體到 JAVA 平臺來說,其中的3,4通常使用動態代理實現,5,6,7,8使用 NIO 或者一些高性能 NIO 框架,如 mina,netty 實現。
最簡單的 RPC JAVA 實現
在進一步拆解了組件并劃分了職責之后,這里以一個最簡單 Java RPC 框架實現為例,對 RPC 具體邏輯進行分析。
RPC 框架服務發布代碼:
服務端發布服務的代碼如上,首先校驗傳入的端口和服務是否合法,然后開啟一個 socket 監聽,這兒為了簡便,沒有采用 NIO 方式,同時直接采用 java 的序列化方式,將傳入的數據通過反射取出調用的方法和參數,本地執行后將運行結果通過 socket 套接字返回給客戶端。
RPC 框架服務調用代碼:
框架中客戶端調用的代碼中,首先校驗對應的端口和主機是否合法,然后通過動態代理生成一個代理對象,在代理對象的方法中,攔截調用,通過建立 socket 連接,將方法和參數傳遞到遠端執行并獲取遠程執行返回結果。
RPC 調用測試:
如上圖所示,服務器端發布一個接口服務 HelloService,客戶端成功通過 RPC 調用。
思 考 篇
自定義 RPC 協議
協議頭
在上面的示例程序當中,我們僅僅是完成了一個基本的遠程調用,并沒有實現 RPC 框架中的很多組件功能,從最簡單的代碼版本中我們可以發現,發起一個 RPC 調用,需要傳輸的最基本數據如下:
接口方法:包括接口的名字和相應的方法名字;
方法參數:包括參數的類型和取值;
附件參數,包括調用接口版本,接口超時時間等等。
因此,如果要自定義協議實現 RPC,我們必須再協議的消息體中包含這部分數據,另外,我們需要定義一些協議元數據,這些元數據通常放在協議頭中,和包含必要參數的協議體一期組成了自定義消息。
元數據通常會包含以下字段,大部分字段只需要1-2位:
magic: 魔數,方便協議解碼
header_size: 協議頭大小,便于解碼,同時可用用于處理TCP粘包問題
id :消息 id,用來標示這次調用
version: 接口版本
type:消息類型,可用包括普通調用消息,心跳,控制消息
status:消息狀態,是否首次處理或者已經處理
body_size: 消息體長度
serialize_type:消息體序列化類型
body:具體消息
具體消息
消息內容在網絡上傳輸需要對其進行編碼,這個編碼的過程就是序列化過程,顯然,對于網絡傳輸的數據,在能夠保證信息足夠解碼的情況下,序列化的大小越小,傳輸的開銷就越小,效率就越高,目前 JAVA 平臺常用的序列化方式有:xml,json ,binary(包括 thrift; hession; kryo 等)。
在 RPC 調用中我們推薦使用二進制方式進行序列化,在大部分的測試中,二進制方式序列化具有相當好的表現,另外一個比較有意思的地方是,每一次 JDK 版本的升級,JAVA 自帶的序列化方式的效率都有提升。
服務端調用優化
從前面的示例代碼中,我們僅僅簡單的考慮了實現了組件中的服務端和客戶端,并沒有考慮效率問題,在一個完整的 RPC 框架中,我們需要考慮實現并優化調用的每一個地方,同時,為了符合業務需求,需要有很高的可靠性和容錯機制。
具體來說,在動態代理模塊,我們不會采用 java 自帶的動態接口,而是會采用一些性能更高的三方庫,在連接通道和連接模塊,我們會采用更優秀的三方NIO,如 netty 來實現,在后端處理模塊,我們也不會僅僅是執行結果并返回,要考慮更多的東西:
并發控制:當多個請求并發處理的時候,如何管理和控制線程池和超時等待時間;
版本隔離:當服務有多個版本的時候,如何讓不同的調用者能夠調用正確的服務;
服務路由:當服務提供者有多臺機器的時候,如何提高系統負載均衡,路由到正確的服務端;
服務降級:當多個服務重要性有不同的時候,如果保證核心業務的穩定性,適當的降低非核心業務優先級;
服務監控和報警:服務出現異常情況時候,運維和對應的系統負責人能夠第一時間得到告警和錯誤信息。
以上的思考大部分要結合運維層面一起考慮,但是 RPC 框架本身也要提供足夠的支持才能保證它足夠的健壯性。
需要注意的一些地方
雖然 RPC 有足夠多的優點讓你去使用,但是當真正轉向服務化的時候,依然有很多需要考慮的地方:
網絡問題:本地調用無需考慮是否能夠執行問題,網絡調用可能會因為各種外部網絡環境,端口攔截,IP 受限等可能情況導致無法成功執行。所以 RPC 的服務端通常要考慮冪等性和容錯性,接口需要較強的魯棒性設計。
異常處理:RPC 和本地服務最大的不同就是 RPC 服務存在分布式一致性問題,當服務沒有調用成功情況下,本地和遠程的服務可能處于一個不一致的狀態,如何進行異常處理和事物的回滾機制也是一個需要考慮的問題,是需要保障強一致性和最終一致性通常取決于具體的業務需求。
由于網絡原因,RPC 服務通常會被本地服務處理慢一個數量級,在比較輕量級的業務和并發量很小的情況下,并不需要 RPC 服務,引入 RPC 服務后,無論是系統的調試,還是線上問題分析都會變得非常復雜,是否引入也需要權衡相關利弊。
文末小結
本文簡單的介紹了 RPC 的基本知識和相關分析以供拋磚引玉,進一步的學習可以參考當前最主流的一些 RPC 框架,如dubbo, protobuff ,thrift 通過對其源碼的深入學習,相信能獲益匪淺。
-
JAVA
+關注
關注
19文章
2975瀏覽量
105164 -
RPC
+關注
關注
0文章
111瀏覽量
11578
發布評論請先 登錄
相關推薦
評論