# 前言 Dubbo是一個分散式服務框架，致力於提供高效能和透明化的RPC遠端服務呼叫方案，以及SOA服務治理方案。簡單的說，dubbo就是個服務框架，如果沒有分散式的需求，其實是不需要用的，只有在分散式的時候，才有dubbo這樣的分散式服務框架的需求，並且本質上是個服務呼叫的東東，說白了就是個遠端服務呼叫的分散式框架（告別Web Service模式中的WSdl，以服務者與消費者的方式在dubbo上註冊）。  很多時候，其實我們使用這個技術的時候，可能都是因為專案需要，所以，我們就用了，但是，至於為什麼我們需要用到這個技術，可能自身並不是很瞭解的，但是，其實瞭解技術的來由及背景知識，對於理解一項技術還是有幫助的。 關於Dubbo的知識總結了個思維導圖  # Dubbo 面試題 > 1、為什麼要用 Dubbo？ > > 2、Dubbo 的整體架構設計有哪些分層? > > 3、預設使用的是什麼通訊框架，還有別的選擇嗎? > > 4、服務呼叫是阻塞的嗎？ > > 5、一般使用什麼註冊中心？還有別的選擇嗎？ > > 6、預設使用什麼序列化框架，你知道的還有哪些？ > > 7、服務提供者能實現失效踢出是什麼原理？ > > 8、服務上線怎麼不影響舊版本？ > > 9、如何解決服務呼叫鏈過長的問題？ > > 10、說說核心的配置有哪些？ > > 11、Dubbo 推薦用什麼協議？ > > 12、同一個服務多個註冊的情況下可以直連某一個服務嗎？ > > 13、畫一畫服務註冊與發現的流程圖？ > > 14、Dubbo 叢集容錯有幾種方案？ > > 15、Dubbo 服務降級，失敗重試怎麼做？ > > 16、Dubbo 使用過程中都遇到了些什麼問題？ > > 17、Dubbo Monitor 實現原理？ > > 18、Dubbo 用到哪些設計模式？ > > 19、Dubbo 配置檔案是如何載入到 Spring 中的？ > > 20、Dubbo SPI 和 Java SPI 區別？ > > 21、Dubbo 支援分散式事務嗎？ > > 22、Dubbo 可以對結果進行快取嗎？ > > 23、服務上線怎麼相容舊版本？ > > 24、Dubbo 必須依賴的包有哪些？ > > 25、Dubbo telnet 命令能做什麼？ > > 26、Dubbo 支援服務降級嗎？ > > 27、Dubbo 如何優雅停機？ > > 28、Dubbo 和 Dubbox 之間的區別？ > > 29、Dubbo 和 Spring Cloud 的區別？ > > 30、你還了解別的分散式框架嗎？  **下面是Dubbo 面試題答案解析** # 1、為什麼要用 Dubbo？ 隨著服務化的進一步發展，服務越來越多，服務之間的呼叫和依賴關係也越來越複雜，誕生了面向服務的架構體系(SOA)，也因此衍生出了一系列相應的技術，如對服務提供、服務呼叫、連線處理、通訊協議、序列化方式、服務發現、服務路由、日誌輸出等行為進行封裝的服務框架。就這樣為分散式系統的服務治理框架就出現了，Dubbo 也就這樣產生了。 # 2、Dubbo 的整體架構設計有哪些分層? > 介面服務層（Service）：該層與業務邏輯相關，根據 provider 和 consumer 的業務設計對應的介面和實現 > > 配置層（Config）：對外配置介面，以 ServiceConfig 和 ReferenceConfig 為中心 > > 服務代理層（Proxy）：服務介面透明代理，生成服務的客戶端 Stub 和 服務端的 Skeleton，以 ServiceProxy 為中心，擴充套件介面為 ProxyFactory > > 服務註冊層（Registry）：封裝服務地址的註冊和發現，以服務 URL 為中心，擴充套件介面為 RegistryFactory、Registry、RegistryService > > 路由層（Cluster）：封裝多個提供者的路由和負載均衡，並橋接註冊中心，以Invoker 為中心，擴充套件介面為 Cluster、Directory、Router 和 LoadBlancce > > 監控層（Monitor）：RPC 呼叫次數和呼叫時間監控，以 Statistics 為中心，擴充套件介面為 MonitorFactory、Monitor 和 MonitorService > > 遠端呼叫層（Protocal）：封裝 RPC 呼叫，以 Invocation 和 Result 為中心，擴充套件介面為 Protocal、Invoker 和 Exporter > > 資訊交換層（Exchange）：封裝請求響應模式，同步轉非同步。以 Request 和Response 為中心，擴充套件介面為 Exchanger、ExchangeChannel、ExchangeClient 和 ExchangeServer > > 網路 傳輸 層（Transport）：抽象 mina 和 netty 為統一介面，以 Message 為中心，擴充套件介面為 Channel、Transporter、Client、Server 和 Codec > > 資料序列化層（Serialize）：可複用的一些工具，擴充套件介面為 Serialization、ObjectInput、ObjectOutput 和 ThreadPool # 3、預設使用的是什麼通訊框架，還有別的選擇嗎? 預設也推薦使用 netty 框架，還有 mina。 # 4、服務呼叫是阻塞的嗎？ 預設是阻塞的，可以非同步呼叫，沒有返回值的可以這麼做。Dubbo 是基於 NIO 的非阻塞實現並行呼叫，客戶端不需要啟動多執行緒即可完成並行呼叫多個遠端服務，相對多執行緒開銷較小，非同步呼叫會返回一個 Future 物件。 # 5、一般使用什麼註冊中心？還有別的選擇嗎？ 推薦使用 Zookeeper 作為註冊中心，還有 Redis、Multicast、Simple 註冊中心，但不推薦。 # 6、預設使用什麼序列化框架，你知道的還有哪些？ 推薦使用 Hessian 序列化，還有 Duddo、FastJson、Java 自帶序列化。 # 7、服務提供者能實現失效踢出是什麼原理？ 服務失效踢出基於 zookeeper 的臨時節點原理。 # 8、服務上線怎麼不影響舊版本？ 採用多版本開發，不影響舊版本。 # 9、如何解決服務呼叫鏈過長的問題？ 可以結合 zipkin 實現分散式服務追蹤。 # 10、說說核心的配置有哪些？  # 11、Dubbo 推薦用什麼協議？  # 12、同一個服務多個註冊的情況下可以直連某一個服務嗎？ 可以點對點直連，修改配置即可，也可以通過 telnet 直接某個服務。 # 13、畫一畫服務註冊與發現的流程圖？  14、Dubbo 叢集容錯有幾種方案？  ## 15、Dubbo 服務降級，失敗重試怎麼做？ 可以通過 dubbo:reference 中設定 mock="return null"。mock 的值也可以修改為 true，然後再跟介面同一個路徑下實現一個 Mock 類，命名規則是 “介面名稱+Mock” 字尾。然後在 Mock 類裡實現自己的降級邏輯 ## 16、Dubbo 使用過程中都遇到了些什麼問題？ 在註冊中心找不到對應的服務,檢查 service 實現類是否添加了@service 註解無法連線到註冊中心,檢查配置檔案中的對應的測試 ip 是否正確 ## 17、Dubbo Monitor 實現原理？ Consumer 端在發起呼叫之前會先走 filter 鏈；provider 端在接收到請求時也是先走 filter 鏈，然後才進行真正的業務邏輯處理。預設情況下，在 consumer 和 provider 的 filter 鏈中都會有 Monitorfilter。 1. MonitorFilter 向 DubboMonitor 傳送資料 2. DubboMonitor 將資料進行聚合後（預設聚合 1min 中的統計資料）暫存到Concu