Dubbo原理是什么？動力節(jié)點小編來為大家解答。Dubbo 框架是用來處理分布式系統(tǒng)中，服務(wù)發(fā)現(xiàn)與注冊以及調(diào)用問題的，并且管理調(diào)用過程。

工作流程：

服務(wù)提供者在啟動的時候，會通過讀取一些配置將服務(wù)實例化。

Proxy 封裝服務(wù)調(diào)用接口，方便調(diào)用者調(diào)用。客戶端獲取 Proxy 時，可以像調(diào)用本地服務(wù)一樣，調(diào)用遠程服務(wù)。

Proxy 在封裝時，需要調(diào)用 Protocol 定義協(xié)議格式，例如：Dubbo Protocol。

將 Proxy 封裝成 Invoker，它是真實服務(wù)調(diào)用的實例。

將 Invoker 轉(zhuǎn)化成 Exporter，Exporter 只是把 Invoker包裝了一層，是為了在注冊中心中暴露自己，方便消費者使用。

將包裝好的 Exporter 注冊到注冊中心。

服務(wù)消費者建立好實例，會到服務(wù)注冊中心訂閱服務(wù)提供者的元數(shù)據(jù)。元數(shù)據(jù)包括服務(wù) IP 和端口以及調(diào)用方式(Proxy)。

消費者會通過獲取的 Proxy 進行調(diào)用。通過服務(wù)提供方包裝過程可以知道，Proxy 實際包裝了 Invoker 實體，因此需要使用Invoker 進行調(diào)用。

在 Invoker 調(diào)用之前，通過 Directory 獲取服務(wù)提供者的 Invoker列表。在分布式的服務(wù)中有可能出現(xiàn)同一個服務(wù)，分布在不同的節(jié)點上。

通過路由規(guī)則了解，服務(wù)需要從哪些節(jié)點獲取。

Invoker 調(diào)用過程中，通過 Cluster 進行容錯，如果遇到失敗策略進行重試。

調(diào)用中，由于多個服務(wù)可能會分布到不同的節(jié)點，就要通過 LoadBalance 來實現(xiàn)負載均衡。

Invoker 調(diào)用之前還需要經(jīng)過 Filter，它是一個過濾鏈，用來處理上下文，限流和計數(shù)的工作。

生成過濾以后的 Invoker。

用 Client 進行數(shù)據(jù)傳輸。

Codec 會根據(jù) Protocol 定義的協(xié)議，進行協(xié)議的構(gòu)造。

構(gòu)造完成的數(shù)據(jù)，通過序列化 Serialization 傳輸給服務(wù)提供者。

Request 已經(jīng)到達了服務(wù)提供者，它會被分配到線程池(ThreadPool)中進行處理。

Server 拿到請求以后查找對應(yīng)的 Exporter(包含有 Invoker)。

由于 Export 也會被 Filter 層層包裹

通過 Filter 以后獲得 Invoker

最后，對服務(wù)提供者實體進行調(diào)用。

各個部分整體機制

1.提供者暴露服務(wù)的整體機制：

在服務(wù)提供者初始化的時候，會通過 Config 組件中的 ServiceConfig 讀取服務(wù)的配置信息。這個配置信息有三種形式，分別是 XML 文件，注解(Annoation)和屬性文件(Properties 和 yaml)。

在讀取配置文件生成服務(wù)實體以后，會通過 ProxyFactory 將 Proxy 轉(zhuǎn)換成 Invoker。

此時，Invoker 會被定義 Protocol，之后會被包裝成 Exporter。

最后，Exporter 會發(fā)送到注冊中心，作為服務(wù)的注冊信息

2.注冊中心

其主要作用如下：

動態(tài)載入服務(wù)

動態(tài)發(fā)現(xiàn)服務(wù)

參數(shù)動態(tài)調(diào)整

服務(wù)統(tǒng)一配置管理

提供者(Provider)啟動時，會向注冊中心寫入自己的元數(shù)據(jù)信息(調(diào)用方式)。

消費者(Consumer)啟動時，也會在注冊中心寫入自己的元數(shù)據(jù)信息，并且訂閱服務(wù)提供者，路由和配置元數(shù)據(jù)的信息。

服務(wù)治理中心(duubo-admin)啟動時，會同時訂閱所有消費者，提供者，路由和配置元數(shù)據(jù)的信息。

當(dāng)提供者離開或者新提供者加入時，注冊中心發(fā)現(xiàn)變化會通知消費者和服務(wù)治理中心。

Dubbo 有四種注冊中心的實現(xiàn)，分別是 ZooKeeper，Redis，Simple 和 Multicast。

ZooKeeper 是負責(zé)協(xié)調(diào)服務(wù)式應(yīng)用的。通過樹形文件存儲的 ZNode 在 /dubbo/Service 目錄下面建立了四個目錄，分別是：

Providers 目錄下面，存放服務(wù)提供者 URL 和元數(shù)據(jù)。

Consumers 目錄下面，存放消費者的 URL 和元數(shù)據(jù)。

Routers 目錄下面，存放消費者的路由策略。

Configurators 目錄下面，存放多個用于服務(wù)提供者動態(tài)配置 URL 元數(shù)據(jù)信息。

客戶端第一次連接注冊中心的時候，會獲取全量的服務(wù)元數(shù)據(jù)，包括服務(wù)提供者和服務(wù)消費者以及路由和配置的信息。

根據(jù) ZooKeeper 客戶端的特性，會在對應(yīng) ZNode 的目錄上注冊一個 Watcher，同時讓客戶端和注冊中心保持 TCP 長連接。

如果服務(wù)的元數(shù)據(jù)信息發(fā)生變化，客戶端會接受到變更通知，然后去注冊中心更新元數(shù)據(jù)信息。變更時根據(jù) ZNode 節(jié)點中版本變化進行。

3.服務(wù)消費者

服務(wù)消費者首先持有遠程服務(wù)實例生成的 Invoker，然后把 Invoker 轉(zhuǎn)換成用戶接口的動態(tài)代理引用，服務(wù)引用的入口點在 ReferenceBean

4.Dubbo 集群容錯

分布式服務(wù)多以集群形式出現(xiàn)，在消費服務(wù)發(fā)起調(diào)用的時候，會涉及到 Cluster，Directory，Router，LoadBalance 幾個核心組件。

cluster生成 Invoker 對象后就獲取可調(diào)用的服務(wù)列表，在 Directory 獲取所有 Invoker 列表之后，會調(diào)用路由接口(Router)。其會根據(jù)用戶配置的不同策略對 Invoker 列表進行過濾，只返回符合規(guī)則的 Invoker。生成的 Invoker服務(wù)有可能分布在不同的節(jié)點上面。所以，需要經(jīng)過 LoadBalance。

5.Dubbo 遠程調(diào)用

服務(wù)消費者經(jīng)過容錯，Invoker 列表，路由和負載均衡以后，會對 Invoker 進行過濾，之后通過 Client 編碼，序列化發(fā)給服務(wù)提供者。

以上就是關(guān)于“Dubbo原理和機制詳解”的介紹，大家如果對此比較感興趣，想了解更多相關(guān)知識，可以關(guān)注一下動力節(jié)點的Dubbo教程，里面的課程內(nèi)容由淺到深，很適合沒有基礎(chǔ)的小伙伴學(xué)習(xí)，希望對大家能夠有所幫助。