淘寶CDN全局流量調度算法

　1、流量調度的基本流程

　　目前CDN系統流量調度是經過DNS解析來實現的，其基本原理以下圖1所示。

　　用戶想要訪問某個圖片的url，分爲四步：

　   一、用戶來自某個區域（如Beijing TelCom）的用戶，想訪問特定Url（如），應該去哪一個IP地址訪問
      二、TGTM根據鏈路信息、成本信息或節點負載信息等因素，決定讓該區域的用戶訪問CDN 1節點
      三、用戶根據DNS解析返回的IP地址訪問CDN 1節點，並請求該圖片的內容
      四、CDN1節點接收並處理用戶的請求，而後將客戶請求的圖片返回

上面的流程是在用戶的瀏覽器或者LDNS(Local DNS)沒有對DNS解析結果進行緩存的狀況下的流程，對於有緩存的系統，瀏覽器會從緩存中取到域名解析結果，所以流量調度策略沒法影響已經緩存了DNS解析結果的用戶請求，這部分請求對應的訪問流量並不受調度系統的指揮，這對流量調度系統有必定的影響。

　　2、調度目標

　　CDN系統目前承載者淘寶網大約90%的流量，全局流量調度系統須要解決的問題是如何將如此大的訪問流量合理分配到分佈在各地的CDN邊緣節點。

　　對於全局流量調度系統而言，設計目標有兩個：

　　(1)提高用戶體驗
      (2)節約系統成本

　　這兩個目標自己都包含不少的方面，但提取其最核心的要求，分別對應

　　(1)下降用戶訪問CDN節點的延遲
       (2)下降CDN節點的帶寬成本

　　本文的內容就是圍繞這兩個目標來介紹的。

　　3、現有調度策略介紹

　　現有的CDN全局流量調度是經過商用的F5 BigIP GTM(之前稱爲3DNS)來實現的。F5的系統提供了Round Robin等12種局域負載均衡算法和Global Availability等15種廣域負載均衡算法，其中這些負載均衡算法按照調度策略是靜態配置仍是動態生成的分爲靜態調度方法和動態調度算法。具體的內容參考F5網站上的相關文檔 F5 Networks

　　目前淘寶CDN系統的流量調度採用的是Topology+ratio的策略，下面對該調度策略進行具體介紹。

　　3.1 基本概念介紹

　　下面的概念摘自百科上易統整理的文檔GSLB概念介紹

• CIDR

• 　　Classless InterDomain Routing ，是一種爲解決地址耗盡，提升地址的利用效率而提出的一種措施 218.30.29.0/25 218.30.28.0/25 218.30.27.0/25 218.30.26.0/2

• Region

