爲何選用Nacos？虎牙直播微服務改造實踐

「

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

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

• 爲何選用 Nacos

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

• 服務註冊的實踐

• CMDB 的應用和實踐

• 服務配置的實踐

• Nacos 改造和升級總結

爲何選用 Nacos

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

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

首先，在虎牙的微服務場景中，起初有多個註冊中心，每個註冊中心服務於某一部分微服務，缺乏一個能融合多個註冊中心，並把他們逐一打通，而後實現一個能管理整個微服務體系的大的註冊中心。

小編分類整理了許多java進階學習材料和BAT面試題，須要資料的請加JAVA高階學習Q羣：8515318105；就能領取2019年java架構師進階學習資料和BAT面試題。

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

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

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

所以，咱們也同步比較了一些服務配置中心的開源方案：

例如 Spring Cloud Config Server、Zookeeper 和 ETCD，整體評估下來，基於咱們微服務體系現狀以及業務場景，咱們決定使用 Nacos 做爲咱們服務化改造中服務註冊和服務發現的方案。

使用過程當中，咱們發現，隨着社區版本的不斷更新和虎牙的深刻實踐，Nacos 的優點遠比咱們調研過程當中發現的更多。

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

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

小編分類整理了許多java進階學習材料和BAT面試題，須要資料的請加JAVA高階學習Q羣：8515318105；就能領取2019年java架構師進階學習資料和BAT面試題。

DNS-F 的技術價值

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

剛纔提到，虎牙有多個微服務體系，但並無一個微服務具有全局動態調度的能力，由於它們各自都是獨立的。

目前，咱們經過 Nacos 已經融合了四個微服務體系的註冊中心，最終目標是把全部的微服務都融合在一塊兒，實現全局動態調動的能力。

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

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

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

這樣就會無故的形成服務的延時和解析不許。即便咱們基於 DNS 作一些解析的優化，但仍然沒法徹底解決服務的延時和解析不許。

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

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

有了 Nacos 後，就能夠接入一個統一的註冊中心以及配置中心，去解決這些問題。（目前，虎牙還在微服務體系的改造過程當中，未徹底實現統一的註冊中心）

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

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

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

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

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

DNS-F 的應用場景

小編分類整理了許多java進階學習材料和BAT面試題，須要資料的請加JAVA高階學習Q羣：8515318105；就能領取2019年java架構師進階學習資料和BAT面試題。

這張圖是 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%，下降了因延遲或服務超時致使的用戶上傳的圖片或文字違規但未被審覈到的風險。

服務註冊的實踐

小編分類整理了許多java進階學習材料和BAT面試題，須要資料的請加JAVA高階學習Q羣：8515318105；就能領取2019年java架構師進階學習資料和BAT面試題。

虎牙的核心業務是跑在 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 則提供負載均衡信息的查詢接口。

服務配置的實踐

小編分類整理了許多java進階學習材料和BAT面試題，須要資料的請加JAVA高階學習Q羣：8515318105；就能領取2019年java架構師進階學習資料和BAT面試題。

虎牙的域名（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，並對接了內部的負載均衡策略。

小編分類整理了許多java進階學習材料和BAT面試題，須要資料的請加JAVA高階學習Q羣：8515318105；就能領取2019年java架構師進階學習資料和BAT面試題。