Dubbo學習導圖

同時可以這個知乎專欄，裡面是更多Java進階技術交流和學習資源分享以及大佬面經分享！

java架構技術交流?

zhuanlan.zhihu.com圖標

一.Dubbo是什麼？

Dubbo 是一個分散式、高性能、透明化的 RPC 服務框架，提供服務自動註冊、自動發現等高效服務治理方案， 可以和 Spring框架無縫集成。

二..Dubbo支持分散式事務嗎？

目前暫時不支持，後續可能採用基於 JTA/XA 規範實現，如以圖所示。

三.Dubbo的主要應用場景？

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

軟負載均衡及容錯機制，可在內網替代F5等硬體負載均衡器，降低成本，減少單點。服務自動註冊與發現，不再需要寫死服務提供方地址，註冊中心基於介面名查詢服務提供者的IP地址，並且能夠平滑添加或刪除服務提供者。

四.Dubbo的核心功能？

主要就是如下3個核心功能：

1.Remoting：網路通信框架，提供對多種NIO框架抽象封裝，包括「同步轉非同步」和「請求-響應」模式的信息交換方式。2.Cluster：服務框架，提供基於介面方法的透明遠程過程調用，包括多協議支持，以及軟負載均衡，失敗容錯，地址路由，動態配置等集群支持。3.Registry：服務註冊，基於註冊中心目錄服務，使服務消費方能動態的查找服務提供方，使地址透明，使服務提供方可以平滑增加或減少機器。

五.Dubbo的核心組件？

六.Dubbo服務註冊與發現的流程？

流程說明：

1.Provider(提供者)綁定指定埠並啟動服務

