Dubbo元數(shù)據(jù)中心是什么

這篇文章主要介紹“Dubbo元數(shù)據(jù)中心是什么”，在日常操作中，相信很多人在Dubbo元數(shù)據(jù)中心是什么問題上存在疑惑，小編查閱了各式資料，整理出簡單好用的操作方法，希望對大家解答”Dubbo元數(shù)據(jù)中心是什么”的疑惑有所幫助！接下來，請跟著小編一起來學(xué)習(xí)吧！

前言

如果讓你在本地構(gòu)建一個 Dubbo 應(yīng)用，你會需要額外搭建哪些中間件呢？如果沒猜錯的話，你的第一反應(yīng)應(yīng)該是注冊中心，類 Dubbo 的大多數(shù)服務(wù)治理框架都有注冊中心的概念。你可以部署一個 Zookeeper，或者一個 Nacos，看你的喜好。但在 Apache Dubbo 的 2.7 版本后，額外引入了兩個中間件：元數(shù)據(jù)中心和配置中心。

在今年年初 Dubbo 2.7 剛發(fā)布時，我就寫了一篇文章 《Dubbo 2.7 三大新特性詳解》，介紹了包含元數(shù)據(jù)中心改造在內(nèi)的三大新特性，但一些細(xì)節(jié)介紹沒有詳細(xì)呈現(xiàn)出來，在這篇文章中，我將會以 Dubbo 為例，跟大家一起探討一下服務(wù)治理框架中元數(shù)據(jù)中心的意義與集成細(xì)節(jié)。

元數(shù)據(jù)中心介紹

服務(wù)治理中的元數(shù)據(jù)（Metadata）指的是服務(wù)分組、服務(wù)版本、服務(wù)名、方法列表、方法參數(shù)列表、超時時間等，這些信息將會存儲在元數(shù)據(jù)中心之中。與元數(shù)據(jù)平起平坐的一個概念是服務(wù)的注冊信息，即：服務(wù)分組、服務(wù)版本、服務(wù)名、地址列表等，這些信息將會存儲在注冊中心中。稍微一對比可以發(fā)現(xiàn)，元數(shù)據(jù)中心和注冊中心存儲了一部分共同的服務(wù)信息，例如服務(wù)名。兩者也有差異性，元數(shù)據(jù)中心還會存儲方法列表即參數(shù)列表，注冊中心存儲了服務(wù)地址。上述的概述，體現(xiàn)出了元數(shù)據(jù)中心和注冊中心在服務(wù)治理過程中，擔(dān)任著不同的角色。為了有一個直觀的對比，我整理出了下面的表格：

下面我會對每個對比點進行單獨分析，以加深對元數(shù)據(jù)中心的理解。

職責(zé)

在 Dubbo 2.7 版本之前，并沒有元數(shù)據(jù)中心的概念，那時候注冊信息和元數(shù)據(jù)都耦合在一起。Dubbo Provider 的服務(wù)配置有接近 30 個配置項，排除一部分注冊中心服務(wù)治理需要的參數(shù)，很大一部分配置項僅僅是 Provider 自己使用，不需要透傳給消費者；Dubbo Consumer 也有 20 多個配置項。在注冊中心之中，服務(wù)消費者列表中只需要關(guān)注 application，version，group，ip，dubbo 版本等少量配置。這部分?jǐn)?shù)據(jù)不需要進入注冊中心，而只需要以 key-value 形式持久化存儲在元數(shù)據(jù)中心即可。從職責(zé)來看，將不同職責(zé)的數(shù)據(jù)存儲在對應(yīng)的組件中，會使得邏輯更加清晰。

變化頻繁度

注冊信息和元數(shù)據(jù)耦合在一起會導(dǎo)致注冊中心數(shù)據(jù)量的膨脹，進而增大注冊中心的網(wǎng)絡(luò)開銷，直接造成了服務(wù)地址推送慢等負(fù)面影響。服務(wù)上下線會隨時發(fā)生，變化的其實是注冊信息，元數(shù)據(jù)是相對不變的。

數(shù)據(jù)量

由于元數(shù)據(jù)包含了服務(wù)的方法列表以及參數(shù)列表，這部分?jǐn)?shù)據(jù)會導(dǎo)致元數(shù)據(jù)要比注冊信息大很多。注冊信息被設(shè)計得精簡會直接直接影響到服務(wù)推送的 SLA。

數(shù)據(jù)交互/存儲模型

