CDN正在進行二次變革，從以內容分發服務為主轉變為邊緣雲平臺，轉型之路任重而道遠，好在隨著以容器、Kuberentes、ServiceMesh為主的雲原生技術的成熟，提供了方向和思路。邊緣計算遇上雲原生，為此從2019年開始阿里雲CDN團隊開始了CDN容器化改造工作，同時逐步沉澱出阿里邊緣雲基礎技術平臺，輸出技術能力輸出到邊緣計算ENS場景，真正意義上實現CDN轉型邊緣雲。

在10月22日的SACC2020中國系統架構師大會上，阿里雲技術專家吳龍輝進行了《邊緣計算遇上雲原生 - 阿里雲CDN和邊緣雲原生技術體系建設之路》主題演講，從CDN和邊緣計算的關係、CDN容器化的挑戰和技術方案、阿里邊緣雲原生技術體系建設概況等方面進行技術解讀。

吳龍輝個人簡介：

阿里雲技術專家，《Kuberentes實戰》作者，致力於雲原生技術的研究，擁有豐富的雲原生和容器化實踐經驗；目前負責阿里雲CDN和邊緣雲原生技術體系建設，包括邊緣容器平臺研發、CDN容器化等。

一、阿里雲CDN和邊緣計算ENS

阿里雲CDN誕生之初主要是為了服務於淘寶主站，2014年開始對外商用，發展至今，阿里雲CDN已經成為中國國內最大的CDN服務商，目前阿里雲CDN在全球有超過2800個邊緣節點，單節點頻寬超過40Gbps，全網頻寬輸出能力130Tbps。

阿里雲CDN支援多種行業、多種場景內容加速，例如：圖片小檔案、大檔案下載、音視訊點播、直播流媒體、全站加速、安全加速等等。

邊緣計算是這幾年才提出的一個概念，首先邊緣計算是相對於雲中心計算而言的，邊緣是一種分散式的計算架構，將應用程式從雲中心節點移往邊緣節點去處理，將原本完全由中心節點處理的服務加以分解，分散到邊緣節點去處理。邊緣節點更靠近於使用者終端，可以加快資料的處理與傳送速度，減少延遲。

CDN是一個已經發展20幾年的技術和行業，業界對於CDN和邊緣計算的關係也有比較一致的認識：CDN是廣義邊緣計算已落地的最大規模業務，通過邊緣節點分發內容，使內容更貼近使用者，有效改善使用者體驗。

今天講CDN不僅僅在於CDN的業務本身，更重要的是CDN的基礎設施屬性，CDN節點是全球分佈的，隨著 5G 的正式商用，目前來看，CDN 的規模最大、算力最強，將成為佈局邊緣計算最佳位置。

2017年 阿里雲內部就已經開始看到了邊緣計算的價值，將阿里雲飛天作業系統在CDN邊緣節點落地，並且通過阿里巴巴集團內部業務進行孵化，隨後即正式釋出ENS1.0服務。ENS是邊緣節點服務（Edge Node Service）的英文簡稱，簡單說ENS是基於CDN的邊緣節點和網路構建的，提供靠近終端使用者、彈性的邊緣算力資源，通過ENS可以幫助使用者業務下沉至邊緣，有效降低計算時延和成本。

在2019年的雲棲大會上 阿里雲對外發布了ENS2.0，開始將CDN和ENS的技術進行深度融合，一方面CDN的通用化核心技術（包括儲存、網路、安全、中臺等等）下沉到ENS，成為ENS的一部分能力，另一方面，CDN業務逐步變成ENS上的一個租戶。通過ENS和CDN的融合，我們也在持續賦能給我們的使用者，進行各種行業和場景落地。

目前在ENS的服務平臺上，已經承載了大量CDN業務，以及一大批直播平臺的邊緣收流、合流、互動、彈幕等業務。而現在火熱的線上教育、智慧辦公、智慧醫療等行業核心依賴的音視訊通訊技術，也因為其低時延、大連線、大頻寬等需求特點，陸續成為使用ENS的重要場景。

隨著各種業務場景的持續打磨，ENS也形成非常強大的產品能力：

第一，ENS支援支援多種計算形態：除了虛擬機器，也支援Kubernetes標準的容器和安全容器形態。

第二，ENS支援多種儲存和網路服務。

第三，ENS在安全和運維自動化上提供全棧技術能力，幫助使用者快速方便、並且安全穩定地落地邊緣計算場景。

二、CDN容器化

在介紹CDN容器化之前，先對比一下CDN相對於中心雲所面臨的技術挑戰：

• 在機房分佈方面，CDN的機房是全球分佈的，這對於機房建設挑戰是非常大的，比如是邊遠地區的機房，維修週期是以周為單位的。

