相比文字和圖片，直播提供了人與人之間更豐富的溝通形式，其對平臺穩定性的考驗很大，那么倡導“以技術驅動娛樂”的虎牙直播如何在技術上賦能娛樂。

本文將分為如下幾個部分介紹虎牙在 DNS、服務注冊、CMDB 和服務配置中心等方面的實踐：

• 為什么選用 Nacos
• DNS-F 的技術價值和應用場景
• 服務注冊的實踐
• CMDB 的應用和實踐
• 服務配置的實踐
• Nacos 改造和升級總結

為什么選用 Nacos

虎牙關注 Nacos 是從 v0.2 開始的(***版本：Pre-GA v0.8)，我們也參與了社區的建設，可以說是比較早期的企業用戶。

Nacos 是一個更易于幫助構建云原生應用的動態服務發現、配置和服務管理平臺，提供注冊中心、配置中心和動態 DNS 服務三大功能。

首先，在虎牙的微服務場景中，起初有多個注冊中心，每一個注冊中心服務于某一部分微服務，缺少一個能融合多個注冊中心，并把他們逐一打通，然后實現一個能管理整個微服務體系的大的注冊中心。

以下內容摘自我們考慮引入 Nacos 時，在服務注冊中心方案上的選型對比：

 

Nacos 提供 DNS-F 功能， 可以與 K8S、Spring Cloud 和 Dubbo 等多個開源產品進行集成，實現服務的注冊功能。

其次，在服務配置中心方案的選型過程中，我們希望配置中心和注冊中心能夠打通，這樣可以省去我們在微服務治理方面的一些投入。

因此，我們也同步比較了一些服務配置中心的開源方案：

 

例如 Spring Cloud Config Server、Zookeeper 和 ETCD，總體評估下來，基于我們微服務體系現狀以及業務場景，我們決定使用 Nacos 作為我們服務化改造中服務注冊和服務發現的方案。

使用過程中，我們發現，隨著社區版本的不斷更新和虎牙的深入實踐，Nacos 的優勢遠比我們調研過程中發現的更多。

接下來，我將圍繞 DNS-F、Nacos-Sync、 CMDB 和負載均衡四個方面來分享虎牙的實踐。

DNS-F 的技術價值和應用場景

DNS-F 的技術價值

Nacos 提供的 DNS-F 功能的***個技術價值在于，彌補了我們內部微服務沒有一個全局動態調度能力的空白。

剛才提到，虎牙有多個微服務體系，但并沒有一個微服務具備全局動態調度的能力，因為它們各自都是獨立的。

目前，我們通過 Nacos 已經融合了四個微服務體系的注冊中心，最終目標是把所有的微服務都融合在一起，實現全局動態調動的能力。

 

第二，DNS-F 解決了服務端端到端面臨的挑戰，即延時大、解析不準、故障牽引慢的問題。

如何去理解呢?當內部有多個微服務體系的時候，每一個體系的成熟度是不同的。

例如，有一些微服務框架對同機房或 CMDB 路由是不支持的，當一個服務注冊到了多個 IDC 中心，去調用它的服務的時候，即便是同機房，也可能調用到一個不是同機房的節點。

這樣就會無端的造成服務的延時和解析不準。即使我們基于 DNS 做一些解析的優化，但仍然無法完全解決服務的延時和解析不準。

這是因為 DNS 都是 IP 策略的就近解析，無法根據服務的物理狀態、物理信息進行路由。

此外，當一個核心服務出現問題，如果缺少一個融合了多個調用方和被調用方的信息的統一的注冊中心，就很難去準確判斷如何去牽引，從而導致故障牽引慢。

有了 Nacos 后，就可以接入一個統一的注冊中心以及配置中心，去解決這些問題。(目前，虎牙還在微服務體系的改造過程中，未完全實現統一的注冊中心)

第三，提供專線流量牽引能力。虎牙的核心機房的流量互通，是使用專線來實現的。專線的特性就是物理建設的，而且我們的專線建設可能不像 BAT 那么大。

