點贊再看，養成習慣，微信搜一搜【三太子敖丙】關注這個喜歡寫情懷的程式設計師。

本文 GitHub https://github.com/JavaFamily 已收錄，有一線大廠面試完整考點、資料以及我的系列文章。

前言

接下來一段時間敖丙將帶大家開啟緊張刺激的 Dubbo 之旅！是的要開始寫 Dubbo 系列的文章了，之前我已經寫過一篇架構演進的文章，也說明了微服務的普及化以及重要性，服務化場景下隨之而來的就是服務之間的通訊問題，那服務間的通訊腦海中想到的就是 RPC，說到 RPC 就離不開咱們的 Dubbo。

這篇文章敖丙先帶著大家來總覽全域性，一般而言熟悉一個框架你要先知道這玩意是做什麼的，能解決什麼痛點，核心的模組是什麼，大致運轉流程是怎樣的。

你要一來就扎入細節之中無法自拔，一波 DFS 直接被勸退的可能性高達99.99%，所以本暖男敖丙將帶大家先過一遍 Dubbo 的簡介、總體分層、核心元件以及大致呼叫流程。

不僅如此我還會帶著大家過一遍如果要讓你設計一個 RPC 框架你看看都需要什麼功能？這波操作之後你會發現嘿嘿 Dubbo 怎麼設計的和我想的一樣呢？真是英雄所見略同啊！

而且我還會寫一個簡單版 RPC 框架實現，讓大家明白 RPC 到底是如何工作的。

如果看了這篇文章你要還是不知道 Dubbo 是啥，我可以要勸退了。

我們先來談一談什麼叫 RPC ，我發現有很多同學不太瞭解這個概念，還有人把 RPC 和 HTTP 來進行對比。所以咱們先來說說什麼是 RPC。

什麼是 RPC

RPC，Remote Procedure Call 即遠端過程呼叫，遠端過程呼叫其實對標的是本地過程呼叫，本地過程呼叫你熟悉吧？

想想那青蔥歲月，你在大學趕著期末大作業，正在攻克圖書管理系統，你奮筆疾書瘋狂地敲擊鍵盤，實現了圖書借閱、圖書歸還等等模組，你實現的一個個方法之間的呼叫就叫本地過程呼叫。

你要是和我說你實現圖書館裡系統已經用了服務化，搞了遠端呼叫了，我只能和你說你有點東西。

簡單的說本機上內部的方法呼叫都可以稱為本地過程呼叫，而遠端過程呼叫實際上就指的是你本地呼叫了遠端機子上的某個方法，這就是遠端過程呼叫。

所以說 RPC 對標的是本地過程呼叫，至於 RPC 要如何呼叫遠端的方法可以走 HTTP、也可以是基於 TCP 自定義協議。

所以說你討論 RPC 和 HTTP 就不是一個層級的東西。

而 RPC 框架就是要實現像那小助手一樣的東西，目的就是讓我們使用遠端呼叫像本地呼叫一樣簡單方便，並且解決一些遠端呼叫會發生的一些問題，使使用者用的無感知、舒心、放心、順心，它好我也好，快樂沒煩惱。

如何設計一個 RPC 框架

在明確了什麼是 RPC，以及 RPC 框架的目的之後，咱們想想如果讓你做一款 RPC 框架你該如何設計？

服務消費者

我們先從消費者方(也就是呼叫方)來看需要些什麼，首先消費者面向介面程式設計，所以需要得知有哪些介面可以呼叫，可以通過公用 jar 包的方式來維護介面。

現在知道有哪些介面可以呼叫了，但是隻有介面啊，具體的實現怎麼來？這事必須框架給處理了！所以還需要來個代理類，讓消費者只管調，啥事都別管了，我代理幫你搞定。

對了，還需要告訴代理，你呼叫的是哪個方法，並且引數的值是什麼。

雖說代理幫你搞定但是代理也需要知道它到底要調哪個機子上的遠端方法，所以需要有個註冊中心，這樣呼叫方從註冊中心可以知曉可以呼叫哪些服務提供方，一般而言提供方不止一個，畢竟只有一個掛了那不就沒了。

所以提供方一般都是叢集部署，那呼叫方需要通過負載均衡來選擇一個呼叫，可以通過某些策略例如同機房優先呼叫啊啥的。

