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

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

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

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

對于直播這種讀操作和寫操作都比較頻繁的服務而言呀，動態流量調度以及數據緩存分發可是解決大量用戶在線互動問題的重要基礎呢。不過呢，它們在功能方面和 DNS（域名系統）是存在重合之處的，所以需要相互配合著來實現相關功能哦。因此呢，在接下來的講解過程中，也會適當地穿插關于 CDN 的相關介紹內容哦。

DNS 域名解析及緩存

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

圖片

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

CDN 全網站加速

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

GTM 全局流量管理

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

圖片

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

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

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

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

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

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

圖片

HttpDNS 服務

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

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

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

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

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

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

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

業務自實現流量調度

一、HttpDNS 服務的局限與業務調度相關情況

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

二、基于 HttpDNS 原理實現的流量調度服務及常見實現方式

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

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

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

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

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

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

四、輔助數據對調度服務決策的支持及相關情況

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

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

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

五、調度穩定性驗證及直播、視頻相關調度功能

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

一旦發現錯誤的請求，可以通過機房網關采取類似 CDN 全站加速那樣的反向代理轉發措施，以此來確保客戶端的穩定。

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

圖片

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

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

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

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

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