Java 200+ 面試題補充③ Dubbo 模塊

今天 Java 面試粉絲羣裏，一個一年開發經驗的小夥伴只用了三天時間，找了一個 13 薪 1.5 萬的工做，真是替他感到開心。

---

高興之餘，讓咱們來看，今天的內容。

本文是 Java 最多見的 200+ 面試題 的第三個補充模塊。

第一個補充模塊：面試題補充① ThreadLocal 模塊

第二個補充模塊：面試題補充② Netty 模塊

1.Dubbo 是什麼？

Dubbo 是一款高性能、輕量級的開源 RPC 框架，提供服務自動註冊、自動發現等高效服務治理方案， 能夠和 Spring 框架無縫集成。

2.Dubbo 的使用場景有哪些？

• 透明化的遠程方法調用：就像調用本地方法同樣調用遠程方法，只需簡單配置，沒有任何API侵入。

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

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

3.Dubbo 核心功能有哪些？

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

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

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

4.Dubbo 核心組件有哪些？

• Provider：暴露服務的服務提供方

• Consumer：調用遠程服務消費方

• Registry：服務註冊與發現註冊中心

• Monitor：監控中心和訪問調用統計

• Container：服務運行容器

5.Dubbo 服務器註冊於發現的流程？

• Provider（提供者）綁定指定端口並啓動服務。

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

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

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

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

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

6.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：基於 Memcache實現的 RPC 協議。

• Redis：基於 Redis 實現的RPC協議。

7.Dubbo 推薦什麼協議？

推薦使用 Dubbo 協議。

8.Dubbo 有哪些註冊中心？

• Multicast 註冊中心：Multicast 註冊中心不須要任何中心節點，只要廣播地址，就能進行服務註冊和發現,基於網絡中組播傳輸實現。

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

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

• Simple 註冊中心。

9.Dubbo 的註冊中心集羣掛掉，發佈者和訂閱者之間還能通訊麼？

能夠通信。啓動 Dubbo 時，消費者會從 Zookeeper 拉取註冊的生產者的地址接口等數據，緩存在本地。每次調用時，按照本地存儲的地址進行調用。

10.Dubbo 使用的是什麼通訊框架?

默認使用 Netty 做爲通信框架。

11.Dubbo集羣提供了哪些負載均衡策略？

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

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

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

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

默認爲 Random 隨機調用。

12.Dubbo的集羣容錯方案有哪些？

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

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

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

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

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

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

默認的容錯方案是 Failover Cluster。

13.Dubbo 支持哪些序列化方式？

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

14.Dubbo 超時設置有哪些方式？

Dubbo 超時設置有兩種方式：

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

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

15.服務調用超時會怎麼樣？

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

16.Dubbo 在安全方面有哪些措施？

• Dubbo 經過 Token 令牌防止用戶繞過註冊中心直連，而後在註冊中心上管理受權。

• Dubbo 還提供服務黑白名單，來控制服務所容許的調用方。

17.Dubbo 相似的分佈式框架還有哪些？

比較著名的就是 Spring Cloud。

18.Dubbo 和 Spring Cloud 有什麼關係？

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

19.Dubbo 和 Spring Cloud 有什麼哪些區別？

Dubbo 底層是使用 Netty 這樣的 NIO 框架，是基於 TCP 協議傳輸的，配合以 Hession 序列化完成 RPC 通訊。

Spring Cloud 是基於 Http 協議 Rest 接口調用遠程過程的通訊，相對來講 Http 請求會有更大的報文，佔的帶寬也會更多。可是 REST 相比 RPC 更爲靈活，服務提供方和調用方的依賴只依靠一紙契約，不存在代碼級別的強依賴，這在強調快速演化的微服務環境下，顯得更爲合適，至於注重通訊速度仍是方便靈活性，具體狀況具體考慮。