Java 200+ 面试题补充③ Dubbo 模块
昨天在我的 Java 面試粉絲群里,有一個只有一年開發(fā)經(jīng)驗的小伙伴只用了三天時間,就找到了一個年薪 20 萬的工作,真是替他感到開心。
他的經(jīng)歷告訴我們:除了加強自我實戰(zhàn)經(jīng)驗之外,還要努力積累自己的理論知識。
人生沒有白走的路,也沒有白吃的苦。你學的某一種知識,在將來某一天一定會給你驚喜!
高興之余,讓我們來看,今天的內(nèi)容。
本文是 Java 最常見的 200+ 面試題 的第三個補充模塊。
第一個補充模塊:面試題補充① ThreadLocal 模塊
第二個補充模塊:面試題補充② Netty 模塊
1.Dubbo 是什么?
Dubbo 是一款高性能、輕量級的開源 RPC 框架,提供服務(wù)自動注冊、自動發(fā)現(xiàn)等高效服務(wù)治理方案, 可以和 Spring 框架無縫集成。
2.Dubbo 的使用場景有哪些?
- 透明化的遠程方法調(diào)用:就像調(diào)用本地方法一樣調(diào)用遠程方法,只需簡單配置,沒有任何API侵入。
- 軟負載均衡及容錯機制:可在內(nèi)網(wǎng)替代 F5 等硬件負載均衡器,降低成本,減少單點。
- 服務(wù)自動注冊與發(fā)現(xiàn):不再需要寫死服務(wù)提供方地址,注冊中心基于接口名查詢服務(wù)提供者的IP地址,并且能夠平滑添加或刪除服務(wù)提供者。
3.Dubbo 核心功能有哪些?
- Remoting:網(wǎng)絡(luò)通信框架,提供對多種NIO框架抽象封裝,包括“同步轉(zhuǎn)異步”和“請求-響應(yīng)”模式的信息交換方式。
- Cluster:服務(wù)框架,提供基于接口方法的透明遠程過程調(diào)用,包括多協(xié)議支持,以及軟負載均衡,失敗容錯,地址路由,動態(tài)配置等集群支持。
- Registry:服務(wù)注冊,基于注冊中心目錄服務(wù),使服務(wù)消費方能動態(tài)的查找服務(wù)提供方,使地址透明,使服務(wù)提供方可以平滑增加或減少機器。
4.Dubbo 核心組件有哪些?
- Provider:暴露服務(wù)的服務(wù)提供方
- Consumer:調(diào)用遠程服務(wù)消費方
- Registry:服務(wù)注冊與發(fā)現(xiàn)注冊中心
- Monitor:監(jiān)控中心和訪問調(diào)用統(tǒng)計
- Container:服務(wù)運行容器
5.Dubbo 服務(wù)器注冊與發(fā)現(xiàn)的流程?
- Provider(提供者)綁定指定端口并啟動服務(wù)。
- 提供者連接注冊中心,并發(fā)本機 IP、端口、應(yīng)用信息和提供服務(wù)信息發(fā)送至注冊中心存儲。
- Consumer(消費者),連接注冊中心 ,并發(fā)送應(yīng)用信息、所求服務(wù)信息至注冊中心。
- 注冊中心根據(jù)消費者所求服務(wù)信息匹配對應(yīng)的提供者列表發(fā)送至 Consumer 應(yīng)用緩存。
- Consumer 在發(fā)起遠程調(diào)用時基于緩存的消費者列表擇其一發(fā)起調(diào)用。
- Provider 狀態(tài)變更會實時通知注冊中心、在由注冊中心實時推送至 Consumer。
6.Dubbo 支持哪些協(xié)議,它們的優(yōu)缺點有哪些?
- Dubbo: 單一長連接和 NIO 異步通訊,適合大并發(fā)小數(shù)據(jù)量的服務(wù)調(diào)用,以及消費者遠大于提供者。傳輸協(xié)議 TCP,異步 Hessian 序列化。
- RMI: 采用 JDK 標準的 RMI 協(xié)議實現(xiàn),傳輸參數(shù)和返回參數(shù)對象需要實現(xiàn) Serializable 接口,使用 Java 標準序列化機制,使用阻塞式短連接,傳輸數(shù)據(jù)包大小混合,消費者和提供者個數(shù)差不多,可傳文件,傳輸協(xié)議 TCP。
多個短連接 TCP 協(xié)議傳輸,同步傳輸,適用常規(guī)的遠程服務(wù)調(diào)用和 RMI 互操作。在依賴低版本的 Common-Collections 包,Java 序列化存在安全漏洞。 - WebService:基于 WebService 的遠程調(diào)用協(xié)議,集成 CXF 實現(xiàn),提供和原生 WebService 的互操作。多個短連接,基于 HTTP 傳輸,同步傳輸,適用系統(tǒng)集成和跨語言調(diào)用。
- HTTP: 基于 Http 表單提交的遠程調(diào)用協(xié)議,使用 Spring 的 HttpInvoke 實現(xiàn)。多個短連接,傳輸協(xié)議 HTTP,傳入?yún)?shù)大小混合,提供者個數(shù)多于消費者,需要給應(yīng)用程序和瀏覽器 JS 調(diào)用。
- Hessian:集成 Hessian 服務(wù),基于 HTTP 通訊,采用 Servlet 暴露服務(wù),Dubbo 內(nèi)嵌 Jetty 作為服務(wù)器時默認實現(xiàn),提供與 Hession 服務(wù)互操作。多個短連接,同步 HTTP 傳輸,Hessian 序列化,傳入?yún)?shù)較大,提供者大于消費者,提供者壓力較大,可傳文件。
- Memcache:基于 Memcache實現(xiàn)的 RPC 協(xié)議。
- Redis:基于 Redis 實現(xiàn)的RPC協(xié)議。
7.Dubbo 推薦什么協(xié)議?
推薦使用 Dubbo 協(xié)議。
8.Dubbo 有哪些注冊中心?
- Multicast 注冊中心:Multicast 注冊中心不需要任何中心節(jié)點,只要廣播地址,就能進行服務(wù)注冊和發(fā)現(xiàn),基于網(wǎng)絡(luò)中組播傳輸實現(xiàn)。
- Zookeeper 注冊中心:基于分布式協(xié)調(diào)系統(tǒng) Zookeeper 實現(xiàn),采用 Zookeeper 的 watch 機制實現(xiàn)數(shù)據(jù)變更。
- Redis 注冊中心:基于 Redis 實現(xiàn),采用 key/map 存儲,住 key 存儲服務(wù)名和類型,map 中 key 存儲服務(wù) url,value 服務(wù)過期時間。基于 Redis 的發(fā)布/訂閱模式通知數(shù)據(jù)變更。
- Simple 注冊中心。
9.Dubbo 的注冊中心集群掛掉,發(fā)布者和訂閱者之間還能通信么?
可以通訊。啟動 Dubbo 時,消費者會從 Zookeeper 拉取注冊的生產(chǎn)者的地址接口等數(shù)據(jù),緩存在本地。每次調(diào)用時,按照本地存儲的地址進行調(diào)用。
10.Dubbo 使用的是什么通信框架?
默認使用 Netty 作為通訊框架。
11.Dubbo集群提供了哪些負載均衡策略?
- Random LoadBalance: 隨機選取提供者策略,有利于動態(tài)調(diào)整提供者權(quán)重。截面碰撞率高,調(diào)用次數(shù)越多,分布越均勻。
- RoundRobin LoadBalance: 輪循選取提供者策略,平均分布,但是存在請求累積的問題。
- LeastActive LoadBalance: 最少活躍調(diào)用策略,解決慢提供者接收更少的請求。
- ConstantHash LoadBalance: 一致性 Hash 策略,使相同參數(shù)請求總是發(fā)到同一提供者,一臺機器宕機,可以基于虛擬節(jié)點,分攤至其他提供者,避免引起提供者的劇烈變動。
默認為 Random 隨機調(diào)用。
12.Dubbo的集群容錯方案有哪些?
- Failover Cluster:失敗自動切換,當出現(xiàn)失敗,重試其它服務(wù)器。通常用于讀操作,但重試會帶來更長延遲。
- Failfast Cluster:快速失敗,只發(fā)起一次調(diào)用,失敗立即報錯。通常用于非冪等性的寫操作,比如新增記錄。
- Failsafe Cluster:失敗安全,出現(xiàn)異常時,直接忽略。通常用于寫入審計日志等操作。
- Failback Cluster:失敗自動恢復(fù),后臺記錄失敗請求,定時重發(fā)。通常用于消息通知操作。
- Forking Cluster:并行調(diào)用多個服務(wù)器,只要一個成功即返回。通常用于實時性要求較高的讀操作,但需要浪費更多服務(wù)資源。可通過 forks=”2″ 來設(shè)置最大并行數(shù)。
- Broadcast Cluster:廣播調(diào)用所有提供者,逐個調(diào)用,任意一臺報錯則報錯 。通常用于通知所有提供者更新緩存或日志等本地資源信息。
默認的容錯方案是 Failover Cluster。
13.Dubbo 支持哪些序列化方式?
默認使用 Hessian 序列化,還有 Duddo、FastJson、Java 自帶序列化。
14.Dubbo 超時設(shè)置有哪些方式?
Dubbo 超時設(shè)置有兩種方式:
- 服務(wù)提供者端設(shè)置超時時間,在Dubbo的用戶文檔中,推薦如果能在服務(wù)端多配置就盡量多配置,因為服務(wù)提供者比消費者更清楚自己提供的服務(wù)特性。
- 服務(wù)消費者端設(shè)置超時時間,如果在消費者端設(shè)置了超時時間,以消費者端為主,即優(yōu)先級更高。因為服務(wù)調(diào)用方設(shè)置超時時間控制性更靈活。如果消費方超時,服務(wù)端線程不會定制,會產(chǎn)生警告。
15.服務(wù)調(diào)用超時會怎么樣?
dubbo 在調(diào)用服務(wù)不成功時,默認是會重試兩次。
16.Dubbo 在安全方面有哪些措施?
- Dubbo 通過 Token 令牌防止用戶繞過注冊中心直連,然后在注冊中心上管理授權(quán)。
- Dubbo 還提供服務(wù)黑白名單,來控制服務(wù)所允許的調(diào)用方。
17.Dubbo 類似的分布式框架還有哪些?
比較著名的就是 Spring Cloud。
18.Dubbo 和 Spring Cloud 有什么關(guān)系?
Dubbo 是 SOA 時代的產(chǎn)物,它的關(guān)注點主要在于服務(wù)的調(diào)用,流量分發(fā)、流量監(jiān)控和熔斷。而 Spring Cloud
誕生于微服務(wù)架構(gòu)時代,考慮的是微服務(wù)治理的方方面面,另外由于依托了 Spirng、Spirng Boot
的優(yōu)勢之上,兩個框架在開始目標就不一致,Dubbo 定位服務(wù)治理、Spirng Cloud 是打造一個生態(tài)。
19.Dubbo 和 Spring Cloud 有什么哪些區(qū)別?
Dubbo 底層是使用 Netty 這樣的 NIO 框架,是基于 TCP 協(xié)議傳輸?shù)?#xff0c;配合以 Hession 序列化完成 RPC 通信。
Spring Cloud 是基于 Http 協(xié)議 Rest 接口調(diào)用遠程過程的通信,相對來說 Http 請求會有更大的報文,占的帶寬也會更多。但是 REST 相比 RPC 更為靈活,服務(wù)提供方和調(diào)用方的依賴只依靠一紙契約,不存在代碼級別的強依賴,這在強調(diào)快速演化的微服務(wù)環(huán)境下,顯得更為合適,至于注重通信速度還是方便靈活性,具體情況具體考慮。
最后
關(guān)于更多 Dubbo 的信息,訪問官網(wǎng):http://dubbo.incubator.apache.org/zh-cn/
查看所有面試題:Java 最常見的 200+ 面試題
參考文章
http://youzhixueyuan.com/dubbo-interview-question-answers.html
近期熱文推薦
Java 最常見的 200+ 面試題
你真的懂 == 和 equals 的區(qū)別嗎?
程序員精美簡歷Top榜—面試必備
程序員專屬精美簡歷合集—第二彈
總結(jié)
以上是生活随笔為你收集整理的Java 200+ 面试题补充③ Dubbo 模块的全部內(nèi)容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: 「视频版」当线程池溢出之后,程序会奔溃吗
- 下一篇: Java中的13个原子操作类