hello，大家好，我是小樓。

在上一篇文章《??如何組裝一個(gè)注冊中心??》中，我們看到了如何利用一些現(xiàn)有的技術(shù)方案來組裝出一個(gè)生產(chǎn)可用的注冊中心最小集。

有的同學(xué)看完表示學(xué)到了，也有同學(xué)直呼不過癮，能不能手寫一個(gè)注冊中心？能不能繼續(xù)展開說說？

由于精力有限，手寫一個(gè)注冊中心暫時(shí)還不行，展開說說倒是可以滿足。

于是本期打算以注冊中心的周邊能力展開說說，這些能力屬于錦上添花，沒有它們注冊中心可以正常運(yùn)行，有了它們也不一定變得更強(qiáng)，但一定會更加花里胡哨。

那可能有讀者會問，花里胡哨的有什么用呢？我覺得主要是了解一些新的、奇怪的知識，說不定哪天能用上呢，是吧？

控制臺

如果想讓注冊中心變得花里胡哨，首先肯定是開發(fā)一個(gè)控制臺，控制臺的基本功能就是展示服務(wù)的消費(fèi)者與提供者，展示的用處有查找服務(wù)，排查問題等等，下圖是Nacos的控制臺：

除了基本的展示功能，我們還可以在控制臺上搞些別的事情，比如下面這些。

服務(wù)配置

配置本不是注冊中心必備的功能，配置一般由配置中心管理，但配置中心似乎又和注冊中心脫不了干系，Nacos就是一個(gè)集注冊中心和配置中心于一體的組件。

注冊中心也可以做一點(diǎn)和服務(wù)相關(guān)配置的事情，比如服務(wù)的超時(shí)時(shí)間、熔斷降級等等元數(shù)據(jù)，不過要注意的是注冊中心本身只能保存、修改，至于這些配置真正起作用的還是得和RPC框架配合。

可能你會問，為什么注冊中心要去做配置中心的事兒呢？這不是職責(zé)不清？

可以這么理解，服務(wù)發(fā)現(xiàn)基本是個(gè)服務(wù)都要接入，但配置中心可不一定要接，如果只想做點(diǎn)簡單的服務(wù)相關(guān)的動態(tài)配置，引入一個(gè)配置中心是有點(diǎn)重。

如果是公司生產(chǎn)級的服務(wù)配置，最好再附帶上一個(gè)灰度的能力，如果一次下發(fā)配置到全部機(jī)器，可能會出現(xiàn)故障，所以需要一種灰度下發(fā)的機(jī)制，分批下發(fā)，控制風(fēng)險(xiǎn)。

事件追蹤

說到問題排查，光展示提供者、消費(fèi)者可能還不夠，有時(shí)候啟動一個(gè)提供者，消費(fèi)者就是沒感知到，或者很久之后才感知到，這時(shí)有點(diǎn)摸不著頭腦，如果我們拿出這個(gè)事件的時(shí)間線，哪個(gè)環(huán)節(jié)出問題便一目了然。

在Nacos的企業(yè)版中就支持了類似的推送軌跡功能，當(dāng)然這么好的功能，肯定是收費(fèi)項(xiàng)。

拓?fù)潢P(guān)系

可能我們忽略了注冊中心的繪制服務(wù)之間的拓?fù)潢P(guān)系的能力，開源注冊中心基本沒提到這個(gè)，一般來說拓?fù)潢P(guān)系是鏈路追蹤的活。

注冊中心其實(shí)也大致可以干這個(gè)活，不過注冊中心是按照服務(wù)的訂閱關(guān)系繪制出來，并不是按照真實(shí)的調(diào)用關(guān)系，但這幾乎也近似調(diào)用關(guān)系了，有了這個(gè)，我們就可以去做一些服務(wù)治理相關(guān)的事了，比如循環(huán)依賴、依賴層級太深等問題都可以看出來。

流量控制

流量控制也不一定非要在注冊中心上做，比如Dubbo就是在RPC框架上做了很多流量相關(guān)的事情，像集群的選擇、路由、負(fù)載均衡等。

如果RPC框架沒這么強(qiáng)大的能力，或者RPC框架是多語言的實(shí)現(xiàn)，能力尚未打平，那么在注冊中心上實(shí)現(xiàn)也是一個(gè)不錯(cuò)的選擇。

路由偏好

路由偏好簡單來說，如果提供者有多個(gè)集群，挑選一個(gè)更適合的集群來提供服務(wù)，這就叫路由偏好。

舉個(gè)例子，例如消費(fèi)者在杭州，提供者有兩個(gè)集群，一個(gè)在上海，一個(gè)在北京，這兩個(gè)機(jī)房提供的服務(wù)完全對等，這時(shí)消費(fèi)者更適合調(diào)用本地的集群，這樣時(shí)延更小。