例如我們專線容量的冗余只有 50%，假設某個直播異常火爆，突發流量高于平常的兩百倍，超過了專線的建設能力，這時候一個服務就有可能會導致全網故障。

但是，通過全局的注冊中心和調動能力，我們就可以把流量牽引到其他地方，例如遷移到公網，甚至牽引到一個不存在的地址，來平衡一下。即便某個服務出現問題，也不會影響我們的全局服務。

第四，支持服務端的多種調度需求，包括同機房路由、同機器路由，以及同機架路由，Nacos 都可以去做適配。

此外，基于 Nacos 的 DNS-F 功能，我們還實現了加速外部域名解析和服務故障牽引秒級生效。

DNS-F 的應用場景

 

這張圖是 Nacos DNS-F 的一個具體實現，實際上是攔截了 OS 層的 DNS 請求。

如果經過 DNS 的域名是內部服務，它就會從 Nacos Server 獲取結果，如果不是，就會轉發到其它的 LocalDNS 進行解析。

 

以數據庫高可用的應用場景為例，我們的數據庫切換效率比較低，依賴業務方修改配置，時效不確定，通常需要 10 分鐘以上(備注：我們的數據庫實際上已經實現了主備的功能，但當一個主服務出現問題的時候，總是要去切換IP。)切換 IP 的過程中，依賴運維和開發的協作，這是一個比較長的過程。

引入 DNS 后，當主出現問題的時候，就可以很快的用另外一個主的 IP 來進行替換，屏蔽故障，而且節點的故障檢測和故障切換都可以自動完成，并不依賴運維和開發的協作，節省了時間。

當然，這個場景的解法有很多，比如說使用 MySQL - Proxy 也可以去解這個問題，但我們的 MySQL - Proxy 還在建設中，想盡快的把這個問題解決，所以采用了 DNS 的方式。

下面我們再著重分享下基于 DNS-F 對 LocalDNS 的優化。虎牙還沒有去建設自己的 LocalDNS，大部分使用的是一些公共的 DNS，大致有以下這些組成。

 

這種組成方式會存在一個問題：假設服務突然一下崩潰后，之后服務又馬上正常了，這種情況我們無法重現去找到崩潰原因。

因為很多場景下，是一個公共 DNS 的請求超時導致的，甚至一個解析失敗導致的，在那一刻，因為無法保留現場的，所以就發現不了問題。

以我們的監測數據來看，DNS 解析錯誤的比例達到 1% 左右，超時比例將更高。

意思是在使用公共 DNS 的情況下，服務有 1% 的幾率是會超時或失敗，如果服務沒有做好容錯，就會出現異常。

同時，一些公共 DNS 解析的延時都是不定的，比如在亞馬遜上一些比較不好的節點，它的延時會比較高，平均超過三四十毫秒。

 

然后我們基于 DNS-F 對 LocalDNS 做了一些優化，優化結果如下：

• 平均解析時間從之前的超過兩百毫秒降低到兩毫秒以下。
• 緩存***率從 92% 提升到了 99% 以上。
• 解析失敗率之前是 1%，現在基本上沒有了。

優化的效果也體現在我們的風控服務上，平均延遲下降 10ms，服務超時比例下降 25%，降低了因延遲或服務超時導致的用戶上傳的圖片或文字違規但未被審核到的風險。

服務注冊的實踐

虎牙的核心業務是跑在 Tars(騰訊開源的一款微服務框架) 上的。

Tars 主要是支持 C++，但對 Java、PHP 等開發語言的支持力度比較差，這就使得我們非 C++ 的業務方去調用它就會很別扭。

引入 Nacos 以后，我們通過 Nacos 支持的 DNS 協議來實現服務發現過程中對全語言的支持。

當然，Nacos 不只是一個注冊中心，它具備了融合多個數據中心的能力，支持多數據源的同步。

例如，我們目前已經支持了 Taf(虎牙內部的一個重要微服務體系)、Nacos 自身、ZooKeeper、以及 K8S 上一些服務注冊的同步。

 

