我們已經(jīng)學(xué)習(xí)了有關(guān)從架構(gòu)設(shè)計(jì)層面去應(yīng)對流量壓力的相關(guān)內(nèi)容。大家都知道，像直播這類服務(wù)呀，其用戶流量是很難預(yù)先準(zhǔn)確估計(jì)的。一旦用戶流量增大到某個(gè)程度，達(dá)到一個(gè)機(jī)房沒辦法承受的時(shí)候，那就得采取動(dòng)態(tài)調(diào)度的措施啦，也就是要把一部分用戶合理地分配到多個(gè)機(jī)房當(dāng)中去。

而且呢，隨著流量不斷增大，網(wǎng)絡(luò)出現(xiàn)不穩(wěn)定狀況的可能性也會跟著提高哦。在這種情況下，只有確保用戶能夠訪問到距離他們較近的機(jī)房，才能讓用戶獲得更好的使用體驗(yàn)呀。

綜合考慮以上這些因素呢，在這節(jié)課里，我們就著重來探討一下流量調(diào)度以及數(shù)據(jù)分發(fā)方面的關(guān)鍵技術(shù)，目的就是幫助大家清楚地了解要怎樣才能妥善地完成多個(gè)機(jī)房之間的流量切換工作。

直播服務(wù)所涉及的流量主要可以分為兩種類型哦，一種是靜態(tài)文件的訪問流量，另一種則是直播流所產(chǎn)生的流量。對于這兩種流量呢，都可以借助 CDN（內(nèi)容分發(fā)網(wǎng)絡(luò)）進(jìn)行分發(fā)處理，這樣就能有效地減輕我們服務(wù)端所承受的壓力啦。

對于直播這種讀操作和寫操作都比較頻繁的服務(wù)而言呀，動(dòng)態(tài)流量調(diào)度以及數(shù)據(jù)緩存分發(fā)可是解決大量用戶在線互動(dòng)問題的重要基礎(chǔ)呢。不過呢，它們在功能方面和 DNS（域名系統(tǒng)）是存在重合之處的，所以需要相互配合著來實(shí)現(xiàn)相關(guān)功能哦。因此呢，在接下來的講解過程中，也會適當(dāng)?shù)卮┎尻P(guān)于 CDN 的相關(guān)介紹內(nèi)容哦。

DNS 域名解析及緩存

服務(wù)流量切換并沒有想象中那么簡單，因?yàn)槲覀儠龅揭粋€(gè)很大的問題，那就是 DNS 緩存。DNS 是我們發(fā)起請求的第一步，如果 DNS 緩慢或錯(cuò)誤解析的話，會嚴(yán)重影響讀多寫多系統(tǒng)的交互效果。那 DNS 為什么會有刷新緩慢的情況呢？這需要我們先了解 DNS 的解析過程，你可以對照下圖聽我分析：

圖片

客戶端或?yàn)g覽器發(fā)起請求時(shí)，第一個(gè)要請求的服務(wù)就是 DNS，域名解析過程可以分成下面三個(gè)步驟：

1. 客戶端會請求 ISP 商提供的 DNS 解析服務(wù)，而 ISP 商的 DNS 服務(wù)會先請求根 DNS 服務(wù)器；

2. 通過根 DNS 服務(wù)器找到.org頂級域名 DNS 服務(wù)器；

3. 再通過頂級域名服務(wù)器找到域名主域名服務(wù)器（權(quán)威 DNS）。

找到主域名服務(wù)器后，DNS 就會開始解析域名。

一般而言，主域名服務(wù)器是由我們所托管域名的服務(wù)商來提供的。

就域名的具體解析規(guī)則以及 TTL（生存時(shí)間）時(shí)間來講，這些都是需要我們在域名托管服務(wù)商的管理系統(tǒng)當(dāng)中去進(jìn)行設(shè)置的。

當(dāng)有對主域名解析服務(wù)發(fā)起請求的時(shí)候，主域名服務(wù)器便會返回服務(wù)器所在機(jī)房的入口 IP 地址，同時(shí)還會給出建議緩存的 TTL 時(shí)間，只有到這個(gè)時(shí)候，DNS 解析查詢的流程才可以說是完成了。

