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

相比文字和圖片，直播提供了人與人之間更豐富的溝通形式，其對平臺穩定性的考驗很大，那麼倡導“以技術驅動娛樂”的虎牙直播（以下簡稱“虎牙”）是如何在技術上賦能娛樂，本文將為您介紹虎牙在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則提供負載均衡資訊的查詢介面。

服務配置的實踐

---

虎牙的域名（）會接入華南、華中、華北多個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。