本文整理自虎牙中間件團隊在 Nacos Meetup 的現(xiàn)場分享，阿里巴巴中間件受權(quán)發(fā)布。

這次分享的是全球 DNS 秒級生效在虎牙的實踐，以及由此產(chǎn)生的一些思考，整體上，分為以下5各部分：

• 背景介紹；
• 方案設(shè)計和對比；
• 高可用；
• 具體實踐和落地；
• 規(guī)劃；

背景介紹

虎牙用到的基礎(chǔ)技術(shù)很多，DNS 是其中比較重要的一個環(huán)節(jié)。

DNS 的解析過程很關(guān)鍵，例如上圖中的 DNS 解析器通過一個定位解析追蹤到我們的 DNS，再到本地域名服務(wù)器迭代解析，經(jīng)過根域再到.com名，最后到huya.com的根域名，獲取最終的解析結(jié)果。

在這個過程中， DNS解析是天然的分布式架構(gòu)，每一層都會有緩存，上一層出現(xiàn)問題掛掉，下一層都會有緩存進行容災(zāi)。另外，整個 DNS 協(xié)議支持面廣，包括手機和 PC，我們用的編程框架里也有 DNS 解析器，服務(wù)器也會配 DNS 解析引擎，因此，DNS 在虎牙的基礎(chǔ)設(shè)施中是很重要的部分。

虎牙的 DNS 的應(yīng)用現(xiàn)狀

虎牙當(dāng)前主要是依賴于公共的 DNS，相信在座的小伙伴們或多或少都會遇到過下面這些問題：

• 依賴公共 localDNS，解析不穩(wěn)定，延遲大。
• 記錄變更生效時間長，無法及時屏蔽線路和節(jié)點異常對業(yè)務(wù)的影響。例如，權(quán)威 DNS 全球各節(jié)點數(shù)據(jù)同步時間不可控，全局生效時間超過10分鐘；localDNS 緩存過期時間不可控，部分 localDNS 不遵循TTL時間，緩存時間超過48小時。
• 內(nèi)部 DNS 功能缺失，無法解決內(nèi)部服務(wù)調(diào)用面臨挑戰(zhàn)。例如，時延大、解析不準(zhǔn)、支持多種調(diào)度策略。
• 無法滿足國外業(yè)務(wù)的快速發(fā)展，雖然一些海外云廠商提供了基于 DNS 的快速擴容方案，以及基于 DNS 的數(shù)據(jù)庫切換方案。

方案設(shè)計和對比

基于以上的問題，我們開始重新規(guī)劃 DNS 的設(shè)計。

名字服務(wù)架構(gòu)

整個規(guī)劃會分三個方面，核心是我們做了「名字服務(wù)」的中心點，基于此，可以滿足我們的需求。

一方面通過 Nacos Sync，將現(xiàn)有多個注冊中心的服務(wù)， 同步到「名字服務(wù)」中， 通過 DNS 實現(xiàn)不同框架之間的 Rest 服務(wù)方式的調(diào)用， 實現(xiàn)例如 Eureka，Consul，Taf等框架之間的服務(wù)調(diào)用。

另一方面，在全球負(fù)載均衡的場景下，由于虎牙是以音視頻業(yè)務(wù)為主，而音視頻業(yè)務(wù)對節(jié)點的延遲是非常敏感的，所以我們希望一旦出現(xiàn)節(jié)點延遲的情況，能立馬做切換。

第三個是傳統(tǒng) DNS 的場景， 可以滿足容器和物理機的 DNS 需求， 提供本機 Agent 和集群兩種方案， 通過緩存和 prefect 大大提高 DNS 解析的可用性和加快生效時間。

對于名字服務(wù)的總體設(shè)計主要分3部分，接入層需要提供 API，消息通知和 DNS 接入的能力。核心功能需要能在基于現(xiàn)有網(wǎng)絡(luò)數(shù)據(jù)，CMDB 和 IP 庫的數(shù)據(jù)基礎(chǔ)上，提供靈活的負(fù)載均衡能力，全球數(shù)據(jù)的秒級同步，多個數(shù)據(jù)源的同步，能對全網(wǎng)服務(wù)的健康狀態(tài)進行監(jiān)控，及時感知到大范圍的節(jié)點異常，并且能夠及時將節(jié)點的屏蔽的信息推送到端上。