接下來，在主域名服務(wù)將結(jié)果返回給 ISP（互聯(lián)網(wǎng)服務(wù)提供商）DNS 服務(wù)之時(shí)，ISP 的 DNS 服務(wù)會首先依照 TTL 所規(guī)定的時(shí)間，把這個(gè)解析結(jié)果緩存到自身服務(wù)本地，然后才會把解析結(jié)果再返回給客戶端。

在 ISP DNS 緩存的 TTL 有效期范圍之內(nèi)，要是遇到同樣的域名解析請求，那么就都會直接從 ISP 的緩存當(dāng)中返回結(jié)果了。

可以想象得到的是，客戶端通常也會把 DNS 解析結(jié)果給緩存下來。并且在實(shí)際進(jìn)行操作的時(shí)候，很多客戶端并不會按照 DNS 所建議緩存的 TTL 時(shí)間去執(zhí)行，而是會優(yōu)先依照自身所配置的時(shí)間來操作。

與此同時(shí)，在數(shù)據(jù)傳輸途徑當(dāng)中的 ISP 服務(wù)商也會對相應(yīng)的緩存情況予以記錄。要是我們對域名的解析做出了改變，那么要想獲得更新的話，最快也得需要服務(wù)商去刷新自己服務(wù)器所花費(fèi)的時(shí)間（一般來說大概需要 3 分鐘），再加上 TTL 時(shí)間才行。

事實(shí)上比較糟糕的情況是下面這樣：

// 全網(wǎng)刷新域名解析緩存時(shí)間
客戶端本地解析緩存時(shí)間30分鐘 
 + 市級 ISP DNS緩存時(shí)間 30分鐘 
 + 省級 ISP DNS緩存時(shí)間 30分鐘 
 + 主域名服務(wù)商 刷新解析服務(wù)器配置耗時(shí) 3分鐘 
 + ... 后續(xù)ISP子網(wǎng)情況 略 
= 域名解析實(shí)際更新時(shí)間 93分鐘以上

基于上述情況，不少域名解析服務(wù)都給出了這樣的建議：把 TTL 的設(shè)置時(shí)長控制在 30 分鐘以內(nèi)為宜。并且呀，許多大型互聯(lián)網(wǎng)公司還會在客戶端的緩存設(shè)置方面采取措施，會人為地去縮短緩存時(shí)間。

要是您所設(shè)置的 TTL 時(shí)間過短的話，雖然域名解析的刷新速度確實(shí)會比較快，可這也會致使服務(wù)請求變得很不穩(wěn)定哦。從理想狀態(tài)來講呢，93 分鐘算是比較合適的時(shí)長。不過根據(jù)過往經(jīng)驗(yàn)來看呀，正常情況下對域名做出修改之后，全國范圍內(nèi)的 DNS 緩存要全部更新完畢，大概得需要花費(fèi) 48 小時(shí)的時(shí)間呢；而要是想讓全世界的 DNS 緩存都更新好，那就得需要 72 小時(shí)啦。所以呢，不到實(shí)在沒辦法的時(shí)候，可千萬不要輕易去變更主域名解析哦。

要是碰到需要緊急刷新 DNS 緩存的情況呀，我這邊給您個(gè)建議，您可以去購買那種能夠強(qiáng)制推送解析的服務(wù)，用它來對主干 ISP 的 DNS 緩存進(jìn)行刷新操作。但是呢，得注意一下哦，這種服務(wù)不但價(jià)格很貴，而且它所能覆蓋到的范圍也只是主要城市的主干線路而已呀，對于個(gè)別地區(qū)來說，依然還是會存在刷新速度比較緩慢的情況呢，具體的刷新速度快慢可就得取決于寬帶服務(wù)商啦。不過總體來講的話，它確實(shí)還是能夠在一定程度上加快 DNS 緩存的刷新速度的。

DNS 刷新緩慢這個(gè)問題呀，真的是給我們帶來了諸多困擾呢。就好比說我們要是進(jìn)行故障切換的話，得需要花費(fèi)三天的時(shí)間才能夠徹底完成切換操作呀，很明顯，這對于系統(tǒng)的可用性而言，那可就是毀滅性的打擊啦。

