Dubbo常見面試題

前言

Dubbo 總體介紹的差很少了，今天就開始面試環節了，我會列舉一些常見的 Dubbo 面試題，只會抓着重的，一些太簡單的我就不提了。

不只僅給你面試題的答案，也會剖析面試官問這個問題的緣由，也就是他的心裏活動。

想從你這裏問出什麼？想要什麼答案？想挖什麼坑給你跳？

開始表演

知道什麼是 RPC 麼？

通常面試官會以這樣的問題來切入、熱場，畢面試也是按部就班的過程，因此你也不用太心急一開始就芭芭拉說一堆，要抓住關鍵點簡單闡述先。

並且面試官能從這個問題鑑定出你平日的工做內容會不會連 RPC 都沒接觸過，會不會就只是一條龍的 Spring MVC ?

確實有不少同窗沒接觸過 RPC ，也很正常好比一些外包或者一些小項目都接觸不到的，不過平日接觸不到和你不知道這個東西是兩個概念。

能從側面反映出這我的工做之餘應該不怎麼學習，連 RPC 都不知道，因此怎麼都說不過去，基本上要涼涼，對你的初始印象就差了，除非你能從後面有亮眼的表現。

答：RPC 就是 Remote Procedure Call，遠程過程調用，它相對應的是本地過程調用。

那爲何要有 RPC，HTTP 很差麼？

這時候面試官就開始追問了。

這個問題其實頗有意思，有些面試官可能本身不太清楚，而後覺得本身很清楚，因此問出這個問題，還有一種是真的清楚，問這個問題是爲了讓你跳坑裏。

由於 RPC 和 HTTP 就不是一個層級的東西，因此嚴格意義上這兩個沒有可比性，也不該該來做比較，而題目問的就是把這兩個做爲比較了。

HTTP 只是傳輸協議，協議只是規範了必定的交流格式，並且 RPC 是早於 HTTP 的，因此真要問也是問有 RPC 爲何還要 HTTP。

RPC 對比的是本地過程調用，是用來做爲分佈式系統之間的通訊，它能夠用 HTTP 來傳輸，也能夠基於 TCP 自定義協議傳輸。

因此你要先提出這兩個不是一個層級的東西，沒有可比性，而後再表現一下，能夠說 HTTP 協議比較冗餘，因此 RPC 大多都是基於 TCP 自定義協議，定製化的纔是最適合本身的。

固然也有基於 HTTP 協議的 RPC 框架，畢竟 HTTP 是公開的協議，比較通用，像 HTTP2 已經作了相應的壓縮了，並且系統之間的調用都在內網，因此說影響也不會很大。

這波回答下來，面試官會以爲你有點東西，開始對你有點興趣了，要開始深刻你了。

說說你對 Dubbo 的瞭解？

面試官會先問個大點的問題，而後從你的回答中找到一些突破口來深刻問，因此這個問題其實挺開放性的，你能夠從歷史的發展來答，也能夠從總體架構來答。

若是從歷史發展的角度來答，說明你平日裏也是挺關注一些開源軟件的，側面也能體現你的對開源的擁抱。

若是從整體架構答，毋庸置疑確定也是能夠的，建議先淺顯的說，等着追問。

歷史發展，這個其實丙以前文章已經提到了：

Dubbo 是阿里巴巴開源的一個基於 Java 的 RPC 框架，中間沉寂了一段時間，但在 2017 年阿里巴巴又重啓了對 Dubbo 維護。

而且在 2018 年和 噹噹的 Dubbox 進行了合併，進入 Apache 孵化器，在 2019 年畢業正式成爲 Apache 頂級項目。

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

2.7.5 版本的發佈被 Dubbo 認爲是里程碑式的版本發佈，支持 gRPC，而且性能提高了 30%（這裏不瞭解gRPC 和爲何性能提高的話就別說了，別給本身挖坑）。

最新的 3.0 版本往雲原生方向上探索着。

注意了，若是對歷史各個版本不太熟，也不知道最新的版本要幹啥就別往這方向答了，運氣好點就是面試官本身也不太瞭解，他可能不會問，運氣背點就追問了。

整體架構，上面也提到了先淺顯的說，等追問，由於面試官若是懂，他確定會問深刻，若是不懂你芭芭拉一堆他無感的。

你就簡單的提一下如今這幾個角色。

節點	角色說明
Consumer	須要調用遠程服務的服務消費方
Registry	註冊中心
Provider	服務提供方
Container	服務運行的容器
Monitor	監控中心