最終，我們選擇 Nacos 作為名字服務(wù)的核心，提供統(tǒng)一的 API ，包括名字注冊、變化推送、負(fù)載均衡等；Nacos Sync 作為全球集群間數(shù)據(jù)同步的組件；DNS - F是客戶端組件，用于攔截 DNS 請求，實現(xiàn)基于 DNS 的名字服務(wù)。

改造前后 DNS 變更生效流程的不同

接下來，我們通過對比看下改造前后 DNS 變更生效流程的差異。

原有 DNS 變更生效流程中，對 DNS 生效時間有影響的是：

Auth DNS：

跨區(qū)域、跨國數(shù)據(jù)同步慢，不穩(wěn)定。

bind 在數(shù)據(jù)量比較大的時候，同步比較慢。

Local DNS：

根據(jù) TTL 緩存，過期后才會刷新數(shù)據(jù)。

部分廠商不遵循 TTL 時間緩存，超過24小時的緩存時間。

服務(wù)器：

服務(wù)器開啟 nscd 做 DNS 緩存。

業(yè)務(wù)進程：

應(yīng)用的 DNS 緩存，比如 JAVA 虛擬機、框架層的 DNS 緩存。

以上四種情況會比較影響 DNS 的變更生效流程，下圖是我們現(xiàn)有的 DNS 變更生效流程：

整體上相對簡單，只要業(yè)務(wù)進程這邊將自己內(nèi)部的 DNS 緩存關(guān)掉， 通過 DNS-F 進行查詢的時候， 會直接到最近的 Nacos 集群拉取最新的服務(wù)節(jié)點信息， 而且后續(xù)節(jié)點的變化也會推送到 DNS-F 中， 后續(xù)可以直接在緩存中獲取最新信息。

國內(nèi) Nacos 集群：

集群內(nèi)通過 raft 協(xié)議同步數(shù)據(jù)，毫秒級別完成同步。

Nacos Sync：

Nacos 推送變化到 Nacos Sync，跨區(qū)域、跨國網(wǎng)絡(luò)差的情況下可能會導(dǎo)致推送結(jié)果丟失，或者延遲加大。

Nacos Sync 會主動拉取實例變更，拉取周期和監(jiān)聽的服務(wù)數(shù)量會影響到變更時效。

DNS - F：

Nacos 會將變更推送到 DNS - F，網(wǎng)絡(luò)差的情況可能會導(dǎo)致推送結(jié)果丟失，或者延遲加大。

DNS - F 會主動拉取實例變更，拉取周期和監(jiān)聽的服務(wù)數(shù)量會影響到變更時效。

業(yè)務(wù)進程：

通過應(yīng)用禁用 DNS 緩存來解決。

核心設(shè)計 Nacos

Nacos 有兩套推送機制。

一種是通過客戶端來選擇一個可獲節(jié)點，比如它第一次拉取的是一個正常節(jié)點，這個正常節(jié)點就會跟它維護一個訂閱關(guān)系，后面有變化就會有一個相應(yīng)的實地變化推送給我。如果當(dāng)前節(jié)點掛掉， 他會通過重連， 在節(jié)點列表上，連上一個正常的節(jié)點。這時候會有新的 DNS 關(guān)系出現(xiàn)。

另一種是通過 SDK 的方式，在服務(wù)端尋找可獲節(jié)點。服務(wù)端每個節(jié)點之間， 會進行一個可活的探測， 選擇其中一個可活節(jié)點用戶維護這個訂閱關(guān)系。 當(dāng)這個節(jié)點出現(xiàn)問題， 連接斷開后， SDK 重新發(fā)送訂閱請求，服務(wù)端會再次選擇另外一個可活的節(jié)點來維護這個訂閱關(guān)系。這就保證整了推送過程不會因為某個節(jié)點掛掉而沒有推送。