好在呢，到了近代出現(xiàn)了不少能夠彌補(bǔ)這個(gè)問題的技術(shù)哦，比如說 CDN 呀、GTM 呀、HttpDNS 等等這些服務(wù)呢。接下來呀，咱們就依次來了解一下這些服務(wù)吧。

CDN 全網(wǎng)站加速

可能你會奇怪“為什么加快刷新 DNS 緩存和 CDN 有關(guān)系？”在講如何實(shí)現(xiàn) CDN 加速之前，我們先了解下 CDN 和它的網(wǎng)站加速技術(shù)是怎么回事。網(wǎng)站加速對于讀多寫多的系統(tǒng)很重要，一般來說，常見的 CDN 提供了靜態(tài)文件加速功能，如下圖：

在用戶向 CDN 服務(wù)發(fā)起請求的時(shí)候，CDN 服務(wù)首先會選擇返回其本地緩存當(dāng)中所存儲的靜態(tài)資源。

要是 CDN 本地并沒有對相關(guān)資源進(jìn)行緩存，又或者該資源屬于動(dòng)態(tài)內(nèi)容，比如 API 接口這類的情況，那么 CDN 就會執(zhí)行回源操作，也就是回到我們的服務(wù)器那里，然后從我們的服務(wù)器當(dāng)中去獲取所需的資源。

與此同時(shí)呢，CDN 會依據(jù)我們服務(wù)端所返回的資源超時(shí)時(shí)間來對本地緩存進(jìn)行刷新操作。通過這樣的方式呀，能夠極大幅度地減輕我們機(jī)房在提供靜態(tài)數(shù)據(jù)服務(wù)時(shí)所承受的壓力，并且還可以節(jié)省下大量用于帶寬以及硬件資源方面的投入呢。

除了具備加速靜態(tài)資源的功能之外呀，CDN 還開展了區(qū)域化的本地 CDN 網(wǎng)絡(luò)加速服務(wù)呢，具體的情況就如同下面所展示的圖片那樣哦。

CDN 會在各個(gè)主要的省市當(dāng)中布置用于加速服務(wù)的機(jī)房哦，并且呀，這些機(jī)房相互之間是會憑借高速專線來實(shí)現(xiàn)互聯(lián)互通的呢。

當(dāng)客戶端向 DNS 發(fā)出進(jìn)行域名解析的請求時(shí)，客戶端所在省市的 DNS 服務(wù)就會借助 GSLB（全局服務(wù)器負(fù)載均衡）的功能，返回給當(dāng)前用戶其所在省市距離最近的 CDN 機(jī)房的 IP 地址呀。

采用這樣的方式呢，是能夠極大地減少用戶與機(jī)房之間所存在的網(wǎng)絡(luò)鏈路節(jié)點(diǎn)的數(shù)量的哦，這樣一來呀，就可以加快網(wǎng)絡(luò)的響應(yīng)速度啦，而且還能夠降低網(wǎng)絡(luò)請求被攔截的這種可能性呢。

客戶端請求服務(wù)的路徑效果如下圖所示：

當(dāng)用戶所請求的是全站加速網(wǎng)站的那些動(dòng)態(tài)接口時(shí)，CDN 節(jié)點(diǎn)會借助 CDN 內(nèi)網(wǎng)，通過最短且最快的網(wǎng)絡(luò)鏈路，把用戶的請求轉(zhuǎn)接到我們的機(jī)房服務(wù)器那邊。相較于客戶端要從外省經(jīng)過多個(gè) ISP 服務(wù)商的網(wǎng)絡(luò)進(jìn)行層層轉(zhuǎn)發(fā)，之后才能向服務(wù)器發(fā)出請求的這種方式而言，采用上述通過 CDN 節(jié)點(diǎn)轉(zhuǎn)接的做法，能夠更有效地應(yīng)對網(wǎng)絡(luò)速度緩慢的問題，進(jìn)而為客戶端提供更為優(yōu)質(zhì)的用戶體驗(yàn)。

