史上超詳細全面30道Dubbo面試筆試題（答案詳解）

Dubbo 支持哪些協議，每種協議的應用場景，優缺點？

dubbo： 單一長鏈接和 NIO 異步通信，適合大併發小數據量的服務調用，以及消費者遠大於提供者。傳輸協議 TCP，異步，Hessian 序列化；

rmi： 採用 JDK 標準的 rmi 協議實現，傳輸參數和返回參數對象須要實現Serializable 接口，使用 java 標準序列化機制，使用阻塞式短鏈接，傳輸數據包大小混合，消費者和提供者個數差很少，可傳文件，傳輸協議 TCP。

多個短鏈接，TCP 協議傳輸，同步傳輸，適用常規的遠程服務調用和 rmi 互操做。在依賴低版本的 Common-Collections 包，java 序列化存在安全漏洞；

webservice： 基於 WebService 的遠程調用協議，集成 CXF 實現，提供和原生 WebService 的互操做。多個短鏈接，基於 HTTP 傳輸，同步傳輸，適用系統集成和跨語言調用；

http： 基於 Http 表單提交的遠程調用協議，使用 Spring 的 HttpInvoke 實現。多個短鏈接，傳輸協議 HTTP，傳入參數大小混合，提供者個數多於消費者，須要給應用程序和瀏覽器 JS 調用；

hessian： 集成 Hessian 服務，基於 HTTP 通信，採用 Servlet 暴露服務，Dubbo 內嵌 Jetty 做爲服務器時默認實現，提供與 Hession 服務互操做。多個短鏈接，同步 HTTP 傳輸，Hessian 序列化，傳入參數較大，提供者大於消費者，提供者壓力較大，可傳文件；

memcache： 基於 memcached 實現的 RPC 協議

redis： 基於 redis 實現的 RPC 協議

一、Dubbo 超時時間怎樣設置？
Dubbo 超時時間設置有兩種方式：

1.服務提供者端設置超時時間，在 Dubbo 的用戶文檔中，推薦若是能在服務端多配置就儘可能多配置，由於服務提供者比消費者更清楚本身提供的服務特性。

1. 服務消費者端設置超時時間，若是在消費者端設置了超時時間，以消費者端爲主，即優先級更高。由於服務調用方設置超時時間控制性更靈活。若是消費方超時，服務端線程不會定製，會產生警告。

二、Dubbo 有些哪些註冊中心？
1.Multicast 註冊中心： Multicast 註冊中心不須要任何中心節點，只要廣播地址，就能進行服務註冊和發現。基於網絡中組播傳輸實現；

1. Zookeeper 註冊中心： 基於分佈式協調系統 Zookeeper 實現，採用Zookeeper 的 watch 機制實現數據變動；

3.redis 註冊中心： 基於 redis 實現，採用 key/Map 存儲，住 key 存儲服務名和類型，Map 中 key 存儲服務 URL，value 服務過時時間。基於 redis 的發佈/訂閱模式通知數據變動；

4.Simple 註冊中心

三、Dubbo 集羣的負載均衡有哪些策略
Dubbo 提供了常見的集羣策略實現，並預擴展點予以自行實現。

1.Random LoadBalance: 隨機選取提供者策略，有利於動態調整提供者權重。截面碰撞率高，調用次數越多，分佈越均勻；

2.RoundRobin LoadBalance: 輪循選取提供者策略，平均分佈，可是存在請求累積的問題；

3.LeastActive LoadBalance: 最少活躍調用策略，解決慢提供者接收更少的請求；

4.ConstantHash LoadBalance: 一致性 Hash 策略，使相同參數請求老是發到同一提供者，一臺機器宕機，能夠基於虛擬節點，分攤至其餘提供者，避免引發提供者的劇烈變更；

四、Dubbo 是什麼？
Dubbo 是一個分佈式、高性能、透明化的 RPC 服務框架，提供服務自動註冊、自動發現等高效服務治理方案， 能夠和Spring 框架無縫集成。

五、Dubbo 的主要應用場景？
1.透明化的遠程方法調用，就像調用本地方法同樣調用遠程方法，只需簡單配置，沒有任何 API 侵入。

2.軟負載均衡及容錯機制，可在內網替代 F5 等硬件負載均衡器，下降成本，減小單點。