推送的效率方面，主要是用 UDP 的方式，這個效率不像 TCP 消耗那么高。

以上兩個方案都比較適合我們目前的場景。

核心組件設(shè)計 Nacos Sync

我們選擇 Nacos Sync 作為多集群數(shù)據(jù)同步的組件，主要是從以下4方面進行考慮的。

• 同步粒度：

Nacos Sync 同步數(shù)據(jù)的時候是以服務(wù)為維度， 比較容易做最終一致性處理， 同時可以提供保活的機制，滿足節(jié)點維持的場景。 數(shù)據(jù)庫通過 Binlog 同步的方式只能局限于事務(wù)粒度， 而文件同步只能通過單個文件的粒度， 在服務(wù)同步這個維度并不是很合適。

• 可用性方面：

Nacos Sync 作為一個中間件，是以集群方式進行的，傳統(tǒng)的數(shù)據(jù)庫和文件方式基本是單進程進行的，可用性方面可能不太滿足要求。

• 同步方式方面：

Nacos Sync 通過在服務(wù)粒度的全量寫入，滿足服務(wù)注冊和 DNS 這兩種場景， 不需要額外的事務(wù)消耗， 能保證最終一致即可。

• 環(huán)形同步：

我們國內(nèi)有多個可獲的節(jié)點，希望它們之間的數(shù)據(jù)可以進行環(huán)形同步，每個節(jié)點之間是相互備份的，這時候用 Nacos Sync 的話，是支持的。雖然數(shù)據(jù)庫方面，比較經(jīng)典的是主主同步，但如果同時對一個主件進行更新的話，每一個點進行協(xié)助是會有問題的，而且文件方面是不支持的。

Nacos Sync 和開源版本的不同

我們對 Nacos Sync 開源方案上做了幾處修改，以更好的適用于現(xiàn)在的場景：

第一，通過配置方式對任務(wù)進行分拆。因為在實際應(yīng)用場景里面，因為 Nacos Sync 的任務(wù)達(dá)一兩萬，單機很容易到達(dá)瓶頸，所以我們通過配置的方式將這些分片到多臺 Nacos Sync 機器上。

第二，通過事件合并和隊列控制的方式控制 Nacos 集群的寫入量，以保證后端的穩(wěn)定性。雖然下發(fā)事件一秒鐘只有一個，但在很多場景中，例如需要 K8s 或者 Taf 進行數(shù)據(jù)同步的時候，變化的頻率是非常高的，這時候通過事件合并，每個服務(wù)單獨進行一個寫入進程。這樣通過隊列控制的方式可以控制整個 Nacos 集群的寫入量。

第三，添加了能支持從K8s 和 Taf 同步數(shù)據(jù)的功能。后期我們會將這個特性提交給 Nacos，讓更多的開發(fā)者使用。

核心組件設(shè)計 DNS - F

DNS - F是基于 CoreDNS 上開發(fā)的，我們擴展了以下 4 個組件：

Nacos 插件：查詢 Nacos 服務(wù)信息，監(jiān)聽 Nacos 服務(wù)變化，并將服務(wù)轉(zhuǎn)化為域名，實現(xiàn)以 DNS 協(xié)議為基礎(chǔ)的服務(wù)發(fā)現(xiàn)；

Cache 插件：提供域名緩存服務(wù);

Log 插件：將 DNS 解析日志上報到日志服務(wù)；

Proxy 插件：代理解析外部域名；

DNS - F 和開源版本的不同

第一，在日志組件里面將日志上傳到自己的日志服務(wù)。

第二，對緩存功能做了一個增強。一般的緩存功能可能根據(jù) TTL 時間會過期，我們把這個過期時間給去掉了，直接令到緩存永遠(yuǎn)不會過期，然后通過異步將這個緩存進行刷新。比如 TTL 可能快到到時間了，我們就會主動做一個查詢或者推送查詢，這樣，服務(wù)端或者公共 DNS 出現(xiàn)問題的時候，就不會影響到整體服務(wù)。

