本文來自時任云帆加速創始人/CTO扶凱在LiveVideoStackCon 2017上的分享，并由LiveVideoStack整理而成，目前扶凱任南海集團下屬大地零一深圳有限公司新零售業務VP。扶凱介紹了在海量視頻和用戶的背景下，CDN如何有效、低成本的提供服務，涉及到存儲架構、邊緣節點架構、流量調度等難題。

今天為大家分享的是與大視頻時代下CDN相關的視頻行業發展趨勢。隨著視頻的內容越來越豐富，流量越來越大，視頻所占用的網絡帶寬越來越多，以至于今年已占用網絡總流量的70%～80%，而視頻的玩法也花樣繁多，例如大家熟悉的短視頻、VR、4K等。我們可以看到視頻行業已進入一個爆炸式發展的時代。在此時代下的視頻網站尤其是大型視頻網站，需要明確如何解決流量爆發背后隱藏的一系列亟待解決的問題：如何有效應對視頻服務需求的迅猛增長？

在視頻行業我們需要應對一系列問題，例如架構問題、存儲問題、分發問題、轉碼問題等等。這些問題歸根結底是什么？技術？

其實是成本問題，我們需要在控制成本的基礎上為客戶提供最好的服務體驗以實現效益最大化。如果落實在技術上可以總結為以下幾點：

在解決以上兩個問題之前，需要追根溯源，首先明確視頻在整個網站架構中是如何處理的，并對每一環節的成本有清晰的理解。

1、 存儲與訪問

例如：用戶是將視頻通過基于HTML5分塊上傳的方式發送到線上；接下來通過音視頻分離的編碼對用戶上傳的視頻進行處理，并通過有AI技術來審核視頻，對視頻中的不良內容進行偵測……在眾多處理流程中最麻煩的是存儲，為什么呢？以UGC網站為例，任何一個視頻，無論時長與內容，UGC網站都需要將此視頻的每一份拷貝單獨存儲。隨著視頻拍攝設備的硬件發展，視頻的清晰度與碼率越來越高，一個視頻文件大小動輒幾百MB甚至上GB，而這樣的文件經過轉碼依照不同的碼流至少需要存儲2～3份拷貝，以至于對現如今的視頻網站而言將這些文件存儲在同一個機房十分困難。例如一份文件有幾十個PB，任何一個機房都無法滿足如此極端的存儲需求，此時我們只能將這些文件分散存儲在多個機房，那具體該如何分散存儲呢？

1.1 分布式存儲

當用戶將視頻文件上傳完畢后，會將文件存儲在至少三個上層機房中的一個，而每一個文件可能存儲在不同的幾個上層中。一般的超大型視頻網站會使用推送機制將至少6份文件拷貝存儲在全國所有的機房當中。例如上圖A、B、C三個存儲中心分布在全國各地，簡而言之這就是一個超大的對象分布式文件系統。

在這樣一個超大的分布式文件系統中，系統會將存儲單元進行分層，并根據算法將最熱門的文件分發到最邊緣的節點。此時便解決了存儲的問題，接下來需要解決的是訪問問題。

1.2 分層訪問邏輯

關于訪問，采用的是冷熱分層的訪問邏輯。既然邊緣節點無法存儲太多數據，那么必須采用一種高效的訪問機制以分擔存儲的壓力。我們會直接將冷門的文件調度至上層，而在邊緣將熱門的文件直接傳送給最近的用戶；直接從上層獲取一部分完整的冷門文件，而熱門文件則從邊緣獲取。這樣我們便妥善解決了存儲與分發問題，也就解決了存儲空間和用戶訪問速度的二難問題。

但此時還需要解決的是推送熱門文件的選擇與數量。這是一個比較麻煩的問題，推送的文件， 因為不是全量， 所以無論我怎么樣推送的熱門算法，其實都有部分請求訪問到上層，上層可能是異地，所以用戶的訪問體驗質量可能不好。 例如小的運營商，象歌華都得透穿出來訪問到上層。 原因二是用戶喜好的地理差異性，例如北京的用戶喜歡看的內容與上海的用戶喜歡看的內容存在明顯差別，而使用通用算法得出的熱門是大家普遍喜歡的，無法針對不同地域特點進行個性化精準調整。之前使用了推的機制，那這里能否反向思考，使用拉的機制來妥善解決以上問題，而CDN的出現可以說很好地解決了這個問題。

