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

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

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

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

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

Dubbo 有些哪些注冊中心？

• Multicast 注冊中心： Multicast 注冊中心不需要任何中心節(jié)點(diǎn)，只要廣播地址，就能進(jìn)行服務(wù)注冊和發(fā)現(xiàn)?；诰W(wǎng)絡(luò)中組播傳輸實(shí)現(xiàn)；
• Zookeeper 注冊中心： 基于分布式協(xié)調(diào)系Zookeeper 實(shí)現(xiàn)，采用Zookeeper 的 watch 機(jī)制實(shí)現(xiàn)數(shù)據(jù)變更；
• redis 注冊中心： 基于 redis 實(shí)現(xiàn)，采用 key/Map 存儲，住 key 存儲服務(wù)名和類型，Map 中 key 存儲服務(wù) URL，value 服務(wù)過期時(shí)間?；?redis 的發(fā)布/訂閱模式通知數(shù)據(jù)變更；
• Simple 注冊中心

Dubbo 集群的負(fù)載均衡有哪些策略

Dubbo 提供了常見的集群策略實(shí)現(xiàn)，并預(yù)擴(kuò)展點(diǎn)予以自行實(shí)現(xiàn)。

• Random LoadBalance: 隨機(jī)選取提供者策略，有利于動(dòng)態(tài)調(diào)整提供者權(quán)重。截面碰撞率高，調(diào)用次數(shù)越多，分布越均勻；
• RoundRobin LoadBalance: 輪循選取提供者策略，平均分布，但是存在請求累積的問題；
• LeastActive LoadBalance: 最少活躍調(diào)用策略，解決慢提供者接收更少的請求；
• ConstantHash LoadBalance: 一致性 Hash 策略，使相同參數(shù)請求總是發(fā)到同一提供者，一臺機(jī)器宕機(jī)，可以基于虛擬節(jié)點(diǎn)，分?jǐn)傊疗渌峁┱撸苊庖鹛峁┱叩膭×易儎?dòng)；

Dubbo 是什么？

• Dubbo 是一個(gè)分布式、高性能、透明化的 RPC 服務(wù)框架，提供服務(wù)自動(dòng)注冊、自動(dòng)發(fā)現(xiàn)等高效服務(wù)治理方案， 可以和Spring 框架無縫集成。

Dubbo 的主要應(yīng)用場景？

• 透明化的遠(yuǎn)程方法調(diào)用，就像調(diào)用本地方法一樣調(diào)用遠(yuǎn)程方法，只需簡單配置，沒有任何 API 侵入。
• 軟負(fù)載均衡及容錯(cuò)機(jī)制，可在內(nèi)網(wǎng)替代 F5 等硬件負(fù)載均衡器，降低成本，減少單點(diǎn)。
• 服務(wù)自動(dòng)注冊與發(fā)現(xiàn)，不再需要寫死服務(wù)提供方地址，注冊中心基于接口名查詢服務(wù)提供者的 IP 地址，并且能夠平滑添加或刪除服務(wù)提供者。

Dubbo 的核心功能？

主要就是如下 3 個(gè)核心功能：

• Remoting：網(wǎng)絡(luò)通信框架，提供對多種 NIO 框架抽象封裝，包括“同步轉(zhuǎn)異步”和“請求-響應(yīng)”模式的信息交換方式。
• Cluster：服務(wù)框架，提供基于接口方法的透明遠(yuǎn)程過程調(diào)用，包括多協(xié)議支持，以及軟負(fù)載均衡，失敗容錯(cuò)，地址路由，動(dòng)態(tài)配置等集群支持。
• Registry：服務(wù)注冊，基于注冊中心目錄服務(wù)，使服務(wù)消費(fèi)方能動(dòng)態(tài)的查找服務(wù)提供方，使地址透明，使服務(wù)提供方可以平滑增加或減少機(jī)器。

Dubbo 的核心組件？

Dubbo 服務(wù)注冊與發(fā)現(xiàn)的流程？

image.png

流程說明：