當然還需要有容錯機制，畢竟這是遠端呼叫，網路是不可靠的，所以可能需要重試什麼的。

還要和服務提供方約定一個協議，例如我們就用 HTTP 來通訊就好啦，也就是大家要講一樣的話，不然可能聽不懂了。

當然序列化必不可少，畢竟我們本地的結構是“立體”的，需要序列化之後才能傳輸，因此還需要約定序列化格式。

並且這過程中間可能還需要摻入一些 Filter，來作一波統一的處理，例如呼叫計數啊等等。

這些都是框架需要做的，讓消費者像在呼叫本地方法一樣，無感知。

服務提供者

服務提供者肯定要實現對應的介面這是毋庸置疑的。

然後需要把自己的介面暴露出去，向註冊中心註冊自己，暴露自己所能提供的服務。

然後有消費者請求過來需要處理，提供者需要用和消費者協商好的協議來處理這個請求，然後做反序列化。

序列化完的請求應該扔到執行緒池裡面做處理，某個執行緒接受到這個請求之後找到對應的實現呼叫，然後再將結果原路返回。

註冊中心

上面其實我們都提到了註冊中心，這東西就相當於一個平臺，大家在上面暴露自己的服務，也在上面得知自己能呼叫哪些服務。

當然還能做配置中心，將配置集中化處理，動態變更通知訂閱者。

監控運維

面對眾多的服務，精細化的監控和方便的運維必不可少。

這點很多開發者在開發的時候察覺不到，到你真正上線開始執行維護的時候，如果沒有良好的監控措施，快速的運維手段，到時候就是睜眼瞎！手足無措，等著挨批把！

那種痛苦不要問我為什麼知道，我就是知道！

小結一下

讓我們小結一下，大致上一個 RPC 框架需要做的就是約定要通訊協議，序列化的格式、一些容錯機制、負載均衡策略、監控運維和一個註冊中心！

簡單實現一個 RPC 框架

沒錯就是簡單的實現，上面我們在思考如何設計一個 RPC 框架的時候想了很多，那算是生產環境使用級別的功能需求了，我們這是 Demo，目的是突出 RPC框架重點功能 - 實現遠端呼叫。

所以啥七七八八的都沒，並且我用虛擬碼來展示，其實也就是刪除了一些保護性和約束性的程式碼，因為看起來太多了不太直觀，需要一堆 try-catch 啥的，因此我刪減了一些，直擊重點。

Let's Do It！

首先我們定義一個介面和一個簡單實現。

publicinterfaceAobingService{
Stringhello(Stringname);
}

publicclassAobingServiceImplimplementsAobingService{
publicStringhello(Stringname){
return"YomanHello，Iam"+name;
}
}

然後我們再來實現服務提供者暴露服務的功能。

publicclassAobingRpcFramework{
publicstaticvoidexport(Objectservice,intport)throwsException{
ServerSocketserver=newServerSocket(port);
while(true){
Socketsocket=server.accept();
newThread(newRunnable(){
//反序列化
ObjectInputStreaminput=newObjectInputStream(socket.getInputStream());
StringmethodName=input.read();//讀取方法名
Class<?>[]parameterTypes=(Class<?>[])input.readObject();//引數型別
Object[]arguments=(Object[])input.readObject();//引數
Methodmethod=service.getClass().getMethod(methodName,parameterTypes);//找到方法
Objectresult=method.invoke(service,arguments);//呼叫方法
//返回結果
ObjectOutputStreamoutput=newObjectOutputStream(socket.getOutputStream());
output.writeObject(result);
}).start();
}
}
publicstatic<T>Trefer(Class<T>interfaceClass,Stringhost,intport)throwsException{
return(T)Proxy.newProxyInstance(interfaceClass.getClassLoader(),newClass<?>[]{interfaceClass},
newInvocationHandler(){
publicObjectinvoke(Objectproxy,Methodmethod,Object[]arguments)throwsThrowable{
Socketsocket=newSocket(host,port);//指定provider的ip和埠
ObjectOutputStreamoutput=newObjectOutputStream(socket.getOutputStream());
output.write(method.getName());//傳方法名
output.writeObject(method.getParameterTypes());//傳引數型別
output.writeObject(arguments);//傳引數值
ObjectInputStreaminput=newObjectInputStream(socket.getInputStream());
Objectresult=input.readObject();//讀取結果
returnresult;
}
});
}
}