當(dāng)然我們還可以根據(jù)服務(wù)器的性能、甚至自定義的規(guī)則來做路由偏好。

動態(tài)切流

有了上面路由偏好的鋪墊，想必你也能想到一個(gè)場景，萬一有一天上海的提供者不可用了，我們可以通過對注冊中心的干預(yù)，手動把北京的提供者下發(fā)給消費(fèi)者，實(shí)現(xiàn)一個(gè)客戶端無侵入的動態(tài)切流。

流量劫持

流量劫持和動態(tài)切流的原理一樣，實(shí)現(xiàn)也基本差不多，只不過下發(fā)的數(shù)據(jù)不太一樣，原先的提供者列表，被注冊中心偷天換日，換成了本地的一個(gè)端口127.0.0.1:8001。

這樣替換有什么作用呢？比如用agent來承接流量，像service mesh都有這種需求，注冊中心就可以完成流量劫持。

其實(shí)劫持還有其他作用，如果服務(wù)的提供方壓力太大，想降級，但消費(fèi)者和提供者都沒有降級能力，眼看著服務(wù)快掛了，千鈞一發(fā)之際，你想到了注冊中心，手動下發(fā)一個(gè)不存在的提供者地址，讓消費(fèi)者請求報(bào)錯(cuò)，以保護(hù)其他服務(wù)正常運(yùn)行，這些奇奇怪怪的想法說不定都可以在注冊中心上實(shí)現(xiàn)。

探活

探活算是注冊中心的一個(gè)小功能，我們看看在這個(gè)小功能上還能玩出什么花樣。

探活擴(kuò)展

最簡單的探活是端口探活，即注冊中心向提供者注冊的端口發(fā)起TCP連接請求，如果能成功建立連接說明服務(wù)正常。但有時(shí)又不是這樣，比如服務(wù)僵死，端口還能連接，但服務(wù)沒法提供了，這時(shí)我們需要語義級的探活。

根據(jù)提供者提供的服務(wù)和配置發(fā)起一個(gè)請求，如果返回和預(yù)期相符合，則判定為服務(wù)存活。

我們通常將這個(gè)探活留出擴(kuò)展點(diǎn)，一般可以擴(kuò)展出HTTP、MySQL、Redis、Thrift等協(xié)議的語義探活，以HTTP為例，服務(wù)提供方配置探活的URI，注冊中心把提供方的ip、port與URI進(jìn)行拼接、發(fā)起請求，如果響應(yīng)符合預(yù)期（如返回碼為2xx），則這次探活成功，同理，也可擴(kuò)展出其他協(xié)議的語義級探活。

探活兜底

探活雖好，但有時(shí)候又很危險(xiǎn)，如果注冊中心與提供者的網(wǎng)絡(luò)閃斷，則可能將提供者全部摘除，這是個(gè)非常危險(xiǎn)的操作，為了防止這種情況，探活兜底是很有必要的一種行為，比如同一個(gè)服務(wù)集群不能摘除超過1/3，當(dāng)然這個(gè)比例是個(gè)經(jīng)驗(yàn)值，也最好可以配置化。

生態(tài)建設(shè)

優(yōu)雅發(fā)布

優(yōu)雅發(fā)布包括優(yōu)雅退出和優(yōu)雅上線，優(yōu)雅是指在應(yīng)用退出和上線過程中沒有報(bào)錯(cuò)。

注冊中心結(jié)合發(fā)布系統(tǒng)來做優(yōu)雅發(fā)布是最好的搭配。發(fā)布系統(tǒng)在停止應(yīng)用前，向注冊中心發(fā)起禁用請求（停止接流），注銷后再停止應(yīng)用，服務(wù)上線后啟動完成后，再將服務(wù)開啟，接受流量。

框架適配

一個(gè)注冊中心如果想要更多的人來使用，則需要適配各種主流開發(fā)語言如Go/Java/Cpp等，適配一些主流框架如Dubbo/SpringCloud/gRPC等，這樣用戶用起來才更加方便，缺點(diǎn)是維護(hù)成本變高。

DNS 服務(wù)發(fā)現(xiàn)

對于無法接入服務(wù)發(fā)現(xiàn)SDK的用戶，如果也想享受服務(wù)發(fā)現(xiàn)能力，怎么做呢？

業(yè)界有一種做法是自定義一個(gè)DNS攔截器，將DNS請求攔截，通過域名（對應(yīng)到服務(wù)名）去注冊中心找提供者。但這樣做有一個(gè)缺點(diǎn)是DNS只能發(fā)現(xiàn)ip，端口沒法自動發(fā)現(xiàn)。

一般這種攔截器可通過中心的DNS服務(wù)器或者本地的DNS agent代理來實(shí)現(xiàn)，也可以自定義編程語言的DNS解析插件來實(shí)現(xiàn)，像Go/Java都可以自定義DNS解析插件，但這種就屬于入侵比較強(qiáng)了。