好比， Dubbo 整體分了以上這麼幾個角色，分別的做用是xxxx。

這裏停頓下看下面試官的反應，若是沒搭話，就繼續說大體的流程。

首先服務提供者 Provider 啓動而後向註冊中心註冊本身所能提供的服務。

服務消費者 Consumer 啓動向註冊中心訂閱本身所需的服務。而後註冊中心將提供者元信息通知給 Consumer， 以後 Consumer 由於已經從註冊中心獲取提供者的地址，所以能夠經過負載均衡選擇一個 Provider 直接調用 。

以後服務提供方元數據變動的話註冊中心會把變動推送給服務消費者。

服務提供者和消費者都會在內存中記錄着調用的次數和時間，而後定時的發送統計數據到監控中心。

到這基本上就差很少了，若是以前看過丙的 Dubbo 系列文章的話，那就算看過源碼了，確定對一系列過程很清晰了，因此在適當的時機能夠說本身看過 Dubbo 源碼。

衆所周知，看過源碼確定是加分項，因此這點是要提的。

面試官一聽，好傢伙看過源碼是吧，來講說。

接下來就開始連擊了。

看過源碼，那說下服務暴露的流程？

服務的暴露起始於 Spring IOC 容器刷新完畢以後，會根據配置參數組裝成 URL， 而後根據 URL 的參數來進行本地或者遠程調用。

會經過 proxyFactory.getInvoker，利用 javassist 來進行動態代理，封裝真的實現類，而後再經過 URL 參數選擇對應的協議來進行 protocol.export，默認是 Dubbo 協議。

在第一次暴露的時候會調用 createServer 來建立 Server，默認是 NettyServer。

而後將 export 獲得的 exporter 存入一個 Map 中，供以後的遠程調用查找，而後會向註冊中心註冊提供者的信息。

基本上就是這麼個流程，說了這些差很少了，太細的誰都記住不。

看過源碼，那說下服務引入的流程？

服務的引入時機有兩種，第一種是餓漢式，第二種是懶漢式。

餓漢式就是加載完畢就會引入，懶漢式是隻有當這個服務被注入到其餘類中時啓動引入流程，默認是懶漢式。

會先根據配置參數組裝成 URL ，通常而言咱們都會配置的註冊中心，因此會構建 RegistryDirectory
向註冊中心註冊消費者的信息，而且訂閱提供者、配置、路由等節點。

得知提供者的信息以後會進入 Dubbo 協議的引入，會建立 Invoker ，期間會包含 NettyClient，來進行遠程通訊，最後經過 Cluster 來包裝 Invoker，默認是 FailoverCluster，最終返回代理類。

說這麼多差很少了，關鍵的點都提到了。

切忌不要太過細，不要把你知道的都說了，這樣會抓不住重點，好比上面的流程你要插入，引入的三種方式：本地引入、直連遠程引入、經過註冊中心引入。

而後再分別說本地引入怎樣的，芭芭拉的就會很亂，因此面試的時候是須要刪減的，要直擊重點。

其實真實說的應該比我上面說的還要精簡點才行，我是怕你們不太清楚說的稍微詳細了一些。

看過源碼，那說下服務調用的流程？

調用某個接口的方法會調用以前生成的代理類，而後會從 cluster 中通過路由的過濾、負載均衡機制選擇一個 invoker 發起遠程調用，此時會記錄此請求和請求的 ID 等待服務端的響應。

服務端接受請求以後會經過參數找到以前暴露存儲的 map，獲得相應的 exporter ，而後最終調用真正的實現類，再組裝好結果返回，這個響應會帶上以前請求的 ID。

消費者收到這個響應以後會經過 ID 去找以前記錄的請求，而後找到請求以後將響應塞到對應的 Future 中，喚醒等待的線程，最後消費者獲得響應，一個流程完畢。

關鍵的就是 cluster、路由、負載均衡，而後 Dubbo 默認是異步的，因此請求和響應是如何對應上的。

以後可能還會追問 Dubbo 異步轉同步如何實現的之類的，在丙以前文章裏面都說了，忘記的同窗能夠回去看看。

知道什麼是 SPI 嘛？

這又是一個方向了，從上面的回答中，不管是從 Dubbo 協議，仍是 cluster ，什麼 export 方法等等無處不是 SPI 的影子，因此若是是問 Dubbo 方面的問題，問 SPI 是毋庸置疑的，由於源碼裏 SPI 無處不在，並且 SPI 也是 Dubbo 可擴展性的基石。