• Provider(提供者)綁定指定端口并啟動(dòng)服務(wù)
• 指供者連接注冊中心，并發(fā)本機(jī) IP、端口、應(yīng)用信息和提供服務(wù)信息發(fā)送至注冊中心存儲
• Consumer(消費(fèi)者），連接注冊中心 ，并發(fā)送應(yīng)用信息、所求服務(wù)信息至注冊中心
• 注冊中心根據(jù) 消費(fèi) 者所求服務(wù)信息匹配對應(yīng)的提供者列表發(fā)送至Consumer 應(yīng)用緩存。
• Consumer 在發(fā)起遠(yuǎn)程調(diào)用時(shí)基于緩存的消費(fèi)者列表擇其一發(fā)起調(diào)用。
• Provider 狀態(tài)變更會(huì)實(shí)時(shí)通知注冊中心、在由注冊中心實(shí)時(shí)推送至Consumer

設(shè)計(jì)的原因：

• Consumer 與 Provider 解偶，雙方都可以橫向增減節(jié)點(diǎn)數(shù)。
• 注冊中心對本身可做對等集群，可動(dòng)態(tài)增減節(jié)點(diǎn)，并且任意一臺宕掉后，將自動(dòng)切換到另一臺
• 去中心化，雙方不直接依懶注冊中心，即使注冊中心全部宕機(jī)短時(shí)間內(nèi)也不會(huì)影響服務(wù)的調(diào)用

• 服務(wù)提供者無狀態(tài)，任意一臺宕掉后，不影響使用

  
  
  image.png

Dubbo 的架構(gòu)設(shè)計(jì)？

image.png

Dubbo 框架設(shè)計(jì)一共劃分了 10 個(gè)層：

• 服務(wù)接口層（Service）：該層是與實(shí)際業(yè)務(wù)邏輯相關(guān)的，根據(jù)服務(wù)提供方和服務(wù)消費(fèi)方的業(yè)務(wù)設(shè)計(jì)對應(yīng)的接口和實(shí)現(xiàn)。
• 配置層（Config）：對外配置接口，以 ServiceConfig 和ReferenceConfig 為中心。
• 服務(wù)代理層（Proxy）：服務(wù)接口透明代理，生成服務(wù)的客戶端 Stub和服務(wù)器端 Skeleton。
• 服務(wù)注冊層（Registry）：封裝服務(wù)地址的注冊與發(fā)現(xiàn)，以服務(wù) URL為中心。
• 集群層（Cluster）：封裝多個(gè)提供者的路由及負(fù)載均衡，并橋接注冊中心，以 Invoker 為中心。
• 監(jiān)控層（Monitor）：RPC 調(diào)用次數(shù)和調(diào)用時(shí)間監(jiān)控。
• 遠(yuǎn)程調(diào)用層（Protocol）：封將 RPC 調(diào)用，以Invocation 和 Result為中心，擴(kuò)展接口為 Protocol、Invoker 和 Exporter。
• 信息交換層（Exchange）：封裝請求響應(yīng)模式，同步轉(zhuǎn)異步，以Request 和 Response 為中心。
• 網(wǎng)絡(luò)傳輸層（Transport）：抽象 mina 和 netty 為統(tǒng)一接口，以Message 為中心。

Dubbo 的服務(wù)調(diào)用流程？

image.png

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

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

dubbo 推薦用什么協(xié)議？

默認(rèn)使用 dubbo 協(xié)議

Dubbo 有些哪些注冊中心？

• Multicast 注冊中心： Multicast 注冊中心不需要任何中心節(jié)點(diǎn)，只要廣播地址，就能進(jìn)行服務(wù)注冊和發(fā)現(xiàn)?；诰W(wǎng)絡(luò)中組播傳輸實(shí)現(xiàn)；
• Zookeeper 注冊中心： 基于分布式協(xié)調(diào)系統(tǒng)Zookeeper 實(shí)現(xiàn)，采用Zookeeper 的 watch 機(jī)制實(shí)現(xiàn)數(shù)據(jù)變更；
• redis 注冊中心： 基于 redis 實(shí)現(xiàn)，采用 key/Map 存儲，住 key 存儲服務(wù)名和類型，Map 中 key 存儲服務(wù) URL，value 服務(wù)過期時(shí)間?；?redis 的發(fā)布/訂閱模式通知數(shù)據(jù)變更；
• Simple 注冊中心

Dubbo 默認(rèn)采用注冊中心？

采用 Zookeeper

為什么需要服務(wù)治理？

image.png

• 過多的服務(wù) URL 配置困難
• 負(fù)載均衡分配節(jié)點(diǎn)壓力過大的情況下也需要部署集群
• 服務(wù)依賴混亂，啟動(dòng)順序不清晰
• 過多服務(wù)導(dǎo)致性能指標(biāo)分析難度較大，需要監(jiān)控

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

可以的，啟動(dòng) dubbo 時(shí)，消費(fèi)者會(huì)從 zookeeper 拉取注冊的生產(chǎn)者的地址接口等數(shù)據(jù)，緩存在本地。
每次調(diào)用時(shí)，按照本地存儲的地址進(jìn)行調(diào)用。

Dubbo 與 Spring 的關(guān)系？

Dubbo 采用全 Spring 配置方式，透明化接入應(yīng)用，對應(yīng)用沒有任何
API 侵入，只需用 Spring 加載 Dubbo 的配置即可，Dubbo 基于Spring 的 Schema 擴(kuò)展進(jìn)行加載。

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

默認(rèn)使用 NIO Netty 框架

Dubbo 集群提供了哪些負(fù)載均衡策略？

• Random LoadBalance: 隨機(jī)選取提供者策略，有利于動(dòng)態(tài)調(diào)整提供者權(quán)重。截面碰撞率高，調(diào)用次數(shù)越多，分布越均勻；
• RoundRobin LoadBalance: 輪循選取提供者策略，平均分布，但是存在請求累積的問題；
• LeastActive LoadBalance: 最少活躍調(diào)用策略，解決慢提供者接收更少的請求；
• ConstantHash LoadBalance: 一致性 Hash 策略，使相同參數(shù)請求總是發(fā)到同一提供者，一臺機(jī)器宕機(jī)，可以基于虛擬節(jié)點(diǎn)，分?jǐn)傊疗渌峁┱?，避免引起提供者的劇烈變?dòng)；
  缺省時(shí)為 Random 隨機(jī)調(diào)用