• 　　一組CIDR組合後的名稱，主要是爲了配置和檢索方便 region_db user { region { name 「CDN_WangSu」 「FujianTelcom」 「GansuTelcom」 「HainanNetcom } region { name 「FujianTelcom」 218.85.157.0/24 220.162.0.0/16 211.148.224.0/19 220.160.0.0/15 }

• Topology

• 　　用於管理從Region到Pool之間的映射關係
  topology {
  // server ldns score
  pool.」img01_WangSu_pool」 user.」CDN_WangSu」 900
  pool.」img02_WangSu_pool」 user.」CDN_WangSu」 900
  pool.」img03_WangSu_pool」 user.」CDN_WangSu」 900
  pool.」img04_WangSu_pool」 user.」CDN_WangSu」 900
  pool.」img01_guangdongtel_pool」 user.」 TB_CDN_GZ_1_MB 」 900
  pool.」img02_guangdongtel_pool」 user.」 TB_CDN_GZ_1_MB 」 900
  }

• WideIP

• 　　客戶在使用CDN服務後將域名CNAME給CDN服務提供商的域名如imag是用戶的域名，在使用CDN服務後會CNAME到imag，後者就被稱爲wideip
  wideip {
  name 「img0」
  pool_lbmode topology
  partition 「Common」
  last resort
  pool 「img02_tel_pool」
  pool 「img02_southcnc_pool」
  pool 「img02_northcnc_pool
  }

• Pool

• 　　爲wideip服務的一組VIP或CNAME的集合
  pool {
  name 「img02_southcnc_pool」
  ttl 300
  monitor all 「tcp」
  preferred rr
  partition 「Common」
  member 218.108.237.202:80
  member 218.108.237.212:80
  }

• member

• 　　供Pool調度的基本元素，在CDN系統中，member用於表示一個CDN節點
  member 218.108.237.202:80

• VIP

• 　　Virtual IP 配置在四層交換上的公網IP和端口的組合，經過地址映射對應四層交換後一臺或多臺內網設備若是沒有四層交換，能夠借指設備上直接配置的公網IP和端口的組合與member元素相對應

　　3.2 基本對象之間的關係

　　上述基本對象的關係以下圖所示

• WideIP概念

• 　　

• Region，CIDR 之間關係圖

• 　　

• WideIP,Pool,member之間的關係

• 　　

• Pool和Region之間的Topology映射

• 　　

　　3.3 現有的流量調度方法

　　現有的系統工做流程是這樣的：
（1）管理員根據經驗預先設置好用戶區域的拓撲關係，並經過設置Topology定義好爲各個區域服務的Pool
（2）當一個DNS解析請求到達時，調度系統根據用戶LDNS的IP地址來判斷出該用戶所在區域，而後根據Topology的設定找出爲該區域服務的Pool
（3）當Pool中有多個member時，全部到達該pool的請求按照各個member的ratio值來進行分配。例如，系統中有3個member，其 ratio分別爲100,100,200，則到達該pool的全部請求將按照25%,25%和50%的比例分配到各個member

　　上述策略整體上能夠當作一種靜態的調度策略，當系統中出現節點不可用、節點過載或者特定區域訪問對應的節點延遲過大等狀況時，只能等到管理員發現後對配置文件進行必定的調整以後才能解決。

　　4、新的流量動態調度算法

　　根據文中第二部分提出的調度算法設計目標，爲當前系統設計了三種動態調度算法，分別是基於負載的調度算法，基於鏈路的調度算法和基於成本的調度算法。綜合考慮鏈路、成本和負載的調度算法還沒有進行設計和實現。

　　4.1 基於負載的調度算法

　　4.1.1 算法原理介紹

　　基於負載的調度算法是最先實現的一種調度算法，考慮的是在一組節點服務特定區域的用戶時，用戶訪問這些節點的鏈路情況接近、節點的帶寬成本也接近的前提下，如何保證訪問這些節點的流量在各個節點之間按照節點的實時負載能力來分配。

　　舉個例子來講，假設上海地區的電信用戶訪問cn12和cn15的鏈路情況相似，cn12和cn15的帶寬成本也接近，如何將上海地區電信用戶的訪問流量按照cn十二、cn15的實時負載能力來進行分配，以保證兩個節點的負載相對於其負載能力來講是均衡的。

　　基於負載的流量調度算法採用的是負反饋調度算法。負反饋是一種基於誤差的調度算法，簡而言之，當系統輸出同指望值不相等時，控制系統根據系統輸出和指望值之間的誤差來對系統施加控制做用，負反饋調度算法的框圖以下圖所示

　　

• 當輸出大於指望值時，誤差爲正，這時給系統一個負的控制量u（減少系統輸出）
• 當輸出小於指望值時，誤差爲負，這時給系統一個正的控制量u（增大系統輸出）

　　能夠看出，系統的控制量同誤差是一種負反饋的關係。

　　應用到基於負載的調度算法中來，當分配給某個節點的流量同其負載能力相比偏小時（誤差爲負），咱們應該增大分配給該節點的流量，反之，則減少分配給該節點的流量。

　　4.1.2 調度算法實現

　　基於負載的調度算法是創建在可以獲取節點的服務質量（QOS）的前提下，所以如何獲取節點的實時QOS是首先必須解決的一個問題。

　　目前CDN系統是經過部署在CDN節點內部的監控系統來獲取節點的實時QOS數據。QOS數據中最重要的兩項是節點的當前負載和節點的最大可用負載能力。節點的當前負載是經過統計交換機的出口流量獲得的，而最大可用負載則是根據各緩存服務器的健康情況得出的。

　　調度系統經過監控系統提供的Web Services接口實時查詢各個CDN節點的當前性能情況，而後根據負反饋調度算法生成流量分配策略。

　　

在必定偏差範圍內保持同一個pool內全部節點的ratio之和固定，記爲  RATIO_SUM，
設節點i的當前流量爲 cur_loadi
系統內當前的總流量爲 sumi=1-n(cur_load)
並設第i個ECC節點當前的負載能力（即上述的max_usable_load）記爲 max_usable_loadi，
pool內全部節點的當前負載能力之和記爲 sumi=1-n(max_usable_load)
則i節點在系統內應分擔的負載流量比例記爲
proportioni=max_usable_loadi/sumi=1-n(max_usable_load)
按照節點的當前負載能力，節點i的指望ratio是
ratioie=RATIO_SUM*proportioni
節點i的當前指望負載應爲
cur_loadie=sumi=1-n(cur_load)*proportioni
節點i的實際負載與指望負載的誤差爲
diffi=cur_loadi-cur_loadie
節點i當前ratio的調整值爲
delta_ratioi = -P*diffi/sumi=1-n(cur_load)*RATIO_SUM
同時，爲了防止流量調節過程當中各節點流量出現劇烈顛簸，設置各節點ratio的調節範圍爲
[(1-Th)*ratioie, (1+Th)*ratioie]
總結一下：

ratio(n+1) = ratio(n) + delta_ratioi
 = ratio(n)-P*diffi/sumi=1-n(cur_load)*RATIO_SUM
             = ratio(n)-P*(cur_loadi-cur_loadie)/sumi=1-n(cur_load)*RATIO_SUM
 = ratio(n)-P*(cur_loadi-sumi=1-n(cur_load)*proportioni)/sumi=1-n(cur_load)*RATIO_SUM
 = ratio(n)-P*(cur_loadi-sumi=1-n(cur_load)*(max_usable_loadi/sumi=1-n(max_usable_load)))/sumi=1-n(cur_load)*RATIO_SUM

　　if(ratio(n+1) = (1+Th)*ratioie)
{
ratio(n+1) = (1+Th)*ratioie;
}

上式中的P爲負反饋比例係數，能夠控制負載獲得指望值的時間，P越大，（在必定偏差範圍內）達到指望值的時間越短，同時系統流量的波動也越大。P過大甚至可能形成系統的不穩定。

　　4.2 基於鏈路的調度算法

　　4.2.1 整體介紹

　　基於鏈路的調度算法的最終目標是使得全網內各區域用戶訪問淘寶的延遲最小，這個問題是一個最優化的問題，實際解決起來很困難，只能隨着對系統瞭解的不斷深刻，逐步優化算法。

　　目前基於鏈路的調度算法的目標是儘可能保證用戶訪問淘寶的延遲在給定的閾值以內，也就是說，調度的目標是對訪問延遲提供必定的保證，但並不能作到最優。

　　基於鏈路的基本思想是將鏈路延遲超過閾值的流量調度到鏈路延遲較好的鏈路上去，以確保全部區域的用戶訪問鏈路延遲都較好。

　　同基於負載的調度算法相似，基於鏈路的調度算法須要節點和網絡的QOS數據，這裏除了須要獲取各個節點的當前負載、最大可用負載數據以外，還須要得到特定區域訪問CDN節點的鏈路延遲。

　　各個節點的當前負載、最大可用負載等QOS數據依然是經過部署在節點內部的監控系統獲取的，而各區域用戶訪問CDN節點的鏈路延遲數據則是經過淘寶的客戶端鏈路探測工具Aliprobe的探測結果統計獲得的。

　　目前鏈路探測的最主要數據有ping time和ping命令的丟包率，而區域和節點之間的鏈路信息則是經過綜合部署在指定區域的全部Aliprobe探測客戶端獲取的訪問指定節點的鏈路信息統計、綜合獲得的。

　　在基於鏈路的調度算法中，咱們對每個感興趣的調度區域，根據其地理位置和系統運維經驗爲其指定一個默認的服務節點和一組備選的服務節點，並將這些節點組成一個pool，該pool專門爲該區域的用戶服務。

　　基於鏈路的調度算法必須考慮到下列異常狀況：
（1）CDN節點的當前負載、最大可用負載等負載類QOS數據沒法獲取
（2）區域到節點的鏈路QOS數據沒法獲取
（3）節點不可用
（4）節點過載

　　4.2.2 算法的實現

　　基於鏈路的調度算法流程以下：

　　Step 1 調度週期開始，嘗試獲取節點的健康情況檢查結果、節點類的負載類QOS數據、區域同節點之間的鏈路類QOS數據

　　Step 2 遍歷全部感興趣的區域

　　2.1) 將當前區域的備選節點分爲如下四類：