第三，增強了高可用的保障能力。包括進程監(jiān)控、內(nèi)部運營和外部運營的探測。另外，原來的開源版本用的是本機部署的方式，我們做成了集群化的部署，解決了服務(wù)推送、服務(wù)負(fù)載均衡方面的問題。

高可用

接下來由我們團隊的李志鵬，分享一下虎牙在高可用方面的實踐。

周健同學(xué)跟大家介紹了項目的背景跟方案設(shè)計，我來和大家介紹一下具體的實踐和落地，實踐過程中的主要關(guān)注點是高可用。

全球化部署方案

這是虎牙的一個全球化的部署方案，我們在全球部署了兩個大區(qū)，分別是國內(nèi)和國外。這兩個大區(qū)是指定服務(wù)同步的，走的是專線，這樣可以保障同步的穩(wěn)定性。在一個大區(qū)內(nèi)我們又部署了多個接入點，例如在國內(nèi)大區(qū)，我們部署了深圳和無錫兩個接入點，這兩個節(jié)點的數(shù)據(jù)是互相同步、互為備份，保證在一個集群掛掉下可以切換到另外一個集群。

多個接入點的情況下，我們通過 HttpDNS 實現(xiàn)客戶端的就近接入。客戶端定期請求 HttpDNS，HttpDNS 能根據(jù)地域?qū)ふ揖徒尤朦c。如果接入點出現(xiàn)故障，我們就直接在HttpDNS 把這個節(jié)點給摘除，這樣客戶端就能快速地切換到另外一個接入點。

接下來講一下單個集群下的部署方案。

單個集群部署了多個 Nacos 節(jié)點，并通過7層負(fù)載均衡的方式暴露給外面使用，并且提供了多個 VIP，滿足不同線路和區(qū)域的接入要求。同時，Nacos Sync 做了分片處理，將同步壓力分散到各個分片上，一個分片下我們又部署了多個 Nacos Sync 的節(jié)點，以保障多活和高可用。

線上演練

演練的場景是模擬一個單個集群掛了和兩個集群都掛了。

從圖中可以看到，把深圳的流量切走之后，無錫的流量就漲上去了，然后再把無錫的流量切走，再關(guān)閉服務(wù)，這樣就可以看到兩邊的流量已經(jīng)沒了。之后，再去恢復(fù)兩個集群的流量，看一下整個切換過程中對服務(wù)的影響。

首先看一下對寫入的影響，在單個集群掛了的情況下，是沒有任何影響的。如果是兩個集群都掛了，寫入就會失敗。可以看到，這個圖有一個波峰，這個波峰就是我們兩個集群都掛了的情況下，寫入失敗延遲加大。

但是切換的整個過程對 DNS-F 是沒有任何影響的，延遲保持平穩(wěn)。此外，在集群重新上線前，我們需要做數(shù)據(jù)校驗，保證集群之間元數(shù)據(jù)和實例數(shù)據(jù)的最終一致。

可用性級別方面，我們可以保障：

• 單集群掛掉后不會有影響；
• 雙集群掛掉后只會影響域名變更，不影響域名解析；

線上演練數(shù)據(jù)校驗機制

運行過程中，我們也要保證集群間數(shù)據(jù)的一致性。我們通過全量校驗和增量校驗兩種手段去保證，全量校驗方式如下：

• 大區(qū)內(nèi)部做10分鐘的全量校驗，保證大區(qū)內(nèi)各個集群數(shù)據(jù)的一致；
• 大區(qū)之間做2分鐘做一次全量校驗，保證大區(qū)之間被同步的服務(wù)的數(shù)據(jù)一致性。

增量校驗方式如下：

• 從其他數(shù)據(jù)源同步的數(shù)據(jù)，通過數(shù)據(jù)源的時間戳，做增量校驗；
• 基于API的寫入日志，定期校驗寫入的內(nèi)容是否已經(jīng)全部同步。