在網(wǎng)站完成全站加速之后呢，所有用戶發(fā)出的請求都會由 CDN 來進(jìn)行轉(zhuǎn)發(fā)處理，而且客戶端所請求的全部域名也都會指向 CDN，隨后再由 CDN 將這些請求轉(zhuǎn)至我們的服務(wù)端。

在此過程當(dāng)中，如果機(jī)房對 CDN 所提供服務(wù)的 IP 地址做出了變更，為了能夠加快 DNS 緩存的刷新速度，我們可以運(yùn)用 CDN 內(nèi)網(wǎng) DNS 的服務(wù)（此服務(wù)是由 CDN 供應(yīng)商所提供的）來對 CDN 中的 DNS 緩存進(jìn)行刷新操作。如此一來，客戶端這邊的 DNS 解析情況是不會發(fā)生改變的，也就不用像往常那樣等待 48 小時(shí)，域名的刷新操作會變得更加便捷。

正是由于存在需要 48 小時(shí)才能刷新緩存的這個(gè)問題，所以大多數(shù)互聯(lián)網(wǎng)公司在進(jìn)行機(jī)房切換的時(shí)候，都不會選擇通過更改 DNS 解析配置的方式來開展故障切換工作，而是會依靠 CDN 來實(shí)現(xiàn)類似的功能。

不過呢，要是 CDN 的入口出現(xiàn)了故障，那么對網(wǎng)站服務(wù)所造成的影響也是相當(dāng)大的。在國外，為了降低入口出現(xiàn)故障的可能性，會配合著使用 anycast 技術(shù)。通過運(yùn)用 anycast 技術(shù)，能夠讓多個(gè)機(jī)房的服務(wù)入口都擁有相同的 IP 地址，這樣的話，一旦其中一個(gè)入口發(fā)生了故障，運(yùn)營商便會把流量轉(zhuǎn)接到另外的機(jī)房當(dāng)中。然而，在國內(nèi)，出于安全方面的考慮，并不支持 anycast 技術(shù)。

除了 CDN 入口有可能出現(xiàn)故障的風(fēng)險(xiǎn)之外，當(dāng)請求流量進(jìn)入到 CDN 之后，要是 CDN 本地既沒有對相關(guān)內(nèi)容進(jìn)行緩存，又需要回源，并且本地的網(wǎng)站服務(wù)也同時(shí)發(fā)生了故障，那么就會出現(xiàn)無法自動(dòng)將源切換到多個(gè)機(jī)房的問題。所以呀，為了提升服務(wù)的可用性，我們可以考慮在 CDN 的后方增設(shè) GTM（全局流量管理）。

GTM 全局流量管理

在了解 GTM 和 CDN 的組合實(shí)現(xiàn)之前，我先給你講講 GTM 的工作原理和主要功能。GTM 是全局流量管理系統(tǒng)的簡稱。我畫了一張工作原理圖幫你加深理解：

圖片

當(dāng)客戶端發(fā)出對服務(wù)域名進(jìn)行請求的操作時(shí)，其首先會向 DNS 服務(wù)發(fā)起請求，目的是對所請求的域名進(jìn)行解析。而在客戶端請求主域名 DNS 服務(wù)來開展域名解析工作的時(shí)候，實(shí)際上會請求到 GTM 服務(wù)所具備的智能解析 DNS。

相較于傳統(tǒng)的相關(guān)技術(shù)而言，GTM 額外增添了三個(gè)功能，分別是服務(wù)健康監(jiān)控、多線路優(yōu)化以及流量負(fù)載均衡。

先來說說服務(wù)健康監(jiān)控功能。GTM 會對服務(wù)器的工作狀態(tài)予以監(jiān)控，一旦察覺到某個(gè)機(jī)房出現(xiàn)沒有響應(yīng)的情況，就會自動(dòng)將流量切換至處于健康狀態(tài)的機(jī)房。并且在此基礎(chǔ)之上，GTM 還提供了故障轉(zhuǎn)移功能，具體來講，就是依據(jù)機(jī)房的能力以及所設(shè)定的權(quán)重等因素，將一部分用戶流量轉(zhuǎn)移到其他的機(jī)房當(dāng)中。