• 機房規模方面，CDN每個機房規模是比較小的，相比雲中心機房上萬甚至百萬機器的規模，邊緣機房是非常之少（幾十/幾百臺），這對於業務的容災保證是比較大考驗：如何在有限機器下保證冗餘和異常遷移。

• 流量排程方面更不需要說了，排程能力是CDN核心技術，如何保證業務質量、成本和水位，一直都是CDN的技術挑戰。

• 運維管理方面，相比於1～3中心，邊緣成千上萬節點的管理，運維成本是幾何倍數增長的。

• 彈性方面，因為單機房資源少，所以在業務彈性的時候往往要彈性到其他節點上，這種擴節點的彈性，對於業務本身也需要提供很多支援，比如跨節點資料同步、服務發現等等。

• 網路方面：邊緣節點的網路是不可靠的，機房割接、網路異常、網路攻擊是常有的事情，網路異常下就面臨業務容災、邊緣自治等等的技術挑戰。

• 儲存方面：在成本和節點規模的限制下，目前邊緣節點其實並沒辦法提供完全的資料持久化能力，那麼邊緣節點資料如何和雲中心進行同步，就是一個關鍵問題，哪些資料可以放在邊緣，哪些資料需要傳回並存儲在中心。

• 資源異構層面：CDN導致機型眾多，機器能力不一致。另外也提出過CDN on Anywhere的目標，包括MEC節點，合作節點等等，節點環境的差異巨大，對安全和管理都是比較大的挑戰。

從ENS2.0開始阿里雲將CDN和ENS的技術進行深度融合，其核心的目的是為了將QQ賬號賣號地圖CDN從以內容分發服務為主轉變為通用邊緣計算平臺，其中的一個核心技術方案就是 CDN容器化。

CDN容器化的價值主要有幾點：

第一，跟大部分業務容器化一樣，CDN容器化主要也是要解決自身的問題：

• 成本方面：通過業務混部優化建設成本，支援CDN輕量級節點；

• 效率方面：通過容器的Devops能力優化運維架構，提高效率；

• 穩定性方面：通過業務拆分隔離，減少業務之間互相影響

第二，CDN容器化更重要的戰略意義是通過CDN容器化後，CDN跑在了ENS之上，一方面CDN資源釋放給ENS，另一方面CDN的通用能力能夠下沉到ENS。

在執行層面，主要從3個步驟推進CDN容器化：

第一步是平臺升級

CDN容器化主要採用的Kubernetes來進行容器編排，ServiceMesh進行元件之間的服務發現，所以需要開發一套PaaS平臺，能夠管理和釋出CDN容器，並同時相容已經具備的運維能力。

第二步是元件容器化

需要針對CDN的元件進行容器化後的功能/效能驗證，元件容器化接入Kuberentes後，也針對一些場景進行微服務改造，以支援元件混部後的服務發現。這部分更多的是驗證和優化，找出元件容器化需要改造的地方。同時在穩定性層面，因為引入了更多的系統和風險，在可觀測性和運維SRE層面需要投入比較多的精力和人力，在體系建設和技能培訓上齊頭並進。

第三步是業務遷移

前2步完成後就是進行CDN業務遷移，正如給飛行中的飛機換引擎，遷移過程需要對現有業務做相容，保證平滑遷移。

通過這3步，CDN業務就順利平滑地遷移到容器中，吳龍輝表示：“我個人的經驗來說：在業務團隊不熟悉容器和雲原生的情況下，儘量先相容已有的邏輯，讓業務對於容器化後沒有太大的變化，然後逐步優化，避免操之過急，引發故障。同時在過程中幫助業務進行優化，幫助業務去理解新的技術和理念，平臺方和業務方共同推進落地。”

吳龍輝：“通過CDN容器化，我們積累了非常多的經驗（坑），阿里雲有個傳統：自己的狗糧自己吃，新技術拿自己試驗，再為對外服務，所以在今年開始我們陸續會將這些雲原生的理念和技術能力注入到ENS中，建立ENS邊緣雲原生技術體系。”

三、ENS邊緣雲原生技術體系

“雲原生也是一個新興的概念，我個人的理解其實就是基於雲端計算技術進行應用設計開發，以充分利用雲端計算的優勢。對於邊緣雲原生，我的定義是基於邊緣計算進行應用設計開發，以充分利用邊緣計算的優勢。”

ENS邊緣雲原生的優勢有：

• 低延時：ENS可以提供就近計算。

• 彈效能力：ENS依託於CDN，有巨大的算力資源，能夠提供彈效能力和質量保證、故障遷移。

• 邊緣自治：在斷網情況下支援邊緣節點內部自治，保證部分業務功能無損。

• 雲邊一體：邊緣計算不是孤立存在，是必須跟雲中心進行協同的，ENS能夠提供跟雲中心一致的能力和體驗。

