1、爲什麼要用 Dubbo？
隨着服務化的進一步發展，服務越來越多，服務之間的調用和依賴關係也越來越複雜，誕生了面向服務的架構體系(SOA)，
也因此衍生出了一系列相應的技術，如對服務提供、服務調用、連接處理、通信協議、序列化方式、服務發現、服務路由、日誌輸出等行爲進行封裝的服務框架。
就這樣爲分佈式系統的服務治理框架就出現了，Dubbo 也就這樣產生了。
2、Dubbo 的整體架構設計有哪些分層?
一共有10層：
接口服務層（Service）：該層與業務邏輯相關，根據 provider 和 consumer 的業務設計對應的接口和實現
配置層（Config）：對外配置接口
服務代理層（Proxy）：服務接口透明代理
服務註冊層（Registry）：封裝服務地址的註冊和發現，以服務 URL 爲中心
路由層（Cluster）：封裝多個提供者的路由和負載均衡
監控層（Monitor）：RPC 調用次數和調用時間監控
遠程調用層（Protocal）：封裝 RPC 調用
信息交換層（Exchange）：封裝請求響應模式
網絡傳輸層（Transport）：抽象 mina 和 netty 爲統一接口，以 Message 爲中心
數據序列化層（Serialize）：可複用的一些工具
3、默認使用的是什麼通信框架，還有別的選擇嗎?
也推薦使用 netty 框架，還有 mina。
4、服務調用是阻塞的嗎？
默認是阻塞的，可以異步調用，沒有返回值的可以這麼做。Dubbo 是基於 NIO 的非阻塞實現並行調用，客戶端不需要啓動多線程即可完成並行調用多個遠程服務，相對多線程開銷較小，異步調用會返回一個 Future 對象。
5、一般使用什麼註冊中心？還有別的選擇嗎？
推薦使用 Zookeeper 作爲註冊中心，還有 Redis、Multicast、Simple 註冊中心，但不推薦
6、默認使用什麼序列化框架，你知道的還有哪些？
推薦使用 Hessian 序列化，還有 Duddo、FastJson、Java 自帶序列化。
7、服務提供者能實現失效踢出是什麼原理？
服務失效踢出基於 zookeeper 的臨時節點原理。
8、如何解決服務調用鏈過長的問題？
可以結合 zipkin 實現分佈式服務追蹤。
9、Dubbo 推薦用什麼協議？
- dubbo://（推薦）
- rmi://
- hessian://
- http://
- webservice://
10、同一個服務多個註冊的情況下可以直連某一個服務嗎？
可以點對點直連，修改配置即可，也可以通過 telnet 直接某個服務
11、畫一畫服務註冊與發現的流程圖？
12、Dubbo 集羣容錯有幾種方案？
Failover Cluster 失敗自動切換，自動重試其它服務器（默認）
Failfast Cluster 快速失敗，立即報錯，只發起一次調用
Failsafe Cluster 失敗安全，出現異常時，直接忽略
Failback Cluster 失敗自動恢復，記錄失敗請求，定時重發
Forking Cluster 並行調用多個服務器，只要一個成功即返回
Broadcast Cluster 廣播逐個調用所有提供者，任意一個報錯則報錯
13、Dubbo 服務降級，失敗重試怎麼做？
可以通過 dubbo:reference 中設置 mock=“return null”。mock 的值也可以修改爲 true，然後再跟接口同一個路徑下實現一個 Mock 類，命名規則是 “接口名稱+Mock” 後綴。然後在 Mock 類裏實現自己的降級邏輯
14、Dubbo 使用過程中都遇到了些什麼問題？
在註冊中心找不到對應的服務,檢查 service 實現類是否添加了@service 註解無法連接到註冊中心,檢查配置文件中的對應的測試 ip 是否正確
15、Dubbo Monitor 實現原理？
Consumer 端在發起調用之前會先走 filter 鏈；provider 端在接收到請求時也是先走 filter 鏈，然後才進行真正的業務邏輯處理。
默認情況下，在 consumer 和 provider 的 filter 鏈中都會有 Monitorfilter。
1、MonitorFilter 向 DubboMonitor 發送數據
2、DubboMonitor 將數據進行聚合後（默認聚合 1min 中的統計數據）暫存到ConcurrentMap<Statistics, AtomicReference> statisticsMap，然後使用一個含有 3 個線程（線程名字：DubboMonitorSendTimer）的線程池每隔 1min 鍾，調用 SimpleMonitorService 遍歷發送 statisticsMap 中的統計數據，每發送完畢一個，就重置當前的 Statistics 的 AtomicReference
3、SimpleMonitorService 將這些聚合數據塞入 BlockingQueue queue 中（隊列大寫爲 100000）
4、SimpleMonitorService 使用一個後臺線程（線程名爲：DubboMonitorAsyncWriteLogThread）將 queue 中的數據寫入文件（該線程以死循環的形式來寫）
5、SimpleMonitorService 還會使用一個含有 1 個線程（線程名字：DubboMonitorTimer）的線程池每隔 5min 鍾，將文件中的統計數據畫成圖表
16、Dubbo 用到哪些設計模式？
Dubbo 框架在初始化和通信過程中使用了多種設計模式，可靈活控制類加載、權限控制等功能。
工廠模式
Provider 在 export 服務時，會調用 ServiceConfig 的 export 方法。ServiceConfig
中有個字段：
private static final Protocol protocol =ExtensionLoader.getExtensionLoader(Protocol.class).getAdaptiveExtension();
Dubbo 裏有很多這種代碼。這也是一種工廠模式，只是實現類的獲取採用了 JDK SPI 的機制。這麼實現的優點是可擴展性強，想要擴展實現，只需要在 classpath下增加個文件就可以了，代碼零侵入。
裝飾器模式
Dubbo 在啓動和調用階段都大量使用了裝飾器模式。以 Provider 提供的調用鏈爲例，具體的調用鏈代碼是在 ProtocolFilterWrapper 的 buildInvokerChain 完成的，具體是將註解中含有 group=provider 的 Filter 實現，按照 order 排序，最後的調用順序是：
EchoFilter -> ClassLoaderFilter -> GenericFilter -> ContextFilter ->ExecuteLimitFilter -> TraceFilter -> TimeoutFilter -> MonitorFilter ->ExceptionFilter
更確切地說，這裏是裝飾器和責任鏈模式的混合使用。例如，EchoFilter 的作用是判斷是否是回聲測試請求，是的話直接返回內容，這是一種責任鏈的體現。而像ClassLoaderFilter 則只是在主功能上添加了功能，更改當前線程的 ClassLoader，這是典型的裝飾器模式。
觀察者模式
Dubbo 的 Provider 啓動時，需要與註冊中心交互，先註冊自己的服務，再訂閱自己的服務，訂閱時，採用了觀察者模式，開啓一個 listener。註冊中心會每 5 秒定時檢查是否有服務更新，如果有更新，向該服務的提供者發送一個 notify 消息，provider 接受到 notify 消息後，即運行 NotifyListener 的 notify 方法，執行監聽器方法。
動態代理模式
Dubbo 擴展 JDK SPI 的類 ExtensionLoader 的 Adaptive 實現是典型的動態代理實現。Dubbo 需要靈活地控制實現類，即在調用階段動態地根據參數決定調用哪個實現類，所以採用先生成代理類的方法，能夠做到靈活的調用。生成代理類的代碼是 ExtensionLoader 的 createAdaptiveExtensionClassCode 方法。代理類的主要邏輯是，獲取 URL 參數中指定參數的值作爲獲取實現類的 key。
17、Dubbo 配置文件是如何加載到 Spring 中的？
Spring 容器在啓動的時候，會讀取到 Spring 默認的一些 schema 以及 Dubbo 自定義的 schema，每個 schema 都會對應一個自己的 NamespaceHandler，NamespaceHandler 裏面通過 BeanDefinitionParser 來解析配置信息並轉化爲需要加載的 bean 對象！
18、Dubbo SPI 和 Java SPI 區別？
JDK SPI
JDK 標準的 SPI 會一次性加載所有的擴展實現，如果有的擴展吃實話很耗時，但也沒用上，很浪費資源。
DUBBO SPI
1，對 Dubbo 進行擴展，不需要改動 Dubbo 的源碼
2，延遲加載，可以一次只加載自己想要加載的擴展實現。
3，增加了對擴展點 IOC 和 AOP 的支持，一個擴展點可以直接 setter 注入其
它擴展點。
3，Dubbo 的擴展機制能很好的支持第三方 IoC 容器，默認支持 Spring Bean。
19、Dubbo 支持分佈式事務嗎？
目前暫時不支持，可與通過zookeeper鎖來實現。
20、Dubbo 可以對結果進行緩存嗎？
爲了提高數據訪問的速度。Dubbo 提供了聲明式緩存，以減少用戶加緩存的工作量，這也是註冊中心掛掉了也能服務的原因
<dubbo:reference cache="true" />
其實比普通的配置文件就多了一個標籤 cache=“true”
21、服務上線怎麼兼容舊版本？
可以用版本號（version）過渡，多個不同版本的服務註冊到註冊中心，版本號不同的服務相互間不引用。這個和服務分組的概念有一點類似。
這也是可以灰度發佈的原因。
22、Dubbo telnet 命令能做什麼？
dubbo 服務發佈之後，我們可以利用 telnet 命令進行調試、管理。Dubbo2.0.5 以上版本服務提供端口支持 telnet 命令
連接服務
telnet localhost 20880 //鍵入回車進入 Dubbo 命令模式。
查看服務列表
dubbo>ls
com.test.TestService
dubbo>ls com.test.TestService
- ls : 顯示服務列表。
- ls -l : 顯示服務詳細信息列表。
- ls XxxService：顯示服務的方法列表。
- ls -l XxxService：顯示服務的方法詳細信息列表。
23、Dubbo 如何優雅停機？
Dubbo 是通過 JDK 的 ShutdownHook 來完成優雅停機的，所以如果使用kill -9 PID 等強制關閉指令，是不會執行優雅停機的，只有通過 kill PID 時，纔會執行優雅停機。
24、Dubbo 和 Dubbox 之間的區別？
Dubbox 是繼 Dubbo 停止維護後，噹噹網基於 Dubbo 做的一個擴展項目，如加了服務可 Restful 調用，更新了開源組件等。
25、Dubbo 和 Spring Cloud 的區別？
| Dubbo | Spring Cloud | |
|---|---|---|
| 服務註冊中心 | Zookeeper | Spring Cloud Netflix Eureka |
| 服務調用方式 | RPC | REST API |
| 服務網關 | 無 | Spring Cloud Netflix Zuul |
| 斷路器 | 不完善 | Spring Cloud Netflix Hystrix |
| 分佈式配置 | 無 | Spring Cloud Config |
| 服務跟蹤 | 無 | Spring Cloud Sleuth |
| 消息總線 | 無 | Spring Cloud Bus |
| 數據流 | 無 | Spring Cloud Stream |
| 批量任務 | 無 | Spring Cloud Task |
使用 Dubbo 構建的微服務架構就像組裝電腦，各環節我們的選擇自由度很高，如果你是一名高手，那這些都不是問題；而 Spring Cloud 就像品牌機，在Spring Source 的整合下，做了大量的兼容性測試，保證了機器擁有更高的穩定性。
26、你還了解別的分佈式框架嗎？
別的還有 spring 的 spring cloud，facebook 的 thrift，twitter 的 finagle 等
27、如果註冊中心集羣都掛掉，發佈者和訂閱者之間還能通信麼？
可以通信的，啓動dubbo時，消費者會從zk拉取註冊的生產者的地址接口等數據，緩存在本地。每次調用時，按照本地存儲的地址進行調用，如果註冊中心服務有變更，註冊中心將基於長連接推送變更數據給消費者。
28、Dubbo在安全機制方面是如何解決的？
Dubbo通過Token令牌防止用戶繞過註冊中心直連，然後在註冊中心上管理授權。Dubbo還提供服務黑白名單，來控制服務所允許的調用方。
29、dubbo協議爲什麼採用單一長連接？
單一：一個消費者和一個提供者之間只有一個連接
長連接：減少連接握手驗證等，
30、dubbo協議爲什麼要消費者比提供者個數多？
一個消費者和一個提供者之間只有一個連接，提供者的網卡爲千兆(1024Mbit=128MByte)，一個連接最多只能有7MByte，所以1個服務提供者可以有128/7=20個連接，所以可以有128/7=20個消費者和提供者相連。
31、dubbo協議爲什麼不能傳大包？
一個消費者和一個提供者之間只有一個連接，數據包傳的太大了，一個能傳的數量就會特別少，而提供者能處理的數據包的數量是很大的，這事網絡就會成爲瓶頸。