3.服務自動註冊與發現，再也不須要寫死服務提供方地址，註冊中心基於接口名查詢服務提供者的 IP 地址，而且可以平滑添加或刪除服務提供者。

六、Dubbo 的核心功能？
主要就是以下 3 個核心功能：

1.Remoting：網絡通訊框架，提供對多種 NIO 框架抽象封裝，包括「同步轉異步」和「請求-響應」模式的信息交換方式。

2.Cluster：服務框架，提供基於接口方法的透明遠程過程調用，包括多協議支持，以及軟負載均衡，失敗容錯，地址路由，動態配置等集羣支持。

3.Registry：服務註冊，基於註冊中心目錄服務，使服務消費方能動態的查找服務提供方，使地址透明，使服務提供方能夠平滑增長或減小機器。

七、Dubbo 的核心組件？

八、Dubbo 服務註冊與發現的流程？

流程說明：

1.Provider(提供者)綁定指定端口並啓動服務

2.指供者鏈接註冊中心，併發本機 IP、端口、應用信息和提供服務信息發送至註冊中心存儲

3.Consumer(消費者），鏈接註冊中心 ，併發送應用信息、所求服務信息至註冊中心

4.註冊中心根據 消費 者所求服務信息匹配對應的提供者列表發送至Consumer 應用緩存。

5.Consumer 在發起遠程調用時基於緩存的消費者列表擇其一發起調用。

6.Provider 狀態變動會實時通知註冊中心、在由註冊中心實時推送至Consumer

設計的緣由：

1.Consumer 與 Provider 解偶，雙方均可以橫向增減節點數。

2.註冊中心對自己可作對等集羣，可動態增減節點，而且任意一臺宕掉後，將自動切換到另外一臺

3.去中心化，雙方不直接依懶註冊中心，即便註冊中心所有宕機短期內也不會影響服務的調用

1. 服務提供者無狀態，任意一臺宕掉後，不影響使用

**九、Dubbo 的架構設計

..]

Dubbo 框架設計一共劃分了 10 個層：

1.服務接口層（Service）：該層是與實際業務邏輯相關的，根據服務提供方和服務消費方的業務設計對應的接口和實現。

2.配置層（Config）：對外配置接口，以 ServiceConfig 和ReferenceConfig 爲中心。

3.服務代理層（Proxy）：服務接口透明代理，生成服務的客戶端 Stub和服務器端 Skeleton。

4.服務註冊層（Registry）：封裝服務地址的註冊與發現，以服務 URL爲中心。

5.集羣層（Cluster）：封裝多個提供者的路由及負載均衡，並橋接註冊中心，以 Invoker 爲中心。

6.監控層（Monitor）：RPC 調用次數和調用時間監控。

7.遠程調用層（Protocol）：封將 RPC 調用，以 Invocation 和 Result爲中心，擴展接口爲 Protocol、Invoker 和 Exporter。

8.信息交換層（Exchange）：封裝請求響應模式，同步轉異步，以Request 和 Response 爲中心。

9.網絡傳輸層（Transport）：抽象 mina 和 netty 爲統一接口，以Message 爲中心。

十、Dubbo 的服務調用流程？

十一、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 協議

1三、Dubbo 有些哪些註冊中心？
1.Multicast 註冊中心： Multicast 註冊中心不須要任何中心節點，只要廣播地址，就能進行服務註冊和發現。基於網絡中組播傳輸實現

2.Zookeeper 註冊中心： 基於分佈式協調系統 Zookeeper 實現，採用Zookeeper 的 watch 機制實現數據變動；

3.redis 註冊中心： 基於 redis 實現，採用 key/Map 存儲，住 key 存儲服務名和類型，Map 中 key 存儲服務 URL，value 服務過時時間。基於 redis 的發佈/訂閱模式通知數據變動；

4.Simple 註冊中心

1四、Dubbo 默認採用註冊中心？
採用 Zookeeper

1五、爲何須要服務治理？

過多的服務 URL 配置困難
負載均衡分配節點壓力過大的狀況下也須要部署集羣
服務依賴混亂，啓動順序不清晰
過多服務致使性能指標分析難度較大，須要監控
1六、Dubbo 的註冊中心集羣掛掉，發佈者和訂閱者之間還能通訊麼？
能夠的，啓動 dubbo 時，消費者會從 zookeeper 拉取註冊的生產者的地址接口等數據，緩存在本地。

每次調用時，按照本地存儲的地址進行調用。

