虎牙直播在微服務改造方面的實踐和總結

相比文字和圖片，直播提供了人與人之間更豐富的溝通形式，其對平臺穩定性的考驗很大，那么倡導“以技術驅動娛樂”的虎牙直播（以下簡稱“虎牙”）是如何在技術上賦能娛樂，本文將為您介紹虎牙在DNS、服務注冊、CMDB和服務配置中心等方面的實踐。

文章整理自虎牙基礎保障部中間件團隊負責人張波（社區ID：zhangjimmy）在Dubbo Meetup 廣州站沙龍上的分享，阿里巴巴中間件授權發布，分享議題如下：

???? 為什么選用Nacos

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

???? 服務注冊的實踐

???? CMDB的應用和實踐

???? 服務配置的實踐

為什么選用 Nacos

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

Nacos 是一個更易于幫助構建云原生應用的動態服務發現、配置和服務管理平臺，提供「注冊中心」、「配置中心」和「動態DNS服務」三大功能。公眾號對話框發送“Nacos”，進一步了解什么是Nacos。

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

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

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

其次，在服務配置中心方案的選型過程中，我們希望配置中心和注冊中心能夠打通，這樣可以省去我們在微服務治理方面的一些投入。因此，我們也同步比較了一些服務配置中心的開源方案：

例如Spring Cloud Config Server、Zookeeper和ETCD，總體評估下來，基于我們微服務體系現狀以及業務場景，我們決定使用Nacos作為我們的服務注冊和服務發現的方案。使用過程中，我們發現，隨著社區版本的不斷更新和虎牙的深入實踐，Nacos的優勢遠比我們調研過程中發現的更多，接下來，我將圍繞DNS-F、Nacos-Sync、 CMDB和負載均衡4方面來分享虎牙的實踐。

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：騰訊開源的一款微服務框架。

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，并對接了內部的負載均衡策略。

本文作者：張波，社區ID zhangjimmy，Nacos Committer，虎牙基礎保障部中間件團隊負責人，阿里云MVP。