2、 用戶體驗：大視頻時代

2.1 標準CDN結構與補充

上圖是一個標準的CDN結構，也就是當最邊緣的用戶訪問最近的節點之后，繼續訪問上層存儲；在經過第三層節點后對流量進行回源。這里需要做的第一件事是使用空間換取流量：盡可能使用最邊緣節點里的空間來存儲用戶訪問的文件從而換取吐出給用戶的 80% 的流量，但由于邊緣的空間有限，我們無法對其進行無限擴張。因此所做的第二件事便是使用回源來換取存儲空間。假設某個文件超過一個月都未被訪問的話便使其訪問回源，重新取一份文件。以上便是典型的CDN結構。此時需要注意的是因為CDN中的回源操作對地域的作用，如果某個用戶屬性有明顯的地域差異，便可以將具有地域特征的文件緩存到相應的邊緣。此時相似地域特征的用戶就近訪問同一邊緣節點，得到符合地域特征要求的文件。

我們通過使用商業CDN進行補充的方式解決了存在地域特點的視頻文件分發難題，現在主流的超大型視頻網站都是基于以上方案。既然談到了CDN的整個結構，那么下面就看看如何使用CDN的單節點（邊緣節點）結構來解決存儲與速度的問題，這也是與之前提到的存儲和體驗直接相關的兩個關鍵性問題。

2.2 CDN邊緣節點結構

整個邊緣節點架構基于一臺具有良好批量管理性能的定制OSPF交換機。這種交換機本身就是一個集群，它可以連接到下層所有交換機，來進行批量控制。并且當機器出現宕機時可在4層路由上就迅速屏蔽宕機信息。每一臺機器分為兩個部分：控制部分與OCT的Cache軟件。控制部分進行邏輯處理以對CDN公司的海量客戶控制管理和功能邏輯處理，例如請求過來以后是從路徑中一部分中計費，還是 URL 的參數中的一個字段來計費。最開始時CDN公司對用戶邏輯處理的的通用做法是使用C代碼將這些邏輯集成到 Cache 中是一體的。所以配置更新時，任何一個用戶修改， 會需要升級整個 Cache 軟件并重加載，這便導致了無數配置文件的積累。而使用分離的二塊抽象，有了前端邏輯處理的部分，當使用Edge Control控制所有的用戶邏輯與域名訪問控制，便可簡化配置文件。此時我們只需要讓 Cache 只負責存儲文件與視頻處理等工作，其余都可以交給EdgeControl系統來完成，只需在必要時與系統進行簡單的通訊，可以秒級生效全網的配置。另一個問題，為了應對海量的文件與視頻存儲，整個存儲資源池中所有的機器都使用一致的哈希的算法并確保整個文件在節點中只存儲一份。也許這里會有人質疑，如果某個視頻文件的訪問量非常高，存儲一份會為內網大環境帶來壓力。尤其對于一些大型視頻網站來說這是個很常見的問題，例如當上線某個熱門的電視劇視頻會為內網帶來極大的壓力，在這里我們使用一項被稱為“熱點遷移”的技術。這是一項非常簡單的技術，我們直接在 Edge Control中，使用一個隊列，對視頻文件進行分析、排序再調整則無法從容應對流量短時間內的爆發性增長。而“熱點遷移”技術實際是對每個URL進行排序，當某個URL出現的頻率達到某一閥值時我們就會將這個熱門URL擴散在多臺機器上并使其以極快的速度擴展，這樣就避免了大數據分析從而能夠在第一時間對某個熱門文件的流量爆發做出反應與干預。

2.3 配置軟件

