1、Dubbo是什麼？
Dubbo是阿裡巴巴開源的基于 Java 的高性能 RPC 分布式服務架構，現已成為 Apache 基金會孵化項目。
dubbo是一個分布式架構，遠端服務調用的分布式架構，其核心部分包含：
叢集容錯：提供基于接口方法的透明遠端過程調用，包括多協定支援，以及軟負載均衡，失敗容錯，位址路由，動态配置等叢集支援。
遠端通訊：提供對多種長連接配接的NIO架構抽象封裝，包括多種線程模型，序列化，以及“請求-響應”模式的資訊交換方式。
自動發現：基于注冊中心目錄服務，使消費提供方能動态的查找服務提供方，使位址透明，使服務提供方可以平滑增加或減少機器。
2、為什麼要用Dubbo？
因為是阿裡開源項目，國内很多網際網路公司都在用，已經經過很多線上考驗。内部使用了 Netty、Zookeeper，保證了高性能高可用性。
使用 Dubbo 可以将核心業務抽取出來，作為獨立的服務，逐漸形成穩定的服務中心，可用于提高業務複用靈活擴充，使前端應用能更快速的響應多變的市場需求。
透明化的遠端方法調用，就像調用本地方法一樣調用遠端方法，隻需要簡單配置，沒有任何API入侵。軟負載均衡及容錯機制，可以在内網替代F5等硬體負載均衡器。降低成本，減少單點。服務自動注冊與發現，不在需要寫死服務提供方位址，注冊中心基于接口名查詢服務提供者的IP位址，并且能夠平滑添加或删除服務提供者。
3、Dubbo 和 Spring Cloud 有什麼差別？
兩個沒關聯，如果硬要說差別，有以下幾點。
1）通信方式不同
Dubbo 使用的是 RPC 通信，而 Spring Cloud 使用的是 HTTP RESTFul 方式。
2）組成部分不同
4、dubbo都支援什麼協定，推薦用哪種？
- dubbo://（推薦）
- rmi://
- hessian://
- http://
- webservice://
- thrift://
- memcached://
- redis://
- rest://
5、Dubbo需要 Web 容器嗎？
不需要，如果硬要用 Web 容器，隻會增加複雜性，也浪費資源。
6、Dubbo内置了哪幾種服務容器？
- Spring Container
- Jetty Container
- Log4j Container
Dubbo 的服務容器隻是一個簡單的 Main 方法，并加載一個簡單的 Spring 容器，用于暴露服務。
7、Dubbo預設使用什麼注冊中心，還有别的選擇嗎？
推薦使用 Zookeeper 作為注冊中心，還有 Redis、Multicast、Simple 注冊中心，但不推薦。
8、Dubbo有哪幾種配置方式？
- Spring 配置方式
- Java API 配置方式
9、Dubbo啟動時如果依賴的服務不可用會怎樣？
Dubbo 預設會在啟動時檢查依賴的服務是否可用，不可用時會抛出異常，阻止 Spring 初始化完成，預設 check="true"，可以通過 check="false" 關閉檢查。
10、Dubbo支援服務多協定嗎？
Dubbo 允許配置多協定，在不同服務上支援不同協定或者同一服務上同時支援多種協定。
11、當一個服務接口有多種實作時怎麼做？
當一個接口有多種實作時，可以用 group 屬性來分組，服務提供方和消費方都指定同一個 group 即可。
12、Dubbo支援分布式事務嗎？
目前暫時不支援，後續可能采用基于 JTA/XA 規範實作，如以圖所示。
13、Dubbo 能內建 Spring Boot 嗎？
可以的，項目位址如下。
https://github.com/apache/incubator-dubbo-spring-boot-project14.Dubbo的好處？
- 透明化的遠端方法調用，就像調用本地方法一樣調用遠端方法，隻需簡單配置，沒有任何API侵入。
- 軟負載均衡及容錯機制，可在内網替代F5等硬體負載均衡器，降低成本，減少單點。
- 服務自動注冊與發現，不再需要寫死服務提供方位址，注冊中心基于接口名查詢服務提供者的IP位址，并且能夠平滑添加或删除服務提供者。（下面講解）
- Dubbo采用全Spring配置方式，透明化接入應用，對應用沒有任何API侵入，隻需用Spring加載Dubbo的配置即可，Dubbo基于Spring的Schema擴充進行加載。
15.dubbo架構圖如下所示：
講解他的架構圖之前，我們先普及下幾個概念。
節點角色說明：
- Provider（生産者）: 暴露服務的服務提供方。
- Consumer（消費者）: 調用遠端服務的服務消費方。
如圖，我們可以簡單了解為web1234需要調用service1234的服務，是以web1234是消費者，service1234是生産者。
你看着暈不暈？暈不暈？暈不暈？反正我是暈了，萬一分布式得更多呢？，是以我們需要他：
Registry（注冊中心）: 服務注冊與發現的注冊中心。dubbo推薦的是zookeeper。什麼是zookeeper？zookeeper是用于分布式中一緻性處理的架構。簡單的講，zookeeper就是個中介，賣樓的（生産者）把樓盤資訊放在中介（注冊中心）那裡，想買樓的（消費者）去中介那裡獲得樓盤資源清單。于是，我們的圖變成了這樣：
是不是好很多了？還不夠， 我們還需要個監控中心（幹嘛用的？當然是監控用的，調用失敗怎麼辦？挂了怎麼辦？）：Monitor: 統計服務的調用次調和調用時間的監控中心。（不畫圖了）
然後，Provider放在容器裡運作，就叫做Container服務運作容器。（不畫圖了）
最終dubbo架構，如圖（從0開始看起）：
自己腦海裡按照上圖走了一遍後，看看自己想的是不是和下面說明一樣。
- 服務容器負責啟動，加載，運作服務提供者。
- 服務提供者（生産者）在啟動時，向注冊中心注冊自己提供的服務。
- 服務消費者在啟動時，向注冊中心訂閱自己所需的服務。
- 注冊中心傳回服務提供者位址清單給消費者，如果有變更，注冊中心将基于長連接配接推送變更資料給消費者。
- 服務消費者，從提供者位址清單中，基于軟負載均衡算法，選一台提供者進行調用，如果調用失敗，再選另一台調用。
- 服務消費者和提供者，在記憶體中累計調用次數和調用時間，定時每分鐘發送一次統計資料到監控