接著是多線路優(yōu)化功能。在國內(nèi)，寬帶存在著不同的服務(wù)提供商，像移動(dòng)、聯(lián)通、電信、教育寬帶等等。不同寬帶的用戶在訪問由其所屬同一家服務(wù)提供商所提供的網(wǎng)站入口 IP 時(shí)，往往能夠獲得最佳的訪問性能；而要是跨服務(wù)商進(jìn)行訪問的話，就會由于需要進(jìn)行跨網(wǎng)轉(zhuǎn)發(fā)操作，從而致使請求延遲有所增加。所以呢，通過使用 GTM，就能夠依據(jù)不同機(jī)房的 CDN 來源，進(jìn)而找到速度更快的訪問路徑。

最后是流量負(fù)載均衡功能。GTM 會根據(jù)對服務(wù)的流量以及請求延遲情況所進(jìn)行的監(jiān)控結(jié)果，來對流量進(jìn)行合理分配，以此實(shí)現(xiàn)智能化地對客戶端流量進(jìn)行調(diào)度的目的。

當(dāng) GTM 和 CDN 網(wǎng)站加速這兩項(xiàng)服務(wù)相互結(jié)合之后，能夠產(chǎn)生更為出色的效果，具體的組合方式就如同下面所展示的圖片那樣：

圖片

HttpDNS 服務(wù)

HttpDNS 服務(wù)具備這樣的能力，它能夠讓我們繞開由本地 ISP 所提供的 DNS 服務(wù)，如此一來，便可以有效防止出現(xiàn) DNS 劫持的情況，而且它不存在 DNS 域名解析刷新方面的困擾。

同樣的，HttpDNS 也為我們提供了 GSLB（全局服務(wù)器負(fù)載均衡）功能。除此之外，HttpDNS 還能夠支持自定義解析服務(wù)，借助這一特性，我們就可以實(shí)現(xiàn)灰度測試或者 A/B 測試等操作。

通常情況下，HttpDNS 僅僅能夠解決 App 端的服務(wù)調(diào)度相關(guān)問題。所以呢，當(dāng)客戶端程序使用了 HttpDNS 服務(wù)時(shí)，為了妥善應(yīng)對因 HttpDNS 服務(wù)出現(xiàn)故障而引發(fā)的域名解析失敗的狀況，還需要提前準(zhǔn)備好備選方案才行。

在這里呢，我給大家提供一個(gè)關(guān)于解析服務(wù)的備選參考順序：一般而言，會首先優(yōu)先選用 HttpDNS；要是它無法正常工作了，接下來就會使用指定了 IP 地址的 DNS 服務(wù)；要是這也不行，最后才會考慮使用本地 ISP 商所提供的 DNS 服務(wù)。通過這樣的安排，可以極大幅度地提升客戶端 DNS 的安全性。

當(dāng)然啦，我們還可以選擇開啟 DNS Sec 來進(jìn)一步增強(qiáng) DNS 服務(wù)的安全性。不過呢，上述所提到的所有服務(wù)，我們都得結(jié)合自身實(shí)際的預(yù)算情況以及所能夠投入的時(shí)間和精力等多方面因素，來進(jìn)行綜合考量并做出決策。

需要注意的是，HttpDNS 這個(gè)服務(wù)可不是免費(fèi)的哦，特別是對于大企業(yè)來講，其使用成本會更高一些。這是因?yàn)楹芏?HttpDNS 服務(wù)商在提供查詢服務(wù)的時(shí)候，是會按照請求次數(shù)來收取費(fèi)用的。

所以呀，為了能夠節(jié)約成本，我們會想辦法去減少請求的數(shù)量。在此建議大家，在使用 App 的時(shí)候，可以根據(jù)客戶端所鏈接網(wǎng)絡(luò)的 IP 地址以及熱點(diǎn)名稱（比如 Wifi、5G、4G 等）作為標(biāo)識，來做一些相應(yīng)的 DNS 緩存操作。

