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

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

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

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

元數(shù)據(jù)

注冊(cè)信息

職責(zé)

描述服務(wù)，定義服務(wù)的基本屬性

存儲(chǔ)地址列表

變化頻繁度

基本不變

隨著服務(wù)上下線而不斷變更

數(shù)據(jù)量

大

小

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

消費(fèi)者/提供者上報(bào)，控制臺(tái)查詢

PubSub 模型，提供者上報(bào)，消費(fèi)者訂閱

主要使用場景

服務(wù)測(cè)試、服務(wù) MOCK

服務(wù)調(diào)用

可用性要求

元數(shù)據(jù)中心可用性要求不高，不影響主流程

注冊(cè)中心可用性要求高，影響到服務(wù)調(diào)用的主流程

下面我會(huì)對(duì)每個(gè)對(duì)比點(diǎn)進(jìn)行單獨(dú)分析，以加深對(duì)元數(shù)據(jù)中心的理解。

職責(zé)

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

變化頻繁度

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

數(shù)據(jù)量

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

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

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

主要使用場景

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

可用性要求

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

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

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

降低地址推送的時(shí)延

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

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

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

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

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

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