DNF - S 高可用

關(guān)于 DNS - F 的高可用，我們主要做了以下5個點：

• Agent 的健康狀態(tài)監(jiān)測，包括進程存活和是否能正常解析；
• 緩存內(nèi)部域名，并做持久化處理，保證 Nacos 集群出現(xiàn)問題時不會影響內(nèi)部域名的解析；
• 提供備用節(jié)點，保證在 DNS-F 掛了，或者是 DNS-F 需要升級的情況下，也不會影響到內(nèi)部域名解析；
• resolv.conf 配置檢查，發(fā)現(xiàn)127.0.0.1不在配置中會自動添加；
• 限制 Agent 的 CPU 的使用，避免對業(yè)務(wù)進程造成影響。

具體的實踐和落地

實踐一：數(shù)據(jù)庫域名改造

之前的數(shù)據(jù)庫是用 IP 方式接入的，在數(shù)據(jù)庫切換的時候，需要通知每個業(yè)務(wù)方修改配置，重啟服務(wù)，這樣就帶來一個問題：整個過程是不可控的，取決于業(yè)務(wù)方的響應(yīng)速度，生效時間通常超過十分鐘。

提升數(shù)據(jù)庫切換的關(guān)鍵點，第一個就是切換時不需要業(yè)務(wù)方參與，能在業(yè)務(wù)方無感知的情況下進行切換；第二個是實例變化能秒級推送到我們的應(yīng)用，將應(yīng)用快速切換到一個新的實例上。

大家可以看一下這個圖，這是我們現(xiàn)在做的一個改造，圖中的 DMX 是虎牙內(nèi)部的一個數(shù)據(jù)庫管理系統(tǒng)，思路就是把 DMX 和名字服務(wù)打通。DMX 會把數(shù)據(jù)庫實例信息以服務(wù)的形式注冊到名字服務(wù)，服務(wù)名就是域名。

實際應(yīng)用過程中，通過這個域名去訪問數(shù)據(jù)庫，應(yīng)用在訪問前首先會經(jīng)過 DNS - F 去做域名的解析，解析的時候是從名字服務(wù)查詢實例信息，然后把實例的IP返回給應(yīng)用。這樣，應(yīng)用就能通過 IP 和我們的數(shù)據(jù)庫實例進行連接。

切換的時候，在 DMX 平臺修改域名對應(yīng)的實例信息，并把變更推送到名字服務(wù)，名字服務(wù)再推送給 DNS-F，應(yīng)用在下一次解析的時候就能拿到新的實例 IP，達(dá)到切換數(shù)據(jù)庫實例的目的。

這套方案落地后，虎牙的數(shù)據(jù)庫切換基本上在10秒鐘之內(nèi)能夠完成。

實踐二：內(nèi)部調(diào)用使用內(nèi)部域名

虎牙部分內(nèi)部系統(tǒng)之間調(diào)用是通過7層負(fù)載均衡，但是由于沒有內(nèi)部 DNS，需要通過的公共的 LocalDNS 來解析，這就帶來一些問題：

問題一：擴縮容的時候要去修改 DNS 記錄，整個過程生效時間可能會超過10分鐘，故障的節(jié)點會影響業(yè)務(wù)較長的時間。

問題二：公共的 LocalDNS 智能解析不準(zhǔn)確，比如無錫的機器可能會解析到深圳的一個接入點，影響接入質(zhì)量。

問題三：不支持定制化的負(fù)載均衡策略，例如同機房、同大區(qū)優(yōu)先的策略，通過公共 LocalDNS 是實現(xiàn)不了的。

如果想要提升內(nèi)部服務(wù)調(diào)用質(zhì)量，一是 DNS 記錄變更繞過 LocalDNS，把 DNS 的記錄變更直接推到 DNS-F。二是與內(nèi)部系統(tǒng)打通，從 CMDB 等內(nèi)部系統(tǒng)獲取機器信息，支持多種負(fù)載均衡策略。