2.指供者連接註冊中心，並發本機IP、埠、應用信息和提供服務信息發送至註冊中心存儲3.Consumer(消費者），連接註冊中心 ，並發送應用信息、所求服務信息至註冊中心4.註冊中心根據 消費 者所求服務信息匹配對應的提供者列表發送至Consumer 應用緩存。5.Consumer 在發起遠程調用時基於緩存的消費者列表擇其一發起調用。6.Provider 狀態變更會實時通知註冊中心、在由註冊中心實時推送至Consumer

設計的原因：

1.Consumer 與Provider 解偶，雙方都可以橫向增減節點數。

2.註冊中心對本身可做對等集群，可動態增減節點，並且任意一台宕掉後，將自動切換到另一台

3.去中心化，雙方不直接依懶註冊中心，即使註冊中心全部宕機短時間內也不會影響服務的調用

4.服務提供者無狀態，任意一台宕掉後，不影響使用

七.Dubbo的架構設計？

Dubbo框架設計一共劃分了10個層：

1.服務介面層（Service）：該層是與實際業務邏輯相關的，根據服務提供方和服務消費方的業務設計對應的介面和實現。

2.配置層（Config）：對外配置介面，以ServiceConfig和ReferenceConfig為中心。3.服務代理層（Proxy）：服務介面透明代理，生成服務的客戶端Stub和伺服器端Skeleton。4.服務註冊層（Registry）：封裝服務地址的註冊與發現，以服務URL為中心。5.集群層（Cluster）：封裝多個提供者的路由及負載均衡，並橋接註冊中心，以Invoker為中心。

6.監控層（Monitor）：RPC調用次數和調用時間監控。

7.遠程調用層（Protocol）：封將RPC調用，以Invocation和Result為中心，擴展介面為Protocol、Invoker和Exporter。10.信息交換層（Exchange）：封裝請求響應模式，同步轉非同步，以Request和Response為中心。11.網路傳輸層（Transport）：抽象mina和netty為統一介面，以Message為中心。

八.Dubbo的服務調用流程？

九.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： 基於memcached實現的RPC協議redis： 基於redis實現的RPC協議

十.dubbo推薦用什麼協議？

默認使用dubbo協議

十一.Dubbo有些哪些註冊中心？

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

Zookeeper註冊中心： 基於分散式協調系統Zookeeper實現，採用Zookeeper的watch機制實現數據變更；redis註冊中心： 基於redis實現，採用key/Map存儲，住key存儲服務名和類型，Map中key存儲服務URL，value服務過期時間。基於redis的發布/訂閱模式通知數據變更；Simple註冊中心

十二.Dubbo默認採用註冊中心？

採用Zookeeper

十三.為什麼需要服務治理？

過多的服務URL配置困難

負載均衡分配節點壓力過大的情況下也需要部署集群服務依賴混亂，啟動順序不清晰過多服務導致性能指標分析難度較大，需要監控

十四.Dubbo的註冊中心集群掛掉，發布者和訂閱者之間還能通信么？

可以的，啟動dubbo時，消費者會從zookeeper拉取註冊的生產者的地址介面等數據，緩存在本地。

每次調用時，按照本地存儲的地址進行調用。

十五.Dubbo與Spring的關係？

Dubbo採用全Spring配置方式，透明化接入應用，對應用沒有任何API侵入，只需用Spring載入Dubbo的配置即可，Dubbo基於Spring的Schema擴展進行載入。

十六.Dubbo使用的是什麼通信框架?

默認使用NIO Netty框架

十七.Dubbo集群提供了哪些負載均衡策略？

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

RoundRobin LoadBalance: 輪循選取提供者策略，平均分布，但是存在請求累積的問題；

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

ConstantHash LoadBalance: 一致性Hash策略，使相同參數請求總是發到同一提供者，一台機器宕機，可以基於虛擬節點，分攤至其他提供者，避免引起提供者的劇烈變動；預設時為Random隨機調用

十八.Dubbo的集群容錯方案有哪些？

Failover Cluster

失敗自動切換，當出現失敗，重試其它伺服器。通常用於讀操作，但重試會帶來更長延遲。Failfast Cluster快速失敗，只發起一次調用，失敗立即報錯。通常用於非冪等性的寫操作，比如新增記錄。Failsafe Cluster失敗安全，出現異常時，直接忽略。通常用於寫入審計日誌等操作。Failback Cluster

失敗自動恢復，後台記錄失敗請求，定時重發。通常用於消息通知操作。

Forking Cluster並行調用多個伺服器，只要一個成功即返回。通常用於實時性要求較高的讀操作，但需要浪費更多服務資源。可通過 forks="2" 來設置最大並行數。Broadcast Cluster廣播調用所有提供者，逐個調用，任意一台報錯則報錯 。通常用於通知所有提供者更新緩存或日誌等本地資源信息。

十九.Dubbo的默認集群容錯方案？

Failover Cluster

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

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

二十一.Dubbo超時時間怎樣設置？

Dubbo超時時間設置有兩種方式：

服務提供者端設置超時時間，在Dubbo的用戶文檔中，推薦如果能在服務端多配置就盡量多配置，因為服務提供者比消費者更清楚自己提供的服務特性。服務消費者端設置超時時間，如果在消費者端設置了超時時間，以消費者端為主，即優先順序更高。因為服務調用方設置超時時間控制性更靈活。如果消費方超時，服務端線程不會定製，會產生警告。

二十二.服務調用超時問題怎麼解決？

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

二十三.Dubbo在安全機制方面是如何解決？

Dubbo通過Token令牌防止用戶繞過註冊中心直連，然後在註冊中心上管理授權。Dubbo還提供服務黑白名單，來控制服務所允許的調用方。

二十四.Dubbo 和 Dubbox 之間的區別？

dubbox 基於 dubbo 上做了一些擴展，如加了服務可 restful 調用，更新了開源組件等。

二十五.Dubbo和Spring Cloud的關係？

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

二十六.Dubbo和Spring Cloud的區別？

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

而SpringCloud是基於Http協議+Rest介面調用遠程過程的通信，相對來說，Http請求會有更大的報文，占的帶寬也會更多。但是REST相比RPC更為靈活，服務提供方和調用方的依賴只依靠一紙契約，不存在代碼級別的強依賴。

二十七.Dubbo服務之間的調用是阻塞的嗎？

默認是同步等待結果阻塞的，支持非同步調用。

Dubbo 是基於 NIO 的非阻塞實現並行調用，客戶端不需要啟動多線程即可完成並行調用多個遠程服務，相對多線程開銷較小，非同步調用會返回一個 Future 對象。非同步調用流程圖如下。

最後

讀到這的朋友如果文章對您有用，可以點贊支持下，同時可以關注我，以後也會分享更多精彩文章乾貨及學習分享！

讀者福利（學習分享）

對於很多初級Java工程師而言，想要提升技能，往往是自己摸索成長，不成體系的學習效果低效漫長且無助。整理的這些架構技術希望對Java開發的朋友們有所參考以及少走彎路，本文的重點是你有沒有收穫與成長，其餘的都不重要，希望讀者們能謹記這一點。同時我經過多年的收藏目前也算收集到了一套完整的學習資料以及高清詳細的Java架構進階學習導圖及筆記免費分享給大家，希望對想成為架構師的朋友有一定的參考和幫助！

下面是部分資料截圖，誠意滿滿：特別適合有1-5年開發經驗的Java程序員們學習。

這些資料整理也花費了蠻多時間，覺得不錯的可以點個贊關注支持下以後還會分享更多精選的乾貨！

有需要的朋友可以關注這個知乎專欄獲取資料免費領取方式！（記得看簡介哦）

java架構技術交流?

zhuanlan.zhihu.com圖標

更多筆記分享


推薦閱讀：
相关文章