好了，這個 RPC 框架就這樣好了，是不是很簡單？就是呼叫者傳遞了方法名、引數型別和引數值，提供者接收到這樣引數之後呼叫對於的方法返回結果就好了！這就是遠端過程呼叫。

我們來看看如何使用

//服務提供者只需要暴露出介面
AobingServiceservice=newAobingServiceImpl();
AobingRpcFramework.export(service,2333);

//服務呼叫者只需要設定依賴
AobingServiceservice=AobingRpcFramework.refer(AobingService.class,"127.0.0.1",2333);
service.hello();

看起來好像好不錯喲，不過這很是簡陋，用作 demo 有助理解還是極好的！

接下來就來看看 Dubbo 吧！上正菜！

Dubbo 簡介

Dubbo 是阿里巴巴 2011年開源的一個基於 Java 的 RPC 框架，中間沉寂了一段時間，不過其他一些企業還在用 Dubbo 並自己做了擴充套件，比如噹噹網的 Dubbox，還有網易考拉的 Dubbok。

但是在 2017 年阿里巴巴又重啟了對 Dubbo 維護。在 2017 年榮獲了開源中國 2017 最受歡迎的中國開源軟體 Top 3。

在 2018 年和 Dubbox 進行了合併，並且進入 Apache 孵化器，在 2019 年畢業正式成為 Apache 頂級專案。

目前 Dubbo 社群主力維護的是 2.6.x 和 2.7.x 兩大版本，2.6.x 版本主要是 bug 修復和少量功能增強為準，是穩定版本。

而 2.7.x 是主要開發版本，更新和新增新的 feature 和優化，並且 2.7.5 版本的釋出被 Dubbo 認為是里程碑式的版本釋出，之後我們再做分析。

它實現了面向介面的代理 RPC 呼叫，並且可以配合 ZooKeeper 等元件實現服務註冊和發現功能，並且擁有負載均衡、容錯機制等。

Dubbo 總體架構

我們先來看下官網的一張圖。

本丙再暖心的給上圖內每個節點的角色說明一下。

我再來大致說一下整體的流程，首先服務提供者 Provider 啟動然後向註冊中心註冊自己所能提供的服務。

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

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

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

一些注意點

首先註冊中心和監控中心是可選的，你可以不要監控，也不要註冊中心，直接在配置檔案裡面寫然後提供方和消費方直連。

然後註冊中心、提供方和消費方之間都是長連線，和監控方不是長連線，並且消費方是直接呼叫提供方，不經過註冊中心。

就算註冊中心和監控中心宕機了也不會影響到已經正常執行的提供者和消費者，因為消費者有本地快取提供者的資訊。

Dubbo 分層架構

總的而言 Dubbo 分為三層，如果每一層再細分下去，一共有十層。別怕也就十層，本丙帶大家過一遍，大家先有個大致的印象，之後的文章丙會帶著大家再深入。

大的三層分別為 Business（業務層）、RPC 層、Remoting，並且還分為 API 層和 SPI 層。

分為大三層其實就是和我們知道的網路分層一樣的意思，只有層次分明，職責邊界清晰才能更好的擴充套件。

而分 API 層和 SPI 層這是 Dubbo 成功的一點，採用微核心設計+SPI擴充套件，使得有特殊需求的接入方可以自定義擴充套件，做定製的二次開發。

接下來咱們再來看看每一層都是幹嘛的。

• Service，業務層，就是咱們開發的業務邏輯層。

• Config，配置層，主要圍繞 ServiceConfig 和 ReferenceConfig，初始化配置資訊。

• Proxy，代理層，服務提供者還是消費者都會生成一個代理類，使得服務介面透明化，代理層做遠端呼叫和返回結果。

• Register，註冊層，封裝了服務註冊和發現。

• Cluster，路由和叢集容錯層，負責選取具體呼叫的節點，處理特殊的呼叫要求和負責遠端呼叫失敗的容錯措施。

• Monitor，監控層，負責監控統計呼叫時間和次數。

• Portocol，遠端呼叫層，主要是封裝 RPC 呼叫，主要負責管理 Invoker，Invoker代表一個抽象封裝了的執行體，之後再做詳解。