Dubbo 的集群容錯(cuò)方案有哪些？

• Failover Cluster
• 失敗自動(dòng)切換，當(dāng)出現(xiàn)失敗，重試其它服務(wù)器。通常用于讀操作，但重試會(huì)帶來更長延遲。
• Failfast Cluster
• 快速失敗，只發(fā)起一次調(diào)用，失敗立即報(bào)錯(cuò)。通常用于非冪等性的寫操作，比如新增記錄。
• Failsafe Cluster
• 失敗安全，出現(xiàn)異常時(shí)，直接忽略。通常用于寫入審計(jì)日志等操作。
• Failback Cluster
• 失敗自動(dòng)恢復(fù)，后臺記錄失敗請求，定時(shí)重發(fā)。通常用于消息通知操作。
• Forking Cluster
• 并行調(diào)用多個(gè)服務(wù)器，只要一個(gè)成功即返回。通常用于實(shí)時(shí)性要求較高的讀操作，但需要浪費(fèi)更多服務(wù)資源。可通過 forks="2" 來設(shè)置最大并行數(shù)。
• Broadcast Cluster
• 廣播調(diào)用所有提供者，逐個(gè)調(diào)用，任意一臺報(bào)錯(cuò)則報(bào)錯(cuò) 。通常用于通知所有提供者更新緩存或日志等本地資源信息。

Dubbo 的默認(rèn)集群容錯(cuò)方案？

Failover Cluster

Dubbo 支持哪些序列化方式？

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

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

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

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

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

dubbo 在調(diào)用服務(wù)不成功時(shí)，默認(rèn)是會(huì)重試兩次的。
Dubbo 在安全機(jī)制方面是如何解決？
Dubbo 通過 Token 令牌防止用戶繞過注冊中心直連，然后在注冊中心上管理授權(quán)。Dubbo 還提供服務(wù)黑白名單，來控制服務(wù)所允許的調(diào)用方。

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

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

Dubbo 和 Spring Cloud 的關(guān)系？

Dubbo 是 SOA 時(shí)代的產(chǎn)物，它的關(guān)注點(diǎn)主要在于服務(wù)的調(diào)用，流量分發(fā)、流量監(jiān)控和熔斷。而 Spring Cloud 誕生于微服務(wù)架構(gòu)時(shí)代，考慮的是微服務(wù)治理的方方面面，另外由于依托了 Spirng、Spirng Boot 的優(yōu)勢之上，兩個(gè)框架在開始目標(biāo)就不一致，Dubbo定位服務(wù)治理、Spirng Cloud 是一個(gè)生態(tài)。

Dubbo 和 Spring Cloud 的區(qū)別？

image.png

最大的區(qū)別：Dubbo 底層是使用 Netty 這樣的 NIO 框架，是基于TCP 協(xié)議傳輸?shù)?，配合?Hession 序列化完成 RPC 通信。
而 SpringCloud 是基于 Http 協(xié)議+Rest 接口調(diào)用遠(yuǎn)程過程的通信，相對來說，Http 請求會(huì)有更大的報(bào)文，占的帶寬也會(huì)更多。但是REST 相比 RPC 更為靈活，服務(wù)提供方和調(diào)用方的依賴只依靠一紙契約，不存在代碼級別的強(qiáng)依賴。