Dubbo原始碼淺析（一）—RPC框架與Dubbo

京東雲開發者發表於2023-09-28
原始碼RPC框架

一、什麼是RPC

1.1 RPC概念

RPC，Remote Procedure Call 即遠端過程呼叫，與之相對的是本地服務呼叫，即LPC(Local Procedure Call)。本地服務呼叫比較常用，像我們應用內部程式(注意此處是程式而不是方法，程式包含方法)互相呼叫即為本地過程呼叫，而遠端過程呼叫是指在本地調取遠端過程進行使用。

而RPC框架就是為了幫助我們在本地呼叫遠端過程時，就像呼叫本地過程一樣方便。

1.2 RPC與Http的關係

用一句話來總結就是：

RPC是一種概念，http是一種協議，可以認為http是Rpc的一種實現，或者Rpc包含了http。為什麼說包含而不是相等，是因為Rpc還有很多基於自定義的Tcp的協議，例如Dubbo等，而我們常說的rpc即指的除Http之外的基於tcp自定義的協議。

1.3 關於Rpc的思考

網上關於Rpc與Http的相關文章並不少，很多人在解釋RPC概念時會提到其是執行遠端的方法，然後直接得出rpc包含http的結論。其實如果按照此概念去思考的話，其實並不能得出Http是Rpc的一種實現。因為http呼叫的方式，從使用者的角度來說，並不是直接呼叫其方法，而是按照一定的方式，完善出了一條http請求，然後交由本地客戶端進行資料傳輸。

而相對比的，如果用過相關Rpc框架，例如Dubbo，是可以像呼叫本地方法一樣直接呼叫遠端方法。而http的呼叫方式可以認為是一種服務呼叫，而不是一種方法。

感覺文章博主應該是有過rpc相關的使用經驗，有點先入為主了。那麼到底rpc與http的關係如何呢，我也思考了很久，後面發現應該從定義上入手，我們既然在討論Rpc是什麼，怎麼能忽略最簡單的定義呢。

Remote Procedure Call，其中"Procedure"按照谷歌翻譯有以下幾種解釋：程式、過程、步驟，並不是方法(Method)。而程式是包含方法的，同時也包含服務。因此上文中才強調了是一種程式或過程，而不是方法。

1.4 Rpc框架

Rpc框架是為了幫助我們在本地服務呼叫遠端服務時像呼叫本地服務一樣簡單，我們不需要關心其底層實現，只需要配置好相應的資訊，rpc框架就會幫我們做這些事。例如在dubbo中，我們只需要配置好相應的註冊中心與想要呼叫的方法，我們就可以按照本地呼叫的方式呼叫遠端服務。

1.5 總結

按照我們上文的梳理過程，可以認為Rpc是一種概念，主要有兩種實現，一種是以http方式的服務呼叫，另一種是以自定義Tcp協議實現的方法呼叫方式，例如dubbo協議，當然一般rpc框架也都支援http協議。當然，無論是那種方式，最終都是以Tcp/Udp的方式進行傳輸。

image-20221116163351469

二、Rpc框架

2.1 dubbo是什麼

我們上文說到Rpc框架就是幫助我們在呼叫遠端服務時像呼叫本地服務一樣簡單，dubbo就是由阿里巴巴開源的一塊rpc框架。

例如，在我們想呼叫某個遠端方法時，只需要配置好相關配置，然後直接呼叫即可，dubbo會幫助我們將處理中間的過程。

/*
省略相關配置
*/

//將配置註冊到spring
@Resource
private QueryPinService queryPinService;

//直接使用遠端方法，像呼叫本地服務一樣簡單
ueryPinService.getPinWithConfig(paramMap, null);

dubbo整體架構圖如下：

圖片

節點 說明
Provider 提供遠端服務的服務提供方
Registry 註冊中心
Consumer 需要呼叫遠端服務的服務消費方
Container 服務執行的容器
Monitor 監控中心

作用流程大致如下：

首先服務提供者Provider 啟動然後向註冊中心註冊自己所能提供的服務。

服務消費者Consumer 啟動向註冊中心訂閱自己所需的服務。然後註冊中心將提供者元資訊通知給 Consumer， 之後 Consumer 因為已經從註冊中心獲取提供者的地址，因此可以透過負載均衡選擇一個 Provider 直接呼叫。

之後服務提供方後設資料變更的話註冊中心會把變更推送給服務消費者。

服務提供者和消費者都會在記憶體中記錄著呼叫的次數和時間，然後定時的傳送統計資料到監控中心。

2.2 dubbo和spring cloud的區別

首先兩者都是當前主流的微服務框架，不過兩者也存在很多差異：

  1. 初始定位不同：SpringCloud定位為微服務架構下的一站式解決方案，主要有閘道器、註冊中心、配置中心、監控中心等；Dubbo 是 它的關注點主要在於服務的呼叫和治理，其中服務呼叫更時其核心。

  2. 生態環境不同：SpringCloud依託於Spring平臺，具備更加完善的生態體系；而Dubbo一開始只是做RPC遠端呼叫，生態相對匱乏，現在逐漸豐富起來。

  3. 呼叫方式：SpringCloud是採用Http協議做遠端呼叫，介面一般是Rest風格，比較靈活；Dubbo是採用Dubbo協議，介面一般是Java的Service介面，格式固定。但呼叫時採用Netty的NIO方式，效能較好。

兩者元件配置：

image-20221116173852813

很明顯SpringCloud擁有比dubbo更完善的配置，支援的功能性也更強。

相比來說，SpringCloud像一臺品牌機，內部所有配置都已經幫我們裝配好了，我們只需要開箱即用即可。而dubbo則更像是組裝機，需要我們自己選擇配置，只提供了核心的計算能力，而顯示器、電源等需要我們自己裝配除錯使用。

從使用者來說，新手小白更適合品牌機，傻瓜式一鍵操作，就能完成我們想要的效果。而dubbo更適合電腦高手，自己裝配自己想要的元件，使用起來更順手。

作者：京東科技 韓國凱

來源：京東雲開發者社群 轉載請註明來源

相關文章