注冊中心采用的是 PubSub 模型，這屬于大家的共識，所以注冊中心組件的選型一般都會要求其有 notify 的機制。而元數(shù)據(jù)中心并沒有 notify 的訴求，一般只需要組件能夠提供 key-value 的存儲結(jié)構(gòu)即可。

主要使用場景

在服務(wù)治理中，注冊中心充當(dāng)了通訊錄的職責(zé)，在復(fù)雜的分布式場景下，讓消費者能找到提供者。而元數(shù)據(jù)中心存儲的元數(shù)據(jù)，主要適用于服務(wù)測試、服務(wù) MOCK 等場景，這些場景都對方法列表、參數(shù)列表有所訴求。在下面的小節(jié)中，我也會對使用場景進行更加詳細(xì)的介紹。

可用性要求

注冊中心宕機或者網(wǎng)絡(luò)不通會直接影響到服務(wù)的可用性，它影響了服務(wù)調(diào)用的主路徑。但一般而言，元數(shù)據(jù)中心出現(xiàn)問題，不會影響到服務(wù)調(diào)用，它提供的能力是可被降級的。這也闡釋了一點，為什么很多用戶在 Dubbo 2.7 中沒有配置元數(shù)據(jù)中心，也沒有影響到正常的使用。元數(shù)據(jù)中心在服務(wù)治理中扮演的是錦上添花的一個角色。在組件選型時，我們一般也會對注冊中心的可用性要求比較高，元數(shù)據(jù)中心則可以放寬要求。

元數(shù)據(jù)中心的價值

小孩子才分對錯，成年人只看利弊。額外引入一個元數(shù)據(jù)中心，必然帶來運維成本、理解成本、遷移成本等問題，那么它具備怎樣的價值，來說服大家選擇它呢？上面我們介紹元數(shù)據(jù)中心時已經(jīng)提到了服務(wù)測試、服務(wù) MOCK 等場景，這一節(jié)我們重點探討一下元數(shù)據(jù)中心的價值。

降低地址推送的時延

由于注冊中心采用的是 PubSub 模型，數(shù)據(jù)量的大小會直接影響到服務(wù)地址推送時間，不知道你有沒有遇到過 No provider available 的報錯呢？明明提供者已經(jīng)啟動了，但由于注冊中心推送慢會導(dǎo)致很多問題，一方面會影響到服務(wù)的可用性，一方面也會增加排查問題的難度。

在一次杭州 Dubbo Meetup 中，網(wǎng)易考拉分享了他們對 Zookeeper 的改造，根源就是

推送量大 -> 存儲數(shù)據(jù)量大 -> 網(wǎng)絡(luò)傳輸量大 -> 延遲嚴(yán)重

這一實際案例佐證了元數(shù)據(jù)改造并不是憑空產(chǎn)生的需求，而是切實解決了一個痛點。

服務(wù)測試 & 服務(wù) MOCK

在 Dubbo 2.7 之前，雖然注冊中心耦合存儲了不少本應(yīng)屬于元數(shù)據(jù)的數(shù)據(jù)，但也漏掉了一部分元數(shù)據(jù)，例如服務(wù)的方法列表，參數(shù)列表。這些是服務(wù)測試和服務(wù) MOCK 必備的數(shù)據(jù)，想要使用這些能力，就必須引入元數(shù)據(jù)中心。例如開源的 Dubbo Admin 就實現(xiàn)了服務(wù)測試功能，用戶可以在控制臺上對已經(jīng)發(fā)布的服務(wù)提供者進行功能測試?？赡苣阒坝羞^這樣的疑惑：為什么只有 Dubbo 2.7 才支持了服務(wù)測試呢？啊哈，原因就是 Dubbo 2.7 才有了元數(shù)據(jù)中心的概念。當(dāng)然，服務(wù) MOCK 也是如此。

其他場景

可以這么理解，任何依賴元數(shù)據(jù)的功能，都需要元數(shù)據(jù)中心的支持。其他場景還包括了網(wǎng)關(guān)應(yīng)用獲取元數(shù)據(jù)來進行泛化調(diào)用、服務(wù)自動化測試等等。再描述一個可能的場景，拋磚引玉。在一次南京 Dubbo Meetup 上，dubbo.js 的作者提及的一個場景，希望根據(jù)元數(shù)據(jù)自動生成 NodeJs 代碼，以簡化前端的開發(fā)量，也是元數(shù)據(jù)的作用之一。這里就需要發(fā)揮各位的想象力了