以上描述的是單機結構，接下來讓我們看看Cache軟件本身需要什么。我們的 Cache軟件類似于Nginx的結構，正常的CDN公司大部分是基于Squid進行修改，但Squid存在很多問題，例如無法共享存儲，基于 Epoll只能依托單CPU進程執行等等；即使3.0版本可在多CPU,但執行但執行效率也非常低下。而我們自己的 Cache 軟件類似于ATS 直接支持多 cpu 共享存儲，不過，原生的 ATS 有什么問題，就是ATS的鎖的機制，會讓運維和研發人員在慢的時候，或異常的時候，不知道什么時間，代碼什么地方，莫名其妙會出現卡住的問題。我們的 Cache 本身就可以象它一樣多進程多 CPU 上執行，中間通過epoll實現一些異步操作，而所有的共享操作通過 IPC 通信來進行。除此之外我們在自己的 Cache 軟件上開發了自己的文件系統：這是一個裸盤的文件系統，運維人員都不用格式化文件系統， 只需要給硬盤路徑配置進去；我們也定制開發了自己的分級內存管理，不在使用操作系統本身的內存管理。因為本身的分頁大小， 特別影響 Cache 對于大文件的效率。在這里我們對硬盤 IO 的優化也不同于其他廠商，其它公司是直接增加SSD的策略，我們的策略是先增加內存，才再考慮增加SSD。因為當我們使用標準操作系統的的內存來緩存分頁時就會發現落到磁盤上的I/O非常多，并且不斷出現缺頁，這便導致讀取視頻文件的效率十分低下，所以我們使用了自己開發的內存管理機制。在使用上述自己開發的技術之后，整體的I/O下降了30% ～40%，并且實現缺頁操作與CPU占用率的大幅降低。

2.4 Cache軟件

接下來詳細介紹文件系統。傳統文件系統的一臺機器連接多個硬盤，一般為12個。如果一個熱門視頻文件訪問量非常高，那么存儲這個文件的當前硬盤，的使用率可達到100%，而其它幾個硬盤則處在空閑狀態，使得文件的訪問性能十分低下。因此我對整個文件系統進行調整，將文件分成多個很小的塊，以這種方式將所有文件分塊存儲至文件系統中，使得每個硬盤中存儲的是一個孤立的文件分塊，所有文件按照邏輯一體，物理上分塊來進行存儲與讀取。這種方塊存儲具有以下優勢：一、沒有大量的I/O分布在一個盤上。因為一旦一個文件塊訪問量高，便意味著整個系統訪問會慢，分塊后此時所有磁盤的I/O是一致的一樣高；二、一旦其中某個硬盤壞掉，受影響的只是文件的某一小部分的分塊， 而不會是所有的整個文件，此時只需要從上層服務器重新讀取文件并放置在其他正常運行的硬盤上，而不用對所有文件進行重新回源。三、如果用戶在訪問時需要跳過視頻文件的片頭片尾，那么分塊存儲可不存儲開頭與結尾，并在處理時可以按分塊進行并發：例如在瀏覽視頻時我們拖動視頻至某一特定進度，正常情況下如果不將整個文件加載完成，視頻服務器便無法實現正常播放；而如果使用分塊存儲那么只需獲取文件第1MB的Meta信息，重新跳轉至需要的視頻進度位置并立即合成一個新的文件，極大提高視頻的拖動效率。四、當刪除一個文件時只需要將文件從內存列表中刪去而不需要調整I/O。綜上所述，自主開發文件系統可以為我們在CDN領域的開發節省很多成本。以目錄刷新為例，目錄刷新一直是CDN界的難題。假設需要對一百萬個文件進行目錄刷新，這里便存在兩個問題：

1、如何找到這些URL文件？

2、如何高效處理數百萬個URL文件？

解決方案是對每個文件確定一個版本號，假設所有文件目錄的版本號為0，當有某個刷新請求提交過來時把此路徑下所有文件的請求標成一個新的版本號，假設為1；這樣當此請求發送至刷新系統中時系統便知道這個請求對應需要版本號為1的文件。此時所有的刷新操作不需要存儲任何的URL到內存中， 并用刪除時也不會出現集中的I/O的占用，因為僅當用戶訪問時系統才會進行I/O操作。

2.5 定制的業務語言

以上描述了在多種功能下如何實現有效配置，方案便是分離配置并對每一項設定專門的邏輯語言。在 CDN 的應用場景中，用戶的邏輯千奇百怪，為了提高開發效率我們開發了一套定制的業務語言。此語言可實現通用的基本操作，如對URL與一些基本參數的調整操作。由于此語言的存在，運維人員不需要單獨開發而只需要根據描述文檔就能實現多項功能。這便相當于一個配置文件，當提交此文件生成操作之后，會進行一次編譯并生成一個二進制代碼，此代碼會被直接傳輸至所有機器中，便實現了所有功能在邊緣的生效。此語言還可以保證良好的性能，例如可在進行編譯時將多個執行點相同的文件合并為同一個文件，或把多個路徑前綴/后綴相同的文件合成為同一個文件；也可基于編譯器對開發過程與業務流程進行優化，例如將多個域名相同處理流程進行合并等。