1七、Dubbo 與 Spring 的關係？
Dubbo 採用全 Spring 配置方式，透明化接入應用，對應用沒有任何API 侵入，只需用 Spring 加載 Dubbo 的配置便可，Dubbo 基於Spring 的 Schema 擴展進行加載。

1八、Dubbo 使用的是什麼通訊框架？
默認使用 NIO Netty 框架

1九、Dubbo 集羣提供了哪些負載均衡策略？
1.Random LoadBalance: 隨機選取提供者策略，有利於動態調整提供者權重。截面碰撞率高，調用次數越多，分佈越均勻；

2.RoundRobin LoadBalance: 輪循選取提供者策略，平均分佈，可是存在請求累積的問題；

3.LeastActive LoadBalance: 最少活躍調用策略，解決慢提供者接收更少的請求；

4.ConstantHash LoadBalance: 一致性 Hash 策略，使相同參數請求老是發到同一提供者，一臺機器宕機，能夠基於虛擬節點，分攤至其餘提供者，避免引發提供者的劇烈變更；

缺省時爲 Random 隨機調用

20、Dubbo 的集羣容錯方案有哪些？
1.Failover Cluster

失敗自動切換，當出現失敗，重試其它服務器。一般用於讀操做，但重試會帶來更長延遲。

2.Failfast Cluster

快速失敗，只發起一次調用，失敗當即報錯。一般用於非冪等性的寫操做，好比新增記錄。

3.Failsafe Cluster

失敗安全，出現異常時，直接忽略。一般用於寫入審計日誌等操做。

4.Failback Cluster

失敗自動恢復，後臺記錄失敗請求，定時重發。一般用於消息通知操做。

5.Forking Cluster

並行調用多個服務器，只要一個成功即返回。一般用於實時性要求較高的讀操做，但須要浪費更多服務資源。可經過 forks="2" 來設置最大並行數。

6.Broadcast Cluster

廣播調用全部提供者，逐個調用，任意一臺報錯則報錯 。一般用於通知全部提供者更新緩存或日誌等本地資源信息。

2一、Dubbo 的默認集羣容錯方案？
Failover Cluster

2二、Dubbo 支持哪些序列化方式？
默認使用 Hessian 序列化，還有 Duddo、FastJson、Java 自帶序列化。

2三、Dubbo 超時時間怎樣設置？
Dubbo 超時時間設置有兩種方式：

1.服務提供者端設置超時時間，在 Dubbo 的用戶文檔中，推薦若是能在服務端多配置就儘可能多配置，由於服務提供者比消費者更清楚本身提供的服務特性。

1. 服務消費者端設置超時時間，若是在消費者端設置了超時時間，以消費者端爲主，即優先級更高。由於服務調用方設置超時時間控制性更靈活。若是消費方超時，服務端線程不會定製，會產生警告。

2四、服務調用超時問題怎麼解決？
dubbo 在調用服務不成功時，默認是會重試兩次的。

2五、Dubbo 在安全機制方面是如何解決？
Dubbo 經過 Token 令牌防止用戶繞過註冊中心直連，而後在註冊中心上管理受權。Dubbo 還提供服務黑白名單，來控制服務所容許的調用方。

2六、Dubbo 和 Dubbox 之間的區別？
dubbox 基於 dubbo 上作了一些擴展，如加了服務可 restful 調用，更新了開源組件等。

2七、Dubbo 和 Spring Cloud 的關係？
Dubbo 是 SOA 時代的產物，它的關注點主要在於服務的調用，流量分發、流量監控和熔斷。而 Spring Cloud 誕生於微服務架構時代，考慮的是微服務治理的方方面面，另外因爲依託了 Spirng、Spirng Boot 的優點之上，兩個框架在開始目標就不一致，Dubbo定位服務治理、Spirng Cloud 是一個生態。

2八、Dubbo 和 Spring Cloud 的區別？

最大的區別：Dubbo 底層是使用 Netty 這樣的 NIO 框架，是基於TCP 協議傳輸的，配合以 Hession 序列化完成 RPC 通訊。而 SpringCloud 是基於 Http 協議+Rest 接口調用遠程過程的通訊，相對來講，Http 請求會有更大的報文，佔的帶寬也會更多。可是REST 相比 RPC 更爲靈活，服務提供方和調用方的依賴只依靠一紙契約，不存在代碼級別的強依賴。