大家可以看一下上面的圖，這個改造和數(shù)據(jù)庫域名的改造思路是一樣的，最右上角有一個7層負(fù)載管理系統(tǒng)，我們把這個系統(tǒng)和名字服務(wù)打通，7層負(fù)載管理系統(tǒng)會把域名信息以服務(wù)形式注冊到名字服務(wù)，變更域名記錄時直接從7層負(fù)載管理系統(tǒng)推送到名字服務(wù)，名字服務(wù)再推送到 DNS-F，達(dá)到快速切換的目的。

如果域名配置了負(fù)載均衡策略，名字服務(wù)會從 CMDB 獲取機器、機房等信息，打標(biāo)到域名的實例信息。然后，DNS-F 查詢名字服務(wù)時，會攜帶 ClientIp，名字服務(wù)根據(jù) ClientIp 的CMDB 信息過濾實例列表，返回同機房的實例給 DNS-F，達(dá)到同機房優(yōu)先的目的。

由此帶來的效果是：

第一，服務(wù)擴縮容能夠秒級完成，減少了故障時間。

第二，擴展了 DNS 的負(fù)載均衡策略，例如有些業(yè)務(wù)是需要在不同區(qū)域有不同的接入點的，而且不能跨區(qū)域調(diào)用，之前的 DNS 負(fù)載均衡策略是不能滿足這個需求的，但在改造之后，我們能根據(jù) CMDB 信息去做同區(qū)域調(diào)度的負(fù)載均衡策略。

第三，業(yè)務(wù)在接入內(nèi)部域名之后，延遲會有明顯的下降。上圖顯示的就是某個服務(wù)在接入到內(nèi)部域名之后，延遲出現(xiàn)明顯的下降。

另一個落地的效果就是我們對主機上的域名解析的優(yōu)化。因為我們的 DNS - F 是部署在每臺主機上的，然后提供一個緩存的功能。帶來的效果就是：

• 平均解析延遲會從之前的200毫秒下降到現(xiàn)在的1毫秒；
•  

緩存命中率會從之前的90%上升到99.8%，90%是用 CoreDNS 原生的那個 Cache，99.8%是在這個 Cache 的組件下做了優(yōu)化之后的效果；

• 解析失敗率是從之前的0.1%下降到0%；

這里再總結(jié)一下項目落地的技術(shù)價值：

第一，提供了基于 DNS 服務(wù)發(fā)現(xiàn)的能力，消除異構(gòu)系統(tǒng)之間互相調(diào)用的障礙。

第二，填補了沒有內(nèi)部域名解析能力的空白。

第三，解決我們上面說的內(nèi)部服務(wù)調(diào)用面臨的挑戰(zhàn)：延時大、解析不準(zhǔn)、不支持多種負(fù)載均衡策略、故障牽引慢。

第四，優(yōu)化外部域名的解析，屏蔽 LocalDNS 的故障。

落地規(guī)模是：DNS - F 覆蓋率100%，完成 Taf 和 Eureka 注冊中心的數(shù)據(jù)同步。

后續(xù)規(guī)劃

LocalDNS：

解決公共 DNS 節(jié)點位置影響域名解析準(zhǔn)確性的問題；

解決內(nèi)部使用公共 DNS 不穩(wěn)定的問題；

優(yōu)化內(nèi)外網(wǎng)解析；

精準(zhǔn)調(diào)度：

解決全球 DNS 節(jié)點生效慢的問題。

本文作者：

周健：GitHub ID @nanamikon，虎牙中間件團隊成員，2012年畢業(yè)于中山大學(xué)，主要負(fù)責(zé)名字和配置服務(wù)，以及虎牙 DNS 和微服務(wù)相關(guān)的工作。

李志鵬：GitHub ID @lzp0412，虎牙中間件團隊成員，主要負(fù)責(zé) DNS，以及服務(wù)注冊與發(fā)現(xiàn)、服務(wù)治理、Service Mesh 等相關(guān)工作。

------------------------------

本文作者：中間件小哥

原文鏈接：https://yq.aliyun.com/articles/703377?utm_content=g_1000059731