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

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

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

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

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

DNS 域名解析及緩存

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

圖片

客戶端或瀏覽器發(fā)起請求時，第一個要請求的服務就是 DNS，域名解析過程可以分成下面三個步驟：

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

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

3. 再通過頂級域名服務器找到域名主域名服務器（權威 DNS）。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

CDN 全網(wǎng)站加速

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

GTM 全局流量管理

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

圖片

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

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

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

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

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

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

圖片

HttpDNS 服務

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

實際上，這么做就相當于自行實現(xiàn)了 GSLB 功能。不過，自行實現(xiàn) GSLB 功能所依據(jù)的數(shù)據(jù)并非絕對準確無誤。因為不同省市的 DNS 服務解析出來的結果往往存在差異，而且如果客戶端無法聯(lián)通，就需要根據(jù)推薦的 IP 挨個嘗試，以此來確保服務的高可用性。

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

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

一旦發(fā)現(xiàn)錯誤的請求，可以通過機房網(wǎng)關采取類似 CDN 全站加速那樣的反向代理轉發(fā)措施，以此來確?？蛻舳说姆€(wěn)定。

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

圖片

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

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

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

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

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