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

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

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

爲何選用Nacos

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

服務註冊的實踐

CMDB的應用和實踐

服務配置的實踐

爲何選用 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和負載均衡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。

其餘服務化改造實踐：網易考拉在服務化改造方面的實踐微衆銀行的金融級消息服務平臺建設實踐和思考消息規模超千億，同程藝龍的消息系統建設實踐滴滴出行基於RocketMQ構建企業級消息隊列服務的實踐