從靜態、動態到全站，看阿里雲「全站加速」的技術演進
所謂的抄近道，走的人多了，也就堵了。網路高速路亦是如此。
作者｜原丘
編輯｜IMMENSE
01 源起：「加速」的經典架構
CDN 並不是互聯網誕生之初就存在的。
當沒有 CDN 加速時，大量的用戶請求需要穿越互聯網骨幹網才能獲得源站的內容。
上世紀80年代，互聯網技術開始民用，人們主要通過撥號來訪問網路，由於用戶少、頻寬小，並沒有對骨幹網和伺服器帶來壓力。
隨著互聯網高速發展，使用互聯網的用戶數量出現井噴式增長，加之寬頻接入網的出現，內容源伺服器和骨幹網路的壓力越來越大。
由於網路距離遠以及骨幹網的網路擁塞問題，端到端的請求時延會非常長，無法及時響應用戶的訪問需求，這會嚴重影響用戶體驗。
在早期CDN架構設計中，核心的目標，是通過內容的分發來實現”加速”，本質邏輯就是將文件從源站「搬」到離用戶近的地方，縮短內容傳輸的物理距離來實現所謂的”加速”效果。
那麼基於這個前提和背景，技術上的重點，就是怎樣讓儘可能少的流量穿過邊緣集群回到源站，即儘可能的提高內容的命中率。
事實上，業界的廠商基本也都是在這個方面注入了最多的技術投入，盡量將訪問終結在邊緣，其次在上游增加快取層(很多廠商叫做中間源)，來”攔截”回源流量。
所以，經典的CDN靜態加速，節點架構按照分層的設計就順理成章了，即從邊緣->一級父層->…->N級父->源站。
使用 CDN 之後，由於大量請求在邊緣就可以找到其所需的內容，因此穿越互聯網骨幹網的流量大幅減少。
這樣，既有效減輕了骨幹網的流量壓力，也節省了SP(Service Provider，服務提供商)的頻寬成本，促進了互聯網業務的快速發展。
02 不足：動態場景下的失控
然而，在部分場景下，CDN經典技術架構並不是萬能的。
以電商、社交互動媒體、部落格為代表的互聯網業務，存在大量不能快取、需要實時回源的動態內容加速場景。
比如：電商平台涉及了用戶註冊、登錄、在線支付、秒殺等需要動態加速的場景。
從流量上來說，一個域名全網的流量，隨著層級的深入，流量逐級減少，最終從幾個節點回到源站，面對一些內容熱度比較高的情況，回源量會更少。
從微觀來講，一般的邏輯是把內容送到離客戶最近的邊緣節點。那麼，對於後續的父層節點來說(Parent Node)，依然遵循同樣的邏輯，即：一級父離edge盡量近，二級父離一級父盡量近。
最終呈現的狀態就是CDN的節點集中在離客戶端比較近的地方。
基於此，會出現一種不可避免的情況，文件沒有在CDN的網內節點命中，必須要回源，這就會經歷一個比較長的非CDN可控的公網鏈路回源。
從品質的角度來看，回源引起的品質劣化對整體域名品質的影響權重不一定很高。
舉個直觀的例子，如果客戶域名的CDN命中率是95%，即回源流量佔比僅為5%，那麼即使這部分流量出現響應時間異常，那麼整體也隻影響5%左右流量。
基於上面的論證，如果是一個需要100%回源的流量，比如登錄，提交表單，推薦列表，支付等場景下的流量。當把流量切到CDN靜態加速平台，那麼面對節點高度集中在邊緣，經過一個長距離不可控的公網鏈路回源，整體的品質將很容易失控。
03 思考：動態加速的核心
對於純動態的流量，核心的問題比較明確：
當客戶流量接入到CDN邊緣節點之後，需要跨越一個很長的物理距離將請求送到客戶源站，CDN怎麼承諾提供一個低延遲，高穩定的服務品質，就是一個核心的課題。
從邊緣的接入角度來看，用戶的動態流量基本都是https接入，那麼基於CDN廣泛分布的邊緣節點來說，可以將客戶端訪問的TCP握手和SSL握手，卸載到CDN邊緣節點，從而讓本來需要長距離跟源站進行多次握手交互的操作，得到了極大的性能改善。
從節點內的傳輸的角度來看，要想做到最優的延遲，就需要利用最短最優的鏈路，同時在這個鏈路上配合最高效的傳輸。
「 所謂「修好路，跑好車」，這兩項能力必須同時滿足，才能發揮最優的加速效果。」
再好的鏈路，如果中間傳輸伴隨額外的交互開銷，例如過多的tcp握手，ssl握手等，也很難承受住負向影響。
我們把這兩項能力稱為「選路能力」和「傳輸能力」，核心技術點就是：傳輸優化與動態選路。
04 「修好路」：核心技術之傳輸優化
對於低延遲來說，動態流量往往都是小文件內容為主，即一次網路交互就完成，所以傳統的CDN基於大文件下載的TCP優化，難以發揮很大的作用。
其根本原因在於：
目前TCP優化多數都是基於多包的統計和測量等方式，來探測網路的最小延遲和最大窗口等維度的數據，來調整收發包數量和頻率。那麼一次網路交互的場景(典型的動態業務場景，例如彈幕、交易支付、登錄等)，就明顯不適用。
所以對於動態流量的加速，首包(基本就等於響應時間)就是一個核心指標。不像大文件場景，由於下載時長可能很多都是秒級以上，首包的多少，佔比總的完成時間比例不是很高。
對於動態流量，首包基本就是全部。它的時間量級幾乎等於一次tcp握手的時間，那麼在傳輸過程中有額外的長鏈路握手開銷，由此帶來的影響是巨大的。
對於動態流量兩項核心能力中的「傳輸能力」，核心其實是0rtt能力，所謂的0rtt指的是，CDN節點內除了必須產生的一次傳輸有效載荷行為外，不會出現網路上的額外往返(即所謂「0」)。
在這項能力方面，阿里雲的全站加速，經過多年的打磨，構建了一個用戶態的應用網路，讓CDN邊緣和源站之間得以實現運行時零握手開銷的傳輸管道。
05 「跑好車」：核心技術之動態選路
關於選路系統，基於阿里雲全站加速DCDN多年的業務經驗和演進，在此文主要拋出一些觀點，來供讀者進一步的思考。
前面談到，在CDN的默認架構下，回源涉及很長的公網鏈路，這段鏈路可能要跨越不通的省份，國家，甚至大洲，又或者是需要穿過不同種類的運營商網路。
而在廣域網的路由中，有很多複雜的地域和商業上面的訂製策略，繞路之類的情況是經常出現的。
一種行之有效的方案就是基於CDN廣泛分布的節點，通過節點間的探測，配合CDN節點與各運營商的廣泛連通性，構造「路徑切割」來盡量規避穿越長鏈路可能存在的問題。
所謂的「路徑切割」就是構建多段TCP來引導數據，在路由層面盡量按照預期的鏈路來走。
對於選路來說，區別於通用的三層路由選路。
因為動態業務流量是一種具體的場景，在選路時會額外的關注節點間。節點到用戶源站層面上，業務特徵、HTTP和HTTPS流量特徵、TCP和UDP差異、長連接和短連接等方面，對於業務流量會有一些微妙的影響。
所以，對於網路(如下圖)的最優路徑計算，相關的演算法可以參考的較多。
「最優路經計算，其核心的問題，在於如何構圖，即圖的邊到底，通過哪些維度來度量與歸一化，是非常重要的課題。」
除了構圖中關於「邊」的度量和定義，還要關注「節點」的維度。學術界的經典最優選路的演算法，並不考慮鏈路或者節點容量的問題。
那麼，如果按照最優路徑相關演算法的運行結果，會導致流量匯聚到某條鏈路或者節點，產生反向作用，導致鏈路品質上的劣化。
一個形象的比喻就是：所謂的抄近道，走的人多了，也就堵了。
傳統的經典演算法，一旦涉及到鏈路容量限制，就不能正常運行，需要有新的模型來處理這類問題。
另外一個選路層面需要考慮的問題，就是：經典的路徑演算法是無狀態的。
意思是說，每兩次選路的過程之間是沒有關聯的，這就會導致每次選路的結果可能差異很大，流量在網路內瘋狂震蕩，對於系統的穩定性和處理能力有很大挑戰和風險。
最後一個在「選路」層面重點考慮的問題就是，分清楚哪些是節點層面應該做好的，哪些應該選路層面去做好的。
在SDN的領域中，節點層面被定義為數據面，選路層面定義為控制面。換句話說，所謂的控制面要控制哪些，能控制哪些？
對於業界常見的方案來說，選路基本都是中心化的，那麼天然來說，節點到中心的交互就不能太頻繁。
選路層面都需要經過收集和匯聚數據的過程，決策和策略必然產生延遲。
比如10分鐘完成一個周期的任務處理和下發，那麼系統一定是留有足夠的buffer的。這個buffer核心一般體現兩點，一是留有一定的餘量，二是帶有一定的預測。
用一句話來講，選路系統每次計算結果，其實對節點數據面來說，有一個隱含SLA（服務水平協議）的。
比如在某個選路系統中，當前給的結果是保證的未來10分鐘內，在流量不超過xx的閾值下，延遲可以控制xx毫秒的概率是99.9%，那麼對於一些秒級的鏈路閃斷或者品質惡化，就需要節點數據面有自己的容災和兜底策略，這部分是中心式選路系統的交互時間尺度內，難以提供有效支援的。
單獨站在選路的視角來看未來的演進，傳統的基於分場景，人為指定策略的探測模式(探測本質是一種旁路取樣，從統計學上來講就是希望構造一種抽樣來最大化的反映整體或者實際業務流)，然後基於此進行構圖和算路的架構，在系統優化和迭代方面，針對業務的貼合度，或多或少存在一定的GAP。
然而，在實際業務發展過程中，面對同時混合了動、靜態兩種流量場景的全站業務，相應的技術架構就需要有更多的兼顧和綜合視角的考慮，無論是「傳輸」還是「選路」。
動態加速業務的技術演進，從歷史的角度看，基本都是立足於靜態CDN架構在特定場景下的問題，不斷迭代和演進，走出了一套有差異化的架構和技術棧。
「影片雲技術」你最值得關注的音影片技術公眾號，每周推送來自阿里雲一線的實踐技術文章，在這裡與音影片領域一流工程師交流切磋。公眾號後台回復【技術】可加入阿里雲影片雲產品技術交流群，和業內大咖一起探討音影片技術，獲取更多行業最新資訊。
