本文來說下Dubbo核心知識點，也是面試中的重難點。
文章目錄
- Dubbo是什麼
- RPC又是什麼
- 說說Dubbo的分層
- 能說下Dubbo的工作原理嗎
- 為什麼要通過代理對象通信
- 說說服務暴露的流程
- 說說服務引用的流程
- 有哪些負載均衡政策
- 叢集容錯方式有哪些
- 了解 Dubbo SPI 機制嗎
- 說說Dubbo支援哪些協定
- Dubbo中都用到哪些設計模式
- 如果讓你實作一個RPC架構怎麼設計
Dubbo是什麼
Dubbo是一個分布式服務架構，緻力于提供高性能和透明化的RPC遠端服務調用方案，以及SOA服務治理方案。
RPC又是什麼
RPC（Remote Procedure Call）—遠端過程調用，它是一種通過網絡從遠端計算機程式上請求服務，而不需要了解底層網絡技術的協定。RPC協定假定某些傳輸協定的存在，如TCP或UDP，為通信程式之間攜帶資訊資料。在OSI網絡通信模型中，RPC跨越了傳輸層和應用層。RPC使得開發包括網絡分布式多程式在内的應用程式更加容易。RPC采用客戶機/伺服器模式。請求程式就是一個客戶機，而服務提供程式就是一個伺服器。首先，客戶機調用程序發送一個有程序參數的調用資訊到服務程序，然後等待應答資訊。在伺服器端，程序保持睡眠狀态直到調用資訊到達為止。當一個調用資訊到達，伺服器獲得程序參數，計算結果，發送答複資訊，然後等待下一個調用資訊，最後，用戶端調用程序接收答複資訊，獲得程序結果，然後調用執行繼續進行。有多種 RPC模式和執行。
我們用一種通俗易懂的語言解釋它，遠端調用就是本地機器調用遠端機器的一個方法，遠端機器傳回結果的過程。
為什麼要這麼做？
主要原因是由于單台服務的性能已經無法滿足我們了，在這個流量劇增的時代，隻有多台伺服器才能支撐起來現有的使用者體系，
而在這種體系下，服務越來越多，逐漸演化出了現在這種微服務化的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收到請求後對資料進行反序列化，然後通過代理調用具體的接口實作
為什麼要通過代理對象通信
主要是為了實作接口的透明代理，封裝調用細節，讓使用者可以像調用本地方法一樣調用遠端方法，同時還可以通過代理實作一些其他的政策，比如：
1.調用的負載均衡政策
2.調用失敗、逾時、降級和容錯機制
3.做一些過濾操作，比如加入緩存、mock資料
4.接口調用資料統計
說說服務暴露的流程
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。
4.權重輪詢：比如伺服器 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加載對應的實作類，這樣做的好處就是可以按需加載，性能上得到優化。
說說Dubbo支援哪些協定
1.dubbo 單一長連接配接和 NIO 異步通訊，适合大并發小資料量的服務調用，以及消費者遠大于提供者。傳輸協定 TCP，異步，Hessian 序列化
2.rmi 采用 JDK 标準的 rmi 協定實作，傳輸參數和傳回參數對象需要實作Serializable 接口，使用 java 标準序列化機制，使用阻塞式短連接配接，傳輸資料包大小混合，消費者和提供者個數差不多，可傳檔案，傳輸協定 TCP。多個短連接配接，TCP 協定傳輸，同步傳輸，适用正常的遠端服務調用和 rmi 互 操作。在依賴低版本的 Common-Collections 包，java 序列化存在安全漏洞
3.webservice 基于 WebService 的遠端調用協定，內建 CXF 實作，提供和原生 WebService 的互操作。多個短連接配接，基于 HTTP 傳輸，同步傳輸，适用系統內建和跨語言調用；
4.http 基于 Http 表單送出的遠端調用協定，使用 Spring 的 HttpInvoke 實 現。多個短連接配接，傳輸協定 HTTP，傳入參數大小混合，提供者個數多于消 費者，需要給應用程式和浏覽器 JS 調用
5.hessian 內建 Hessian 服務，基于 HTTP 通訊，采用 Servlet 暴露服務，Dubbo 内嵌 Jetty 作為伺服器時預設實作，提供與 Hession 服務互操作。多個短連接配接，同步 HTTP 傳輸，Hessian 序列化，傳入參數較大，提供者大于消費者，提供者壓力較大，可傳檔案；
6.memcache 基于 memcached 實作的 RPC 協定
7.redis 基于 redis 實作的 RPC 協定
Dubbo中都用到哪些設計模式
責任鍊模式:
責任鍊模式在Dubbo中發揮的作用舉足輕重，就像是Dubbo架構的骨架。Dubbo的調用鍊組織是用責任鍊模式串連起來的。責任鍊中的每個節點實作Filter接口，然後由ProtocolFilterWrapper，将所有Filter串連起來。Dubbo的許多功能都是通過Filter擴充實作的，比如監控、日志、緩存、安全、telnet以及RPC本身都是。
觀察者模式
Dubbo中使用觀察者模式最典型的例子是RegistryService。消費者在初始化的時候回調用subscribe方法，注冊一個觀察者，如果觀察者引用的服務位址清單發生改變，就會通過NotifyListener通知消費者。此外，Dubbo的InvokerListener、ExporterListener 也實作了觀察者模式，隻要實作該接口，并注冊，就可以接收到consumer端調用refer和provider端調用export的通知。
修飾器模式
Dubbo中還大量用到了修飾器模式。比如ProtocolFilterWrapper類是對Protocol類的修飾。在export和refer方法中，配合責任鍊模式，把Filter組裝成責任鍊，實作對Protocol功能的修飾。其他還有ProtocolListenerWrapper、 ListenerInvokerWrapper、InvokerWrapper等。
工廠方法模式
CacheFactory的實作采用的是工廠方法模式。CacheFactory接口定義getCache方法，然後定義一個AbstractCacheFactory抽象類實作CacheFactory，并将實際建立cache的createCache方法分離出來，并設定為抽象方法。這樣具體cache的建立工作就留給具體的子類去完成。
抽象工廠模式
ProxyFactory及其子類是Dubbo中使用抽象工廠模式的典型例子。ProxyFactory提供兩個方法，分别用來生産Proxy和Invoker（這兩個方法簽名看起來有些沖突，因為getProxy方法需要傳入一個Invoker對象，而getInvoker方法需要傳入一個Proxy對象，看起來會形成循環依賴，但其實兩個方式使用的場景不一樣）。AbstractProxyFactory實作了ProxyFactory接口，作為具體實作類的抽象父類。然後定義了JdkProxyFactory和JavassistProxyFactory兩個具體類，分别用來生産基于jdk代理機制和基于javassist代理機制的Proxy和Invoker。
擴充卡模式
為了讓使用者根據自己的需求選擇日志元件，Dubbo自定義了自己的Logger接口，并為常見的日志元件（包括jcl, jdk, log4j, slf4j）提供相應的擴充卡。并且利用簡單工廠模式提供一個LoggerFactory，客戶可以建立抽象的Dubbo自定義Logger，而無需關心實際使用的日志元件類型。在LoggerFactory初始化時，客戶通過設定系統變量的方式選擇自己所用的日志元件，這樣提供了很大的靈活性。
代理模式
Dubbo consumer使用Proxy類建立遠端服務的本地代理，本地代理實作和遠端服務一樣的接口，并且屏蔽了網絡通信的細節，使得使用者在使用本地代理的時候，感覺和使用本地服務一樣。
如果讓你實作一個RPC架構怎麼設計
1.首先需要一個服務注冊中心，這樣consumer和provider才能去注冊和訂閱服務
2.需要負載均衡的機制來決定consumer如何調用用戶端，這其中還當然要包含容錯和重試的機制
3.需要通信協定和工具架構，比如通過http或者rmi的協定通信，然後再根據協定選擇使用什麼架構和工具來進行通信，當然，資料的傳輸序列化要考慮
4.除了基本的要素之外，像一些監控、配置管理頁面、日志是額外的優化考慮因素。
那麼，本質上，隻要熟悉一兩個RPC架構，就很容易想明白我們自己要怎麼實作一個RPC架構。
關于這個問題，其實核心考察點就是你對于RPC架構的了解，一個成熟的RPC架構可以完成哪些功能，其實當我們看過一兩個RPC架構後，就可以對這個問題回答個七七八八了，我們來舉個例子。