　　class 1: good 節點健康、鏈路類QOS數據能獲得而且鏈路延遲沒有超過給定閾值、負載類QOS數據能獲得、節點沒有超載（全部good節點中鏈路延遲最小的一個節點叫作最佳備選節點）
class 2: bad 節點健康，鏈路類QOS數據能獲得而且鏈路延遲超過給定閾值
class 3: unhealthy 節點不健康
class 4: other 不屬於上面三類的節點

　　2.2） 處理區域的默認節點
2.2.1 若是默認節點不健康，則嘗試將默認節點的全部流量調度到備選節點中
2.2.1.1 若是該區域有good備選節點存在，則將默認節點的流量均分到全部good備選節點
2.2.1.2 不然，報警
2.2.2 若是區域用戶訪問默認節點的鏈路不佳，則嘗試將默認節點的一小部分流量（比例可配）調度到最佳備選節點中
2.2.2.1 若是該區域存在最佳備選節點，將默認節點的一小部分流量調度到該最佳備選節點
2.2.2.2 不然，報警

　　2.3） 處理區域的多個備選節點
2.3.1） 若是備選節點不健康
2.3.1.1） 若是默認節點能夠接收更多的流量，則將不健康節點的流量都切到默認節點上，不然轉下一步
2.3.1.2） 若是存在good備選節點，則將不健康節點的流量均分到good備選節點上，不然轉下一步
2.3.1.3） 報警
2.3.2） 若是備選節點鏈路很差
2.3.2.1） 若是默認節點能夠接收更多的流量，則將不健康節點流量的一部分切到默認節點上，不然轉下一步
2.3.2.2） 若是存在最佳備選節點，則將不健康節點流量的一部分切到最佳備選節點上，不然轉下一步
2.3.2.3） 不然，報警
2.3.3） 若是默認節點可以接受更多的流量
2.3.3.1） 若是存在good備選節點，則將全部good備選節點的部分流量切回默認節點
2.3.3.2） 若是存在other備選節點，則將全部other備選節點的部分流量切回默認節點