因此這個題目沒什麼套路，直接答就行。

SPI 是 Service Provider Interface，主要用於框架中，框架定義好接口，不一樣的使用者有不一樣的需求，所以須要有不一樣的實現，而 SPI 就經過定義一個特定的位置，Java SPI 約定在 Classpath 下的 META-INF/services/ 目錄裏建立一個以服務接口命名的文件，而後文件裏面記錄的是此 jar 包提供的具體實現類的全限定名。

因此就能夠經過接口找到對應的文件，獲取具體的實現類而後加載便可，作到了靈活的替換具體的實現類。

爲何 Dubbo 不用 JDK 的 SPI，而是要本身實現?

問這個問題就是看你有沒有深刻的瞭解，或者本身思考過，不是死板的看源碼，或者看一些知識點。

不少點是要思考的，不是書上說什麼就是什麼，你要知道這樣作的理由，有什麼好處和壞處，這很容易看出一我的是死記硬背仍是有本身的思考。

答：由於 Java SPI 在查找擴展實現類的時候遍歷 SPI 的配置文件而且將實現類所有實例化，假設一個實現類初始化過程比較消耗資源且耗時，可是你的代碼裏面又用不上它，這就產生了資源的浪費。

所以 Dubbo 就本身實現了一個 SPI，給每一個實現類配了個名字，經過名字去文件裏面找到對應的實現類全限定名而後加載實例化，按需加載。

這答出來就加分了，面試官內心在拍手了，不錯不錯有點東西。

Dubbo 爲何默認用 Javassist

上面你回答 Dubbo 用 Javassist 動態代理，因此極可能會問你爲何要用這個代理，可能還會引伸出 JDK 的動態代理、ASM、CGLIB。

因此這也是個注意點，若是你不太清楚的話上面的回答就不要扯到動態代理了，若是清楚的話那確定得提，來誘導面試官來問你動態代理方面的問題，這很關鍵。

面試官是須要誘導的，畢竟他也想知道你優秀的方面到底有多優秀，你也取長補短，共贏共贏。

來回答下爲何用 Javassist，很簡單，就是快，且字節碼生成方便。

ASM 比 Javassist 更快，可是沒有快一個數量級，而Javassist 只需用字符串拼接就能夠生成字節碼，而 ASM 須要手工生成，成本較高，比較麻煩。

若是讓你設計一個 RPC 框架，如何設計？

面試官都很喜歡問這類問題，來考驗候選人的設計能力，和平日有無全方面的瞭解過一個框架。

若是你平時沒有思考，沒有往這方面想過答出來的東西就會沒有條理性，會顯得雜亂無章，不過你也不用慌張，不用想的很全面，答的很細緻，沒有必要，面試官要的是那些關鍵的重點。

你能夠從底層向上開始提及。

首先須要實現高性能的網絡傳輸，能夠採用 Netty 來實現，不用本身重複造輪子，而後須要自定義協議，畢竟遠程交互都須要遵循必定的協議，而後還須要定義好序列化協議，網絡的傳輸畢竟都是二進制流傳輸的。

而後能夠搞一套描述服務的語言，即 IDL（Interface description language），讓全部的服務都用 IDL 定義，再由框架轉換爲特定編程語言的接口，這樣就能跨語言了。

此時最近基本的功能已經有了，可是隻是最基礎的，工業級的話首先得易用，因此框架須要把上述的細節對使用者進行屏蔽，讓他們感受不到本地調用和遠程調用的區別，因此須要代理實現。

而後還須要實現集羣功能，所以的要服務發現、註冊等功能，因此須要註冊中心，固然細節仍是須要屏蔽的。

最後還須要一個完善的監控機制，埋點上報調用狀況等等，便於運維。

這樣一個 RPC 框架的雛形就差很少了。

最後

Dubbo 系列就到此結束了，其實仍是有不少細節的，若是要寫確定仍是有不少能夠寫的。

不過總體脈絡都理清楚了，以後的修行仍是得靠你們本身多多努力。

面試題確定不止這一些，面試題是問不完的，真實的面試確定是抓住你回答的點來深挖，因此我也模擬不了，我只能告訴你大體關鍵點，和揣摩一下面試官的心理活動。

當面試官問你的時候你能夠試着去揣摩，看看他到底想要問什麼，這很關鍵。

面試的時候不要慌，你和麪試官是平等的，並且面試官不必定你厲害，還有面試有時候就是看運氣了，面試失敗了也不要氣餒，換一家就行了，有時候就是氣場不和，這很正常。

加油。