業(yè)務(wù)自實(shí)現(xiàn)流量調(diào)度

一、HttpDNS 服務(wù)的局限與業(yè)務(wù)調(diào)度相關(guān)情況

HttpDNS 服務(wù)雖然能夠解決 DNS 污染的問題，但其無法參與到我們的業(yè)務(wù)調(diào)度當(dāng)中。所以當(dāng)我們依據(jù)業(yè)務(wù)需求開展管控調(diào)度工作時(shí)，它所能給予的支持是比較有限的。

二、基于 HttpDNS 原理實(shí)現(xiàn)的流量調(diào)度服務(wù)及常見實(shí)現(xiàn)方式

為了給用戶帶來更好的體驗(yàn)，互聯(lián)網(wǎng)公司參照 HttpDNS 的原理實(shí)現(xiàn)了流量調(diào)度功能。就拿很多難以對用戶流量進(jìn)行有效控制的直播服務(wù)來說，它們就實(shí)現(xiàn)了類似 HttpDNS 的流量調(diào)度服務(wù)。

這種調(diào)度服務(wù)常見的實(shí)現(xiàn)方式是：由客戶端向調(diào)度服務(wù)發(fā)起請求，隨后調(diào)度服務(wù)會將客戶端調(diào)配到距離較近的機(jī)房。

三、調(diào)度服務(wù)的故障轉(zhuǎn)移及提高自身可用性的做法

該調(diào)度服務(wù)還具備機(jī)房故障轉(zhuǎn)移的能力。當(dāng)服務(wù)器集群出現(xiàn)故障時(shí)，客戶端請求機(jī)房就會出現(xiàn)諸如失敗、卡頓、延遲等情況，此時(shí)客戶端會主動(dòng)向調(diào)度服務(wù)發(fā)出請求。倘若調(diào)度服務(wù)接收到了切換機(jī)房的指令，便會向客戶端返回健康機(jī)房的 IP 地址，以此來提升服務(wù)的可用性。

不僅如此，調(diào)度服務(wù)自身也需要提高可用性。具體的做法是將調(diào)度服務(wù)部署在多個(gè)機(jī)房，并且多個(gè)調(diào)度機(jī)房會通過 Raft 強(qiáng)一致協(xié)議來同步用戶調(diào)度結(jié)果策略。

例如，當(dāng)一個(gè)用戶請求 A 機(jī)房的調(diào)度服務(wù)后，被調(diào)度到了北京機(jī)房，那么在短期內(nèi)，即便該用戶再次請求 B 機(jī)房的調(diào)度服務(wù)，仍舊會被調(diào)度到北京機(jī)房。只有在客戶端切換網(wǎng)絡(luò)或者我們的服務(wù)機(jī)房出現(xiàn)故障的情況下，才會對流量進(jìn)行統(tǒng)一的變更。

四、輔助數(shù)據(jù)對調(diào)度服務(wù)決策的支持及相關(guān)情況

為了提升客戶端的用戶體驗(yàn)，我們需要將客戶端調(diào)配到距離近且響應(yīng)性能最佳的機(jī)房。為此，我們需要一些輔助數(shù)據(jù)來為調(diào)度服務(wù)分配客戶端提供支撐，這些輔助數(shù)據(jù)包括 IP、GPS 定位、網(wǎng)絡(luò)服務(wù)商、ping 網(wǎng)速、實(shí)際播放效果等。

客戶端會定期收集這些數(shù)據(jù)，并將其反饋給大數(shù)據(jù)中心進(jìn)行分析計(jì)算，以便為調(diào)度服務(wù)提供參考建議，從而幫助調(diào)度服務(wù)更好地做出關(guān)于當(dāng)前應(yīng)該鏈接哪個(gè)機(jī)房以及對應(yīng)的線路的決策。

實(shí)際上，這么做就相當(dāng)于自行實(shí)現(xiàn)了 GSLB 功能。不過，自行實(shí)現(xiàn) GSLB 功能所依據(jù)的數(shù)據(jù)并非絕對準(zhǔn)確無誤。因?yàn)椴煌∈械?DNS 服務(wù)解析出來的結(jié)果往往存在差異，而且如果客戶端無法聯(lián)通，就需要根據(jù)推薦的 IP 挨個(gè)嘗試，以此來確保服務(wù)的高可用性。