　　Step 3 遍歷全部過載節點

　　對於每個過載節點，首先報警，而後找出其所服務區域中全部不以該節點爲默認節點的區域，嘗試將區域流量的一部分切回區域對應的默認節點。若是找不到不以該節點爲默認節點的區域，則報警

　　Step 4 開始新一輪的調度，轉Step 1

　　其中， Step 2中根據鏈路延遲進行調度的流程以下圖所示：

　　

　　4.2.3 算法存在的問題

　　目前系統沒法得知某一區域用戶的訪問流量值，因此在本調度算法中將區域訪問流量在節點之間調度時的具體流量值是沒法獲得的，爲了防止調度過程當中流量出現大的波動，每一個調度週期調度的流量都會很小，但調度幅度小必然致使調度效果顯現的時間會比較長。

　　另外，目前基於鏈路的調度算法中會有一個比較關鍵的閾值（最大延遲，超過該閾值會認爲鏈路差，不然認爲鏈路好），該閾值是經過經驗設置的，但實際上這個值在不一樣的時間段，不一樣的網絡情況下應該是不一樣的，而且應該隨着時間的變化而變化，該閾值的設置仍有較大的改進空間。

　　4.3 基於成本的調度算法

　　4.3.1 CDN節點的帶寬成本模型

　　CDN的帶寬成本能夠分紅保底帶寬和流量成本兩部分。其中保底帶寬指的是隻要使用該節點就必須支付的費用，而流量成本指的是在保底帶寬之上，按照實際使用的流量來支付費用。節點的帶寬成本模型以下圖所示：

　　

　　4.3.2 算法設計和實現

　　基於成本的調度算法的目標是使得系統的帶寬成本最小，這裏採用的貪婪算法來實現流量的調度

　　算法簡述以下：

　　（1）若是系統當前總的流量小於全部節點的保底帶寬之和，則將流量按照各節點的保底帶寬佔全部保底帶寬之和的比來分配流量
（2）若是系統當前流量大於全部節點的保底帶寬之和，則首先將全部節點的保底帶寬使用滿，而後依次選取各節點中帶寬成本最低的節點，將該節點的負載能力用完爲止。

　　算法流程以下圖所示：

　　

　　在實際實現時，因爲調度過程當中流量有可能出現波動，因此必須保證出現波動時不會出現問題。舉例來講，若是某一節點的保底帶寬是1G，若是分配給該節點 的流量就是1G，但因爲流量出現波動，就會出現除了須要支付保底帶寬費用以外，還須要支付一部分超出保底帶寬的費用，這是咱們所不但願看到的。所以，咱們 在處理保底帶寬和階梯價格上限時留有必定的裕量。