一文聊透 Dubbo 後設資料中心

前言

如果讓你在本地構建一個 Dubbo 應用，你會需要額外搭建哪些中介軟體呢？如果沒猜錯的話，你的第一反應應該是註冊中心，類 Dubbo 的大多數服務治理框架都有註冊中心的概念。你可以部署一個 Zookeeper，或者一個 Nacos，看你的喜好。但在 Apache Dubbo 的 2.7 版本後，額外引入了兩個中介軟體：後設資料中心和配置中心。

在今年年初 Dubbo 2.7 剛釋出時，我就寫了一篇文章 《Dubbo 2.7 三大新特性詳解》，介紹了包含後設資料中心改造在內的三大新特性，但一些細節介紹沒有詳細呈現出來，在這篇文章中，我將會以 Dubbo 為例，跟大家一起探討一下服務治理框架中後設資料中心的意義與整合細節。

後設資料中心介紹

服務治理中的後設資料（Metadata）指的是服務分組、服務版本、服務名、方法列表、方法引數列表、超時時間等，這些資訊將會儲存在後設資料中心之中。與後設資料平起平坐的一個概念是服務的註冊資訊，即：服務分組、服務版本、服務名、地址列表等，這些資訊將會儲存在註冊中心中。稍微一對比可以發現，後設資料中心和註冊中心儲存了一部分共同的服務資訊，例如服務名。兩者也有差異性，後設資料中心還會儲存方法列表即引數列表，註冊中心儲存了服務地址。上述的概述，體現出了後設資料中心和註冊中心在服務治理過程中，擔任著不同的角色。為了有一個直觀的對比，我整理出了下面的表格：

	後設資料	註冊資訊
職責	描述服務，定義服務的基本屬性	儲存地址列表
變化頻繁度	基本不變	隨著服務上下線而不斷變更
資料量	大	小
資料互動/儲存模型	消費者/提供者上報，控制檯查詢	PubSub 模型，提供者上報，消費者訂閱
主要使用場景	服務測試、服務 MOCK	服務呼叫
可用性要求	後設資料中心可用性要求不高，不影響主流程	註冊中心可用性要求高，影響到服務呼叫的主流程

下面我會對每個對比點進行單獨分析，以加深對後設資料中心的理解。

職責

在 Dubbo 2.7 版本之前，並沒有後設資料中心的概念，那時候註冊資訊和後設資料都耦合在一起。Dubbo Provider 的服務配置有接近 30 個配置項，排除一部分註冊中心服務治理需要的引數，很大一部分配置項僅僅是 Provider 自己使用，不需要透傳給消費者；Dubbo Consumer 也有 20 多個配置項。在註冊中心之中，服務消費者列表中只需要關注 application，version，group，ip，dubbo 版本等少量配置。這部分資料不需要進入註冊中心，而只需要以 key-value 形式持久化儲存在後設資料中心即可。從職責來看，將不同職責的資料儲存在對應的元件中，會使得邏輯更加清晰。

變化頻繁度

註冊資訊和後設資料耦合在一起會導致註冊中心資料量的膨脹，進而增大註冊中心的網路開銷，直接造成了服務地址推送慢等負面影響。服務上下線會隨時發生，變化的其實是註冊資訊，後設資料是相對不變的。

資料量

由於後設資料包含了服務的方法列表以及引數列表，這部分資料會導致後設資料要比註冊資訊大很多。註冊資訊被設計得精簡會直接直接影響到服務推送的 SLA。

資料互動/儲存模型

註冊中心採用的是 PubSub 模型，這屬於大家的共識，所以註冊中心元件的選型一般都會要求其有 notify 的機制。而後設資料中心並沒有 notify 的訴求，一般只需要元件能夠提供 key-value 的儲存結構即可。

主要使用場景

在服務治理中，註冊中心充當了通訊錄的職責，在複雜的分散式場景下，讓消費者能找到提供者。而後設資料中心儲存的後設資料，主要適用於服務測試、服務 MOCK 等場景，這些場景都對方法列表、引數列表有所訴求。在下面的小節中，我也會對使用場景進行更加詳細的介紹。

可用性要求