Dubbo 配置元數(shù)據(jù)中心

目前 Dubbo 最新的版本為 2.7.4，目前支持的幾種元數(shù)據(jù)中心可以從源碼中得知（官方文檔尚未更新）：

支持 consul、etcd、nacos、redis、zookeeper 這五種組件。

配置方式如下：

dubbo.metadata-report.address=nacos://127.0.0.1:8848

元數(shù)據(jù)存儲格式剖析

前面我們介紹了元數(shù)據(jù)中心的由來以及價值，還是飄在天上的概念，這一節(jié)將會讓概念落地。元數(shù)據(jù)是以怎么樣一個格式存儲的呢？

以 DemoService 服務(wù)為例：

<dubbo:service interface="com.alibaba.dubbo.demo.DemoService" ref="demoService" executes="4500" retries="7" owner="kirito"/>
<dubbo:registry address="zookeeper://127.0.0.1:2181" />

首先觀察在 Dubbo 2.6.x 中，注冊中心如何存儲這個服務(wù)的信息：

dubbo://30.5.120.185:20880/com.alibaba.dubbo.demo.DemoService?
anyhost=true&
application=demo-provider&
interface=com.alibaba.dubbo.demo.DemoService&
methods=sayHello&
bean.name=com.alibaba.dubbo.demo.DemoService&
dubbo=2.0.2&executes=4500&
generic=false&owner=kirito&
pid=84228&retries=7&side=provider&timestamp=1552965771067

例如 bean.name 和 owner 這些屬性，肯定是沒必要注冊上來的。

接著，我們在 Dubbo 2.7 中使用最佳實踐，為 registry 配置 simplified=true：

<dubbo:service interface="com.alibaba.dubbo.demo.DemoService" ref="demoService" executes="4500" retries="7" owner="kirito"/>
<dubbo:registry address="zookeeper://127.0.0.1:2181" simplified="true" />
<dubbo:metadata-report address="nacos://127.0.0.1:8848"/>

之后再觀察注冊中心的數(shù)據(jù)，已經(jīng)變得相當(dāng)精簡了：

dubbo://30.5.120.185:20880/org.apache.dubbo.demo.api.DemoService?
application=demo-provider&
dubbo=2.0.2&
release=2.7.0&
timestamp=1552975501873

被精簡省略的數(shù)據(jù)不代表沒有用了，而是轉(zhuǎn)移到了元數(shù)據(jù)中心之中，我們觀察一下此時元數(shù)據(jù)中心中的數(shù)據(jù)：

最佳實踐

元數(shù)據(jù)中心是服務(wù)治理中的一個關(guān)鍵組件，但對于大多數(shù)用戶來說還是一個比較新的概念，我整理了一些我認(rèn)為的最佳實踐，分享給大家。

• 從 Dubbo 2.6 遷移到 Dubbo 2.7 時，可以采取三步走的策略來平滑遷移元數(shù)據(jù)。第一步：Dubbo 2.6 + 注冊中心，第二步：Dubbo 2.7 + 注冊中心 + 元數(shù)據(jù)中心，第三步：Dubbo 2.7 + 注冊中心（simplified=true） + 元數(shù)據(jù)中心。在未來 Dubbo 的升級版本中，registry 的 simplified 默認(rèn)值將會變成 true，目前是 false，預(yù)留給用戶一個升級的時間。

• 應(yīng)用在啟動時，會發(fā)布一次元數(shù)據(jù)，在此之后會有定時器，一天同步一次元數(shù)據(jù)，以上報那些運行時生成的 Bean，目前用戶不可以配置元數(shù)據(jù)上報的周期，但可以通過 -Dcycle.report 關(guān)閉這一定時器。

• 元數(shù)據(jù)中心推薦選型：Nacos 和 Redis。

Dubbo 2.7 還有很多有意思的特性，如果你對 Dubbo 有什么感興趣的問題，歡迎在文末或者后臺進行留言，后面我會繼續(xù)更新 Dubbo 系列的文章。

到此，關(guān)于“Dubbo元數(shù)據(jù)中心是什么”的學(xué)習(xí)就結(jié)束了，希望能夠解決大家的疑惑。理論與實踐的搭配能更好的幫助大家學(xué)習(xí)，快去試試吧！若想繼續(xù)學(xué)習(xí)更多相關(guān)知識，請繼續(xù)關(guān)注億速云網(wǎng)站，小編會繼續(xù)努力為大家?guī)砀鄬嵱玫奈恼拢?/p>