• Exchange，資訊交換層，用來封裝請求響應模型，同步轉非同步。

• Transport，網路傳輸層，抽象了網路傳輸的統一介面，這樣使用者想用 Netty 就用 Netty，想用 Mina 就用 Mina。

• Serialize，序列化層，將資料序列化成二進位制流，當然也做反序列化。

SPI

我再稍微提一下 SPI（Service Provider Interface），是 JDK 內建的一個服務發現機制，它使得介面和具體實現完全解耦。我們只宣告介面，具體的實現類在配置中選擇。

具體的就是你定義了一個介面，然後在META-INF/services目錄下放置一個與介面同名的文字檔案，檔案的內容為介面的實現類，多個實現類用換行符分隔。

這樣就通過配置來決定具體用哪個實現！

而 Dubbo SPI 還做了一些改進，篇幅有限留在之後再談。

Dubbo 呼叫過程

上面我已經介紹了每個層到底是幹嘛的，我們現在再來串起來走一遍呼叫的過程，加深你對 Dubbo 的理解，讓知識點串起來，由點及面來一波連連看。

我們先從服務提供者開始，看看它是如何工作的。

服務暴露過程

首先 Provider 啟動，通過 Proxy 元件根據具體的協議 Protocol 將需要暴露出去的介面封裝成 Invoker，Invoker 是 Dubbo 一個很核心的元件，代表一個可執行體。

然後再通過 Exporter 包裝一下，這是為了在註冊中心暴露自己套的一層，然後將 Exporter 通過 Registry 註冊到註冊中心。 這就是整體服務暴露過程。

消費過程

接著我們來看消費者呼叫流程（把服務者暴露的過程也在圖裡展示出來了，這個圖其實算一個挺完整的流程圖了）。

首先消費者啟動會向註冊中心拉取服務提供者的元資訊，然後呼叫流程也是從 Proxy 開始，畢竟都需要代理才能無感知。

Proxy 持有一個 Invoker 物件，呼叫 invoke 之後需要通過 Cluster 先從 Directory 獲取所有可呼叫的遠端服務的 Invoker 列表，如果配置了某些路由規則，比如某個介面只能呼叫某個節點的那就再過濾一遍 Invoker 列表。

剩下的 Invoker 再通過 LoadBalance 做負載均衡選取一個。然後再經過 Filter 做一些統計什麼的，再通過 Client 做資料傳輸，比如用 Netty 來傳輸。

傳輸需要經過 Codec 介面做協議構造，再序列化。最終發往對應的服務提供者。

服務提供者接收到之後也會進行 Codec 協議處理，然後反序列化後將請求扔到執行緒池處理。某個執行緒會根據請求找到對應的 Exporter ，而找到 Exporter 其實就是找到了 Invoker，但是還會有一層層 Filter，經過一層層過濾鏈之後最終呼叫實現類然後原路返回結果。

完成整個呼叫過程！

總結

這次敖丙帶著大家先了解了下什麼是 RPC，然後規劃了一波 RPC 框架需要哪些元件，然後再用程式碼實現了一個簡單的 RPC 框架。

然後帶著大家瞭解了下 Dubbo 的發展歷史、總體架構、分層設計架構以及每個元件是幹嘛的，再帶著大夥走了一遍整體呼叫過程。

我真的是太暖了啊！

dubbo近期我會安排幾個章節繼續展開，最後會出一個面試版本的dubbo，我們拭目以待吧。

絮叨

另外，敖丙把自己的面試文章整理成了一本電子書，共 1630頁！目錄如下，還有我複習時總結的面試題以及簡歷模板

現在免費送給大家，點贊後在我的公眾號三太子敖丙回覆 【資料】 即可獲取。

我是敖丙，你知道的越多，你不知道的越多，我們下期見！

人才們的 【三連】 就是敖丙創作的最大動力，如果本篇部落格有任何錯誤和建議，歡迎人才們留言！

文章持續更新，可以微信搜一搜「 三太子敖丙 」第一時間閱讀，回覆【資料】有我準備的一線大廠面試資料和簡歷模板，本文 GitHub https://github.com/JavaFamily 已經收錄，有大廠面試完整考點，歡迎Star。