五、調(diào)度穩(wěn)定性驗(yàn)證及直播、視頻相關(guān)調(diào)度功能

為了驗(yàn)證調(diào)度是否穩(wěn)定，我們可以在客戶端暫存調(diào)度結(jié)果，并且在每次客戶端請求時(shí)，在請求頭（header）中帶上當(dāng)前調(diào)度的結(jié)果。通過這種方式，就能在服務(wù)端監(jiān)控是否存在客戶端錯(cuò)誤請求到其他機(jī)房的情況。

一旦發(fā)現(xiàn)錯(cuò)誤的請求，可以通過機(jī)房網(wǎng)關(guān)采取類似 CDN 全站加速那樣的反向代理轉(zhuǎn)發(fā)措施，以此來確保客戶端的穩(wěn)定。

對于直播和視頻業(yè)務(wù)，同樣也需要開展類似調(diào)度的功能。當(dāng)我們播放視頻或者進(jìn)行直播時(shí)，倘若出現(xiàn)監(jiān)控視頻卡頓等情況，客戶端應(yīng)能夠自動(dòng)切換視頻源，同時(shí)將相關(guān)情況上報(bào)給大數(shù)據(jù)中心進(jìn)行記錄分析。要是發(fā)現(xiàn)大規(guī)模視頻卡頓的情況，大數(shù)據(jù)中心會向我們的運(yùn)維和研發(fā)伙伴發(fā)送警報(bào)。

圖片

域名作為我們服務(wù)的關(guān)鍵入口，當(dāng)對一個(gè)域名發(fā)起請求時(shí)，第一步就是要經(jīng)由 DNS 把域名解析為 IP 地址。然而，要是過于頻繁地去請求 DNS，那么這將會對服務(wù)的響應(yīng)速度產(chǎn)生不利影響。所以呢，許多客戶端以及 ISP 服務(wù)商都會針對 DNS 設(shè)置緩存機(jī)制。但恰恰是這種多層級的緩存設(shè)置，直接致使刷新域名解析的操作變得極為困難。

即便我們愿意花錢去刷新多個(gè)帶寬服務(wù)商那里的緩存，可在某些個(gè)別區(qū)域，仍然至少需要等待 48 個(gè)小時(shí)，才能夠完成對大部分用戶的緩存刷新工作。要是因?yàn)榫W(wǎng)站出現(xiàn)故障等特殊原因，我們必須要對 IP 進(jìn)行切換的話，那么由此帶來的影響可就堪稱是災(zāi)難性的了。

好在近些年來，我們能夠借助 CDN、GTM、HttpDNS 這些技術(shù)手段，來強(qiáng)化針對多機(jī)房的流量調(diào)度能力。不過需要注意的是，CDN 和 GTM 主要是針對機(jī)房進(jìn)行調(diào)度安排，對于業(yè)務(wù)方而言，它們的調(diào)度過程是透明不可見的。

因此，在那些更加注重用戶體驗(yàn)并且存在高并發(fā)情況的場景當(dāng)中，我們往往會自行去實(shí)現(xiàn)一套專門的調(diào)度系統(tǒng)。在這種自行實(shí)現(xiàn)的方案里，大家會察覺到，其思路和 HttpDNS 以及 GSLB 的思路頗為相似。它們之間的區(qū)別在于，之前的那些服務(wù)僅僅屬于基礎(chǔ)服務(wù)，而我們自行實(shí)現(xiàn)的服務(wù)還能夠迅速且有效地幫助我們對用戶流量進(jìn)行調(diào)度安排。

通過 HttpDNS 來實(shí)現(xiàn)讓用戶切換機(jī)房、切換視頻流的操作，無疑是非常便捷簡單的。只需要在我們 App 發(fā)送請求進(jìn)行封裝的時(shí)候，對鏈接的 IP 地址做出更改，就能夠在業(yè)務(wù)不受影響的情況下，完成機(jī)房的切換操作。