為了賬號安全,請及時綁定郵箱和手機立即綁定

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

2019.03.12 09:23 2720瀏覽

昨天在我的 Java 面試粉絲群里,有一個只有一年開發經驗的小伙伴只用了三天時間,就找到了一個年薪 20 萬的工作,真是替他感到開心。

他的經歷告訴我們:除了加強自我實戰經驗之外,還要努力積累自己的理論知識。

人生沒有白走的路,也沒有白吃的苦。你學的某一種知識,在將來某一天一定會給你驚喜!


高興之余,讓我們來看,今天的內容。

本文是 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 更為靈活,服務提供方和調用方的依賴只依靠一紙契約,不存在代碼級別的強依賴,這在強調快速演化的微服務環境下,顯得更為合適,至于注重通信速度還是方便靈活性,具體情況具體考慮。

最后

關于更多 Dubbo 的信息,訪問官網:http://dubbo.incubator.apache.org/zh-cn/

查看所有面試題:Java 最常見的 200+ 面試題

參考文章

近期熱文推薦

點擊查看更多內容

本文原創發布于慕課網 ,轉載請注明出處,謝謝合作

8人點贊

若覺得本文不錯,就分享一下吧!

評論

相關文章推薦

正在加載中
意見反饋 幫助中心 APP下載
官方微信

舉報

0/150
提交
取消
开奖号码