2.6 流量調度

如果想保證視頻的質量，也就需要考慮基于成本與質量的流量調度，實際上我們公司也會對流量調度進行質量評估。流量如果想節約成本， 需要讓調度支持很多功能，抽象出來有二點，第一個做95，第二個是做保底。另一個， 就是集中的調度處理， 無論用戶選擇302 還是 HTTP 調度、HTTP DNS調度、DNS調度以及M3U8調度等，都是相同的處理邏輯， 只有前端接口不一樣，所以是統一體。 另外， 我們邊緣化來計算所有我們的調度請求，我們會將以上所有調度直接指定到離用戶最近的節點上，所以所有的機器都能實現調度， 也能實現 CDN 本身的功能。在我們在流量調度的處理算法上全部使用自主開發的一致性算法，與在上層節點使用的一致性哈希算法相同。這樣上層就算變成下層， 也能很方便的保證命中率， 和不增加存儲空間。

2.7 邊緣化調度

一般廠商會選擇使用中心節點/調度處理，在此模型下所有用戶必須先請求調度才可得到目標地址，而這種動態請求需要中心中央服務器實時處理，無法在邊緣對其進行配置，并且服務器的機位與處理能力有限，如果有攻擊，和高并發流量，極易造成調度的宕機。所以我們嘗試了新的思路，即邊緣化調度：不設立調度中心服務器，將邊緣作為調度服務器。采用本地就近處理的方式讓用戶訪問就近的調度器，而調度器會區分調度請求與用戶訪問請求并反饋不同的操作。

2.8 其他常見問題

2.8.1 回源

這是一個經典場景，邊緣的用戶請求最近的節點并回源。在此過程中， 如果本地的服務器異常，網絡不通，這時周邊沒有服務怎么辦？我們的結構中， 上層和下層基本是一樣的，任何一個邊緣節點都可作為上層與下層，并且程序， 訪問， 計費本身是抽象出來，并不需要區分上下層來單獨處理。只需在后臺對流量進行調整或自動識別某個流量是邊緣流量還是回源流量。

2.8.2 安全體系

在安全領域我們也做了很多嘗試，例如WAF安全體系，可實現動態加載防盜鏈、內容加密與視頻防盜播、文件防篡改、HTTPs回源與加密支持、防劫持等。并且采用積分機制，例如某個不良請求命令10分，某個處于黑名單中的IP 10分，當達到一定分數時安全體系會直接拒絕操作。

3、 未來CDN方向

眾所周知，CDN的成本越來越低，如果想把CDN做得更好，或者想進一步挖掘CDN的潛能，必須尋找差異化路線。例如P2P解決方案；另一條路是安全解決方案，例如各種抗DDOS服務、流量清洗的服務、Wap等服務。

邊緣計算

在這里我想強調的是邊緣計算。大家都將CDN視為一個靜態的東西，那么為什么不能將其作為一個通用的網關接口呢？因為CDN離用戶最近并可實現很多功能，可以利用CDN開發很多智能解決方案，例如對多家客戶的IP進行重合度分析；利用大數據技術結合自己的連接數、I/O等進行校驗來實現自主學習的安全防護從而實現故障自主檢測等。

舉一個邊緣計算的例子，假設上圖是一個標準視頻網站架構中的一部分。如果我要訪問一個視頻，需要從調度器的相關系統， 來查詢很多信息，例如媒體系統、會員系統、視頻調度系統等。其中大部分的信息是不怎么變的，即使只有一兩個信息變化也需要客戶訪問原站并獲取此調度器，這也就使得此調度器非常容易出現重復訪問，大量并發。為了解決這個問題我們可將這三個接口在CDN層進行合并，直接緩存基本的視頻原信息、回源原信息等不變信息，而只把最終的調度信息傳遞給用戶。每次只需要在邊緣與后端的客戶交換少量必要信息，利用有限的服務器資源實現更穩定高效的數據交換，這是CDN一項很重要的趨勢。