《我想進大廠》之Dubbo普普統統9問

這是面試專題系列第四篇，Dubbo系列。Dubbo自己並不複雜，並且官方文檔寫的很是清楚詳細，面試中dubbo的問題通常不會不少，從分層到工做原理、負載均衡策略、容錯機制、SPI機制基本就差很少了，最大的一道大題通常就是怎麼設計一個RPC框架了，可是若是你工做原理分層都搞明白了這個問題其實也就至關於回答了不是嗎。

說說Dubbo的分層？

從大的範圍來講，dubbo分爲三層，business業務邏輯層由咱們本身來提供接口和實現還有一些配置信息，RPC層就是真正的RPC調用的核心層，封裝整個RPC的調用過程、負載均衡、集羣容錯、代理，remoting則是對網絡傳輸協議和數據轉換的封裝。

劃分到更細的層面，就是圖中的10層模式，整個分層依賴由上至下，除開business業務邏輯以外，其餘的幾層都是SPI機制。

能說下Dubbo的工做原理嗎？

1. 服務啓動的時候，provider和consumer根據配置信息，鏈接到註冊中心register，分別向註冊中心註冊和訂閱服務
2. register根據服務訂閱關係，返回provider信息到consumer，同時consumer會把provider信息緩存到本地。若是信息有變動，consumer會收到來自register的推送
3. consumer生成代理對象，同時根據負載均衡策略，選擇一臺provider，同時定時向monitor記錄接口的調用次數和時間信息
4. 拿到代理對象以後，consumer經過代理對象發起接口調用
5. provider收到請求後對數據進行反序列化，而後經過代理調用具體的接口實現

爲何要經過代理對象通訊？

主要是爲了實現接口的透明代理，封裝調用細節，讓用戶能夠像調用本地方法同樣調用遠程方法，同時還能夠經過代理實現一些其餘的策略，好比：

一、調用的負載均衡策略

二、調用失敗、超時、降級和容錯機制

三、作一些過濾操做，好比加入緩存、mock數據

四、接口調用數據統計

說說服務暴露的流程？

1. 在容器啓動的時候，經過ServiceConfig解析標籤，建立dubbo標籤解析器來解析dubbo的標籤，容器建立完成以後，觸發ContextRefreshEvent事件回調開始暴露服務
2. 經過ProxyFactory獲取到invoker，invoker包含了須要執行的方法的對象信息和具體的URL地址
3. 再經過DubboProtocol的實現把包裝後的invoker轉換成exporter，而後啓動服務器server，監聽端口
4. 最後RegistryProtocol保存URL地址和invoker的映射關係，同時註冊到服務中心

說說服務引用的流程？

服務暴露以後，客戶端就要引用服務，而後纔是調用的過程。

1. 首先客戶端根據配置文件信息從註冊中心訂閱服務
2. 以後DubboProtocol根據訂閱的獲得provider地址和接口信息鏈接到服務端server，開啓客戶端client，而後建立invoker
3. invoker建立完成以後，經過invoker爲服務接口生成代理對象，這個代理對象用於遠程調用provider，服務的引用就完成了

   

有哪些負載均衡策略？

1. 加權隨機：假設咱們有一組服務器 servers = [A, B, C]，他們對應的權重爲 weights = [5, 3, 2]，權重總和爲10。如今把這些權重值平鋪在一維座標值上，[0, 5) 區間屬於服務器 A，[5, 8) 區間屬於服務器 B，[8, 10) 區間屬於服務器 C。接下來經過隨機數生成器生成一個範圍在 [0, 10) 之間的隨機數，而後計算這個隨機數會落到哪一個區間上就能夠了。
2. 最小活躍數：每一個服務提供者對應一個活躍數 active，初始狀況下，全部服務提供者活躍數均爲0。每收到一個請求，活躍數加1，完成請求後則將活躍數減1。在服務運行一段時間後，性能好的服務提供者處理請求的速度更快，所以活躍數降低的也越快，此時這樣的服務提供者可以優先獲取到新的服務請求。
3. 一致性hash：經過hash算法，把provider的invoke和隨機節點生成hash，並將這個 hash 投射到 [0, 2^32 - 1] 的圓環上，查詢的時候根據key進行md5而後進行hash，獲得第一個節點的值大於等於當前hash的invoker。

1. 加權輪詢：好比服務器 A、B、C 權重比爲 5:2:1，那麼在8次請求中，服務器 A 將收到其中的5次請求，服務器 B 會收到其中的2次請求，服務器 C 則收到其中的1次請求。

集羣容錯方式有哪些？

1. Failover Cluster失敗自動切換：dubbo的默認容錯方案，當調用失敗時自動切換到其餘可用的節點，具體的重試次數和間隔時間可用經過引用服務的時候配置，默認重試次數爲1也就是隻調用一次。
2. Failback Cluster快速失敗：在調用失敗，記錄日誌和調用信息，而後返回空結果給consumer，而且經過定時任務每隔5秒對失敗的調用進行重試
3. Failfast Cluster失敗自動恢復：只會調用一次，失敗後馬上拋出異常
4. Failsafe Cluster失敗安全：調用出現異常，記錄日誌不拋出，返回空結果
5. Forking Cluster並行調用多個服務提供者：經過線程池建立多個線程，併發調用多個provider，結果保存到阻塞隊列，只要有一個provider成功返回告終果，就會馬上返回結果
6. Broadcast Cluster廣播模式：逐個調用每一個provider，若是其中一臺報錯，在循環調用結束後，拋出異常。

瞭解Dubbo SPI機制嗎？

SPI 全稱爲 Service Provider Interface，是一種服務發現機制，本質是將接口實現類的全限定名配置在文件中，並由服務加載器讀取配置文件，加載實現類，這樣能夠在運行時，動態爲接口替換實現類。

Dubbo也正是經過SPI機制實現了衆多的擴展功能，並且dubbo沒有使用java原生的SPI機制，而是對齊進行了加強和改進。

SPI在dubbo應用不少，包括協議擴展、集羣擴展、路由擴展、序列化擴展等等。

使用方式能夠在META-INF/dubbo目錄下配置：

key=com.xxx.value

而後經過dubbo的ExtensionLoader按照指定的key加載對應的實現類，這樣作的好處就是能夠按需加載，性能上獲得優化。

若是讓你實現一個RPC框架怎麼設計？

1. 首先須要一個服務註冊中心，這樣consumer和provider才能去註冊和訂閱服務
2. 須要負載均衡的機制來決定consumer如何調用客戶端，這其中還固然要包含容錯和重試的機制
3. 須要通訊協議和工具框架，好比經過http或者rmi的協議通訊，而後再根據協議選擇使用什麼框架和工具來進行通訊，固然，數據的傳輸序列化要考慮
4. 除了基本的要素以外，像一些監控、配置管理頁面、日誌是額外的優化考慮因素。

那麼，本質上，只要熟悉一兩個RPC框架，就很容易想明白咱們本身要怎麼實現一個RPC框架。