• 不變的基礎設施：ENS會遮蔽邊緣異構資源的差異性，給上層提供統一的Serverless能力

• 標準化：邊緣計算是雲端計算的一部分，2者是統一的。

就如大家所知道的，目前Docker、Kuberentes、ServiceMesh是雲原生領域的代表技術。在前面CDN容器化部分提到我們已經邊緣場景落地容器、Kubernetes和ServiceMesh。

這裡總結一下邊緣雲原生的區別和挑戰：

• 容器排程：中心的容器排程一般是不需要考慮業務請求（流量）排程的，中心會在1～3個Region進行部署，然後通過DNS配置請求轉發邏輯，這種情況下，容器都是提前排程並且部署好的（主要是資源排程），其實並不需要跟業務請求協同。而邊緣很多場景下容器排程是需要和業務請求排程協同，比如業務需要在華南地區部署10個容器，這10個容器會分佈在10個邊緣節點，那麼當容器排程到這些邊緣節點後，業務請求也需要排程過來，而且當某個節點故障後，容器遷移到其他節點，業務請求也需要同步排程過去。業務請求排程可以複用CDN強大的流量排程能力，同時容器排程需要和CDN排程深度協同，這是中心不具備的能力，也是邊緣場景下需要深入打磨的核心能力。

• Kubernetes：目前Kuberentes的大部分都是在中心場景下落地，一般來說一箇中心會部署完整一套Kuberentes，Kuberentes的Master和Node都在一個私有網路/VPC內，Kuberentes單叢集能管理5千～1萬的Node數目，其實對於大部分場景下只需要維護1～3個Kuberentes即可。在邊緣場景下，目前採用的結構是Kuberentes Master部署在雲中心，然後就近管理周邊的邊緣節點，比如部署在杭州Region的Kuberentes Master，管理整個浙江省的節點，Master和Node之間是通過公網通訊；同時因為我們節點和機器比較多，Kuberentes叢集數目也比較多，在全球主要的Region都會部署。

• ServiceMesh：跟Kuberentes類似，ServiceMesh大多是在中心內網內工作，不需要考慮跨機房、跨公網通訊能力。ServiceMesh因為涉及到業務資料面，對於資料延時和邊緣自治的要求會更高。

• 應用/運維管理：應用/運維管理方面，邊緣跟中心大部分是一致的，但是邊緣場景下需要考慮多節點的釋出灰度、中心和邊緣的網路通訊等等問題

阿里雲邊緣節點服務ENS邊緣雲原生體系建設的技術目標：

• 更加適合邊緣的雲原生能力：各種雲上的技術，各種開源技術，需要針對邊緣的需求進行增強，能夠讓使用者在邊緣使用各種能力，目前正在投入的方向有：Kubernetes、ServiceMesh、容器、安全容器、容器儲存/網路，以及各種中介軟體的整合。

• 更加標準和通用的應用管理能力：對使用者來說，應用部署雲中心和邊緣，只是底層環境的差別，上層的應用管理應該是一致的，標準的。這部分我們也在整合一些業界標準，包括微服務化、OAM、可觀測性等等

• 更加穩定和可靠的邊緣Serverless底座：邊緣的管控和運維成本是比較高的，所以使用者在邊緣落地的時候更傾向於Serverless形態，為此我們需要提供一個穩定和可靠的底座。

核心能力上，包括邊緣網路，邊緣融合計算、邊緣管控，邊緣雲原生體系會跟整個ENS邊緣雲核心能力進行整合和持續打磨，做深技術和產品，為使用者持續建立價值。

隨著CDN容器化的落地，以及ENS邊緣雲原生體系的建設，阿里雲進一步提出CDN on ENS，即全網CDN使用雲原生技術上ENS。

通過CDN on ENS，阿里雲會把全網2800+多個CDN節點改成ENS節點，所有ENS節點除了能夠執行CDN業務之外，也能夠執行ENS外部業務。技術挑戰上：

• 需要要保證CDN業務和ENS外部業務的隔離，包括執行時、網路、儲存都需要強隔離以保證安全

• 需要在保證穩定性的前提下，CDN on ENS後成本無大幅增加。

• CDN和ENS統一資源池，那麼CDN的流程排程和ENS的算力排程需要時時協同，在保證質量和SLA的情況下最大化資源複用率。

吳龍輝：“在大部分CDN廠商還處在探索階段的時候，阿里雲正在進行著真正意義上CDN的技術架構大升級，這代表了我們對於邊緣計算的態度和決心。邊緣計算是個非常大的領域，我們想通過5G的來臨和邊緣計算的發展，能夠讓產業網際網路有更大的發展，讓我們不曾想、未曾做的事情得以實現。”