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

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

在視頻行業(yè)我們需要應(yīng)對一系列問題，例如架構(gòu)問題、存儲問題、分發(fā)問題、轉(zhuǎn)碼問題等等。這些問題歸根結(jié)底是什么？技術(shù)？

其實(shí)是成本問題，我們需要在控制成本的基礎(chǔ)上為客戶提供最好的服務(wù)體驗(yàn)以實(shí)現(xiàn)效益最大化。如果落實(shí)在技術(shù)上可以總結(jié)為以下幾點(diǎn)：

在解決以上兩個問題之前，需要追根溯源，首先明確視頻在整個網(wǎng)站架構(gòu)中是如何處理的，并對每一環(huán)節(jié)的成本有清晰的理解。

1、 存儲與訪問

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

1.1 分布式存儲

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

在這樣一個超大的分布式文件系統(tǒng)中，系統(tǒng)會將存儲單元進(jìn)行分層，并根據(jù)算法將最熱門的文件分發(fā)到最邊緣的節(jié)點(diǎn)。此時便解決了存儲的問題，接下來需要解決的是訪問問題。

1.2 分層訪問邏輯

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

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

2、 用戶體驗(yàn)：大視頻時代

2.1 標(biāo)準(zhǔn)CDN結(jié)構(gòu)與補(bǔ)充

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

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

2.2 CDN邊緣節(jié)點(diǎn)結(jié)構(gòu)

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

2.3 配置軟件

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

2.4 Cache軟件

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

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

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

解決方案是對每個文件確定一個版本號，假設(shè)所有文件目錄的版本號為0，當(dāng)有某個刷新請求提交過來時把此路徑下所有文件的請求標(biāo)成一個新的版本號，假設(shè)為1；這樣當(dāng)此請求發(fā)送至刷新系統(tǒng)中時系統(tǒng)便知道這個請求對應(yīng)需要版本號為1的文件。此時所有的刷新操作不需要存儲任何的URL到內(nèi)存中， 并用刪除時也不會出現(xiàn)集中的I/O的占用，因?yàn)閮H當(dāng)用戶訪問時系統(tǒng)才會進(jìn)行I/O操作。

2.5 定制的業(yè)務(wù)語言

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

2.6 流量調(diào)度

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

2.7 邊緣化調(diào)度

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

2.8 其他常見問題

2.8.1 回源

這是一個經(jīng)典場景，邊緣的用戶請求最近的節(jié)點(diǎn)并回源。在此過程中， 如果本地的服務(wù)器異常，網(wǎng)絡(luò)不通，這時周邊沒有服務(wù)怎么辦？我們的結(jié)構(gòu)中， 上層和下層基本是一樣的，任何一個邊緣節(jié)點(diǎn)都可作為上層與下層，并且程序， 訪問， 計(jì)費(fèi)本身是抽象出來，并不需要區(qū)分上下層來單獨(dú)處理。只需在后臺對流量進(jìn)行調(diào)整或自動識別某個流量是邊緣流量還是回源流量。

2.8.2 安全體系

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

3、 未來CDN方向

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

邊緣計(jì)算

在這里我想強(qiáng)調(diào)的是邊緣計(jì)算。大家都將CDN視為一個靜態(tài)的東西，那么為什么不能將其作為一個通用的網(wǎng)關(guān)接口呢？因?yàn)镃DN離用戶最近并可實(shí)現(xiàn)很多功能，可以利用CDN開發(fā)很多智能解決方案，例如對多家客戶的IP進(jìn)行重合度分析；利用大數(shù)據(jù)技術(shù)結(jié)合自己的連接數(shù)、I/O等進(jìn)行校驗(yàn)來實(shí)現(xiàn)自主學(xué)習(xí)的安全防護(hù)從而實(shí)現(xiàn)故障自主檢測等。

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