註冊中心當機或者網路不通會直接影響到服務的可用性，它影響了服務呼叫的主路徑。但一般而言，後設資料中心出現問題，不會影響到服務呼叫，它提供的能力是可被降級的。這也闡釋了一點，為什麼很多使用者在 Dubbo 2.7 中沒有配置後設資料中心，也沒有影響到正常的使用。後設資料中心在服務治理中扮演的是錦上添花的一個角色。在元件選型時，我們一般也會對註冊中心的可用性要求比較高，後設資料中心則可以放寬要求。

後設資料中心的價值

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

降低地址推送的時延

由於註冊中心採用的是 PubSub 模型，資料量的大小會直接影響到服務地址推送時間，不知道你有沒有遇到過 No provider available 的報錯呢？明明提供者已經啟動了，但由於註冊中心推送慢會導致很多問題，一方面會影響到服務的可用性，一方面也會增加排查問題的難度。

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

推送量大 -> 儲存資料量大 -> 網路傳輸量大 -> 延遲嚴重

這一實際案例佐證了後設資料改造並不是憑空產生的需求，而是切實解決了一個痛點。

服務測試 & 服務 MOCK

在 Dubbo 2.7 之前，雖然註冊中心耦合儲存了不少本應屬於後設資料的資料，但也漏掉了一部分後設資料，例如服務的方法列表，引數列表。這些是服務測試和服務 MOCK 必備的資料，想要使用這些能力，就必須引入後設資料中心。例如開源的 Dubbo Admin 就實現了服務測試功能，使用者可以在控制檯上對已經發布的服務提供者進行功能測試。可能你之前有過這樣的疑惑：為什麼只有 Dubbo 2.7 才支援了服務測試呢？啊哈，原因就是 Dubbo 2.7 才有了後設資料中心的概念。當然，服務 MOCK 也是如此。

其他場景

可以這麼理解，任何依賴後設資料的功能，都需要後設資料中心的支援。其他場景還包括了閘道器應用獲取後設資料來進行泛化呼叫、服務自動化測試等等。再描述一個可能的場景，拋磚引玉。在一次南京 Dubbo Meetup 上，dubbo.js 的作者提及的一個場景，希望根據後設資料自動生成 NodeJs 程式碼，以簡化前端的開發量，也是後設資料的作用之一。這裡就需要發揮各位的想象力了

Dubbo 配置後設資料中心

目前 Dubbo 最新的版本為 2.7.4，目前支援的幾種後設資料中心可以從原始碼中得知（官方文件尚未更新）：

支援 consul、etcd、nacos、redis、zookeeper 這五種元件。

配置方式如下：

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

後設資料儲存格式剖析

前面我們介紹了後設資料中心的由來以及價值，還是飄在天上的概念，這一節將會讓概念落地。後設資料是以怎麼樣一個格式儲存的呢？

以 DemoService 服務為例：

<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 中，註冊中心如何儲存這個服務的資訊：

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"/>

之後再觀察註冊中心的資料，已經變得相當精簡了：

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

被精簡省略的資料不代表沒有用了，而是轉移到了後設資料中心之中，我們觀察一下此時後設資料中心中的資料：

最佳實踐

後設資料中心是服務治理中的一個關鍵元件，但對於大多數使用者來說還是一個比較新的概念，我整理了一些我認為的最佳實踐，分享給大家。

• 從 Dubbo 2.6 遷移到 Dubbo 2.7 時，可以採取三步走的策略來平滑遷移後設資料。第一步：Dubbo 2.6 + 註冊中心，第二步：Dubbo 2.7 + 註冊中心 + 後設資料中心，第三步：Dubbo 2.7 + 註冊中心（simplified=true） + 後設資料中心。在未來 Dubbo 的升級版本中，registry 的 simplified 預設值將會變成 true，目前是 false，預留給使用者一個升級的時間。

• 應用在啟動時，會發布一次後設資料，在此之後會有定時器，一天同步一次後設資料，以上報那些執行時生成的 Bean，目前使用者不可以配置後設資料上報的週期，但可以透過 -Dcycle.report 關閉這一定時器。

• 後設資料中心推薦選型：Nacos 和 Redis。

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