同時，基于 Nacos 集群的雙向同步功能(Nacos-Sync)，我們實現了國內的兩個可用區，以及國外的多個可用區之間的數據值同步，最終實現了一處注冊、多地可讀。

Nacos-Sync 是事件機制，即同步任務通過事件觸發，可以靈活地開啟和關閉你要同步的任務，然后根據服務變化事件觸發監聽，保證實時性，***通過定時的全量突發同步事件，保證服務數據的最終一致。

同時，Nacos-Sync 也支持服務心跳維持，即多個數據中心的心跳，可以使用 Nacos-Sync 代理來實現遠端同步。此外，也支持心跳與同步任務綁定，便于靈活控制。

由于 Taf 上有數萬個注冊服務，同步的量特別大，所以我們在 Nacos-Sync 做了一些改造，通過任務分片來實現數萬服務同步的可用性保障。

改造步驟是先以服務為粒度定義任務，然后在多個分片上分散任務負載，***以單分片多副本來保證任務可用性。

對接 CMDB，實現就近訪問

在服務進行多機房或者多地域部署時，跨地域的服務訪問往往延遲較高，一個城市內的機房間的典型網絡延遲在 1ms 左右，而跨城市的網絡延遲，例如上海到北京大概為 30ms。

此時自然而然的一個想法就是能不能讓服務消費者和服務提供者進行同地域訪問。

Nacos 定義了一個 SPI 接口，里面包含了與第三方 CMDB 約定的一些方法。

用戶依照約定實現了相應的 SPI 接口后，將實現打成 Jar 包放置到 Nacos 安裝目錄下，重啟 Nacos 即可讓 Nacos 與 CMDB 的數據打通。

 

在實際的落地過程中，我們是在 DNS-F 接入 Taf，在 DNS-F 上實現 Taf 的中控接口，無縫對接 Taf 的 SDK。

DNS-F 提供緩存負載均衡和實例信息，Nacos 則提供負載均衡信息的查詢接口。

服務配置的實踐

虎牙的域名(www.huya.com)會接入華南、華中、華北多個 IDC 機房，每個機房都會建設一個 Nginx 去做負載均衡，經過負載均衡的流量會通過專線返回到我們的后端服務器上。

在這個過程中，如果我們去修改一個在中間的配置，需要下發到多個機房的上百個負責負載均衡的機器上。

如果出現配置下發不及時，或下發配置失敗，極大可能會出現故障，同時，負責均衡服務的機器對彈性能力的要求較高，在業務高峰如果不能快速擴容，容易出現全網故障。

 

傳統的配置下發方式是通過服務端下發文件更新配置，更新配置生效時間長，由于需要預先知道負責均衡集群的機器信息，擴縮容需要等元信息同步以后才能接入流量，擴容流量的接入時間較長。

引入 Nacos 后，我們采用了配置中心監聽方式，通過客戶端主動監聽配置更新，配置便可秒級生效，新擴容服務主動拉取全量配置，流量接入時長縮短 3 分鐘+。

Nacos 改造和升級總結

引入 Nacos 的過程中，我們所做的改造和升級總結如下：

①在 DNS-F 上，我們增加了對外部域名的預緩存的支持，Agent 的監控數據對接到公司的內部監控，日志輸出也對接到內部的日志服務，然后和公司的 CMDB 對接，并實現了 DNS-F Cluster 集群。

我們之所以去構建一個 DNS-FCluster 集群，是為了避免內存、硬盤或版本問題導致的 DNS 服務無效，有了 DNS-F Cluster 集群，當本地 Agent 出現問題的時候，就可以通過集群去代理和解析 DNS 請求。

②在 Nacos-Sync 上，我們對接了 TAF 注冊服務和 K8S 注冊服務，以及解決了多數據中心環形同步的問題。

③在 Nacos CMDB 上，我們對 Nacos CMDB 進行了擴展，對接了虎牙自己的 CMDB，并對接了內部的負載均衡策略。