Dubbo 支持哪些協(xié)議，每種協(xié)議的應(yīng)用場景，優(yōu)缺點?

• ? dubbo: 單一長連接和 NIO 異步通訊，適合大并發(fā)小數(shù)據(jù)量的服務(wù)調(diào)用， 以及消費者遠(yuǎn)大于提供者。傳輸協(xié)議 TCP，異步，Hessian 序列化;
• ? rmi: 采用 JDK 標(biāo)準(zhǔn)的 rmi 協(xié)議實現(xiàn)，傳輸參數(shù)和返回參數(shù)對象需要實現(xiàn) Serializable 接口，使用 java 標(biāo)準(zhǔn)序列化機制，使用阻塞式短連接，傳輸數(shù) 據(jù)包大小混合，消費者和提供者個數(shù)差不多，可傳文件，傳輸協(xié)議 TCP。 多個短連接，TCP 協(xié)議傳輸，同步傳輸，適用常規(guī)的遠(yuǎn)程服務(wù)調(diào)用和 rmi 互 操作。在依賴低版本的 Common-Collections 包，java 序列化存在安全漏 洞;
• ? webservice: 基于 WebService 的遠(yuǎn)程調(diào)用協(xié)議，集成 CXF 實現(xiàn)，提供和 原生 WebService 的互操作。多個短連接，基于 HTTP 傳輸，同步傳輸，適 用系統(tǒng)集成和跨語言調(diào)用;
• ? http: 基于 Http 表單提交的遠(yuǎn)程調(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ù)器時默認(rèn)實現(xiàn)，提供與 Hession 服務(wù)互操作。多 個短連接，同步 HTTP 傳輸，Hessian 序列化，傳入?yún)?shù)較大，提供者大于 消費者，提供者壓力較大，可傳文件;
• ? memcache: 基于 memcached 實現(xiàn)的 RPC 協(xié)議
• ? redis: 基于 redis 實現(xiàn)的 RPC 協(xié)議

Dubbo 超時時間怎樣設(shè)置?

Dubbo 超時時間設(shè)置有兩種方式:

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

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 注冊中心

Dubbo 和 Dubbox 之間的區(qū)別?

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

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)勢之上，兩個框架在開始目標(biāo)就不一致，Dubbo 定位服務(wù)治理、Spirng Cloud 是一個生態(tài)。 最大的區(qū)別:Dubbo 底層是使用 Netty 這樣的 NIO 框架，是基于 TCP 協(xié)議傳輸?shù)?#xff0c;配合以 Hession 序列化完成 RPC 通信。

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

服務(wù)調(diào)用超時問題怎么解決?

dubbo 在調(diào)用服務(wù)不成功時，默認(rèn)是會重試兩次的。

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

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

Dubbo 超時時間怎樣設(shè)置?

Dubbo 超時時間設(shè)置有兩種方式:

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

Dubbo 的默認(rèn)集群容錯方案?

Failover Cluster

Dubbo 支持哪些序列化方式?

默認(rèn)使用 Hessian 序列化，還有 Duddo、FastJson、Java 自帶序列 化。

總結(jié)

以上是生活随笔為你收集整理的dubbo调用超时回滚_面试必问之Dubbo面试题的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。