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 超時時間設置有兩種方式：

? 服務提供者端設置超時時間，在 Dubbo 的用戶文檔中，推薦如果能在服務端多配置就盡量多配置，因為服務提供者比消費者更清楚自己提供的服務特性。

? 服務消費者端設置超時時間，如果在消費者端設置了超時時間，以消費者端為主，即優先級更高。因為服務調用方設置超時時間控制性更靈活。如果消費方超時，服務端線程不會定制，會產生警告。

Dubbo 有些哪些注冊中心？

? Multicast 注冊中心： Multicast 注冊中心不需要任何中心節點，只要廣播地址，就能進行服務注冊和發現。基于網絡中組播傳輸實現；

? Zookeeper 注冊中心： 基于分布式協調系統 Zookeeper 實現，采用

Zookeeper 的 watch 機制實現數據變更；

? redis 注冊中心： 基于 redis 實現，采用 key/Map 存儲，住 key 存儲服務名和類型，Map 中 key 存儲服務 URL，value 服務過期時間。基于 redis 的發布/訂閱模式通知數據變更；

? Simple 注冊中心

Dubbo 集群的負載均衡有哪些策略

Dubbo 提供了常見的集群策略實現，并預擴展點予以自行實現。

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

? RoundRobin LoadBalance: 輪循選取提供者策略，平均分布，但是存在請求累積的問題；

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

? ConstantHash LoadBalance: 一致性 Hash 策略，使相同參數請求總是發到同一提供者，一臺機器宕機，可以基于虛擬節點，分攤至其他提供者，避免引起提供者的劇烈變動；

? Dubbo 是什么？

? Dubbo 是一個分布式、高性能、透明化的 RPC 服務框架，提

供服務自動注冊、自動發現等高效服務治理方案， 可以和

Spring 框架無縫集成。

? Dubbo 的主要應用場景？

? 透明化的遠程方法調用，就像調用本地方法一樣調用遠程方法，

只需簡單配置，沒有任何 API 侵入。

? 軟負載均衡及容錯機制，可在內網替代 F5 等硬件負載均衡器，

降低成本，減少單點。

? 服務自動注冊與發現，不再需要寫死服務提供方地址，注冊中心

基于接口名查詢服務提供者的 IP 地址，并且能夠平滑添加或刪

除服務提供者。

Dubbo 的核心功能？

主要就是如下 3 個核心功能：

§ **Remoting：**網絡通信框架，提供對多種 NIO 框架抽象封裝，包括

“同步轉異步”和“請求-響應”模式的信息交換方式。

§ Cluster：服務框架，提供基于接口方法的透明遠程過程調用，包括多

協議支持，以及軟負載均衡，失敗容錯，地址路由，動態配置等集群

支持。

Registry：服務注冊，基于注冊中心目錄服務，使服務消費方能動態的查找服務提供方，使地址透明，使服務提供方可以平滑增加或減少機器。

Dubbo 的核心組件？

Dubbo 服務注冊與發現的流程？

流程說明：

§ Provider(提供者)綁定指定端口并啟動服務

§ 指供者連接注冊中心，并發本機 IP、端口、應用信息和提供服務信息

發送至注冊中心存儲

§ Consumer(消費者），連接注冊中心 ，并發送應用信息、所求服務信

息至注冊中心

§ 注冊中心根據 消費 者所求服務信息匹配對應的提供者列表發送至

Consumer 應用緩存。

§ Consumer 在發起遠程調用時基于緩存的消費者列表擇其一發起調

用。

Provider 狀態變更會實時通知注冊中心、在由注冊中心實時推送至

Consumer

設計的原因：

• Consumer 與 Provider 解偶，雙方都可以橫向增減節點數。
• 注冊中心對本身可做對等集群，可動態增減節點，并且任意一臺宕掉后，將自動切換到另一臺
• 去中心化，雙方不直接依懶注冊中心，即使注冊中心全部宕機短時間內也不會影響服務的調用
• 服務提供者無狀態，任意一臺宕掉后，不影響使用

Dubbo 的架構設計？

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

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

• 配置層（Config）：對外配置接口，以 ServiceConfig 和ReferenceConfig 為中心。

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

• 服務注冊層（Registry）：封裝服務地址的注冊與發現，以服務 URL為中心。

• 集群層（Cluster）：封裝多個提供者的路由及負載均衡，并橋接注冊中心，以 Invoker 為中心。

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

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

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

• 網絡傳輸層（Transport）：抽象 mina 和 netty 為統一接口，以essage 為中心。

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 協議

Dubbo 有些哪些注冊中心？

• Multicast 注冊中心： Multicast 注冊中心不需要任何中心節點，只要廣播地址，就能進行服務注冊和發現。基于網絡中組播傳輸實現；
• Zookeeper 注冊中心： 基于分布式協調系統 Zookeeper 實現，采用Zookeeper 的 watch 機制實現數據變更；
• redis 注冊中心： 基于 redis 實現，采用 key/Map 存儲，住 key 存儲服務名和類型，Map 中 key 存儲服務 URL，value 服務過期時間。基于 redis 的發布/訂閱模式通知數據變更；
• Simple 注冊中心

Dubbo 默認采用注冊中心？

采用 Zookeeper

為什么需要服務治理？

• 過多的服務 URL 配置困難
• 負載均衡分配節點壓力過大的情況下也需要部署集群服務依賴混亂，啟動順序不清晰
• 過多服務導致性能指標分析難度較大，需要監控

Dubbo 的注冊中心集群掛掉，發布者和訂閱者之間還能通信么？

可以的，啟動 dubbo 時，消費者會從 zookeeper 拉取注冊的生產者的地址接口等數據，緩存在本地。

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

Dubbo 與 Spring 的關系？

Dubbo 采用全 Spring 配置方式，透明化接入應用，對應用沒有任何

API 侵入，只需用 Spring 加載 Dubbo 的配置即可，Dubbo 基于

Spring 的 Schema 擴展進行加載。

Dubbo 使用的是什么通信框架?

默認使用 NIO Netty 框架

Dubbo 集群提供了哪些負載均衡策略？

• Random LoadBalance: 隨機選取提供者策略，有利于動態調整提供者權重。截面碰撞率高，調用次數越多，分布越均勻；
• RoundRobin LoadBalance: 輪循選取提供者策略，平均分布，但是存在請求累積的問題；

LeastActive LoadBalance: 最少活躍調用策略，解決慢提供者接收

更少的請求；

ConstantHash LoadBalance: 一致性 Hash 策略，使相同參數請求總是發到同一提供者，一臺機器宕機，可以基于虛擬節點，分攤至其他提供者，避免引起提供者的劇烈變動；

缺省時為 Random 隨機調用

Dubbo 的集群容錯方案有哪些？

Failover Cluster

失敗自動切換，當出現失敗，重試其它服務器。通常用于讀操作，但

重試會帶來更長延遲。

Failfast Cluster

快速失敗，只發起一次調用，失敗立即報錯。通常用于非冪等性的寫操作，比如新增記錄。

Failsafe Cluster

失敗安全，出現異常時，直接忽略。通常用于寫入審計日志等操作。

Failback Cluster

失敗自動恢復，后臺記錄失敗請求，定時重發。通常用于消息通知操作。

Forking Cluster 并行調用多個服務器，只要一個成功即返回。通常用于實時性要求較高的讀操作，但需要浪費更多服務資源。可通過 forks=“2” 來設置最大并行數。

roadcast Cluster

廣播調用所有提供者，逐個調用，任意一臺報錯則報錯 。通常用于通知所有提供者更新緩存或日志等本地資源信息。

Dubbo 的默認集群容錯方案？

Failover Cluster

Dubbo 支持哪些序列化方式？

默認使用 Hessian 序列化，還有 Duddo、FastJson、Java 自帶序列化。

Dubbo 超時時間怎樣設置？

Dubbo 超時時間設置有兩種方式：

• 服務提供者端設置超時時間，在 Dubbo 的用戶文檔中，推薦如果能在服務端多配置就盡量多配置，因為服務提供者比消費者更清楚自己提供的服務特性。
• 服務消費者端設置超時時間，如果在消費者端設置了超時時間，以消費者端為主，即優先級更高。因為服務調用方設置超時時間控制性更靈活。如果消費方超時，服務端線程不會定制，會產生警告。

服務調用超時問題怎么解決？

dubbo 在調用服務不成功時，默認是會重試兩次的。

Dubbo 在安全機制方面是如何解決？

Dubbo 通過 Token 令牌防止用戶繞過注冊中心直連，然后在注冊中心上管理授權。Dubbo 還提供服務黑白名單，來控制服務所允許的調用方。

Dubbo 和 Dubbox 之間的區別？

dubbox 基于 dubbo 上做了一些擴展，如加了服務可 restful 調用，更新了開源組件等。

Dubbo 和 Spring Cloud 的關系？

Dubbo 是 SOA 時代的產物，它的關注點主要在于服務的調用，流量分發、流量監控和熔斷。而 Spring Cloud 誕生于微服務架構時代，考慮的是微服務治理的方方面面，另外由于依托了 Spirng、

Spirng Boot 的優勢之上，兩個框架在開始目標就不一致，Dubbo 定位服務治理、Spirng Cloud 是一個生態。

Dubbo 和 Spring Cloud 的區別？

最大的區別：Dubbo 底層是使用 Netty 這樣的 NIO 框架，是基于TCP 協議傳輸的，配合以 Hession 序列化完成 RPC 通信。

而 SpringCloud 是基于 Http 協議+Rest 接口調用遠程過程的通信，相對來說，Http 請求會有更大的報文，占的帶寬也會更多。但是REST 相比 RPC 更為靈活，服務提供方和調用方的依賴只依靠一紙契約，不存在代碼級別的強依賴。