基于CDN的邊緣計算平臺設計和思考
CDN的重要性不僅僅在于CDN的業務本身,更重要的是CDN的基礎設施屬性,CDN節點是全球分布的,隨著5G的正式商用,目前來看,CDN的規模最大、算力最強,將成為布局邊緣計算最佳的位置。但是邊緣計算不是孤立存在,是必須跟云中心協同的。本文介紹從CDN的角度思考如何打造一個云邊端協同的邊緣計算平臺。
CDN和邊緣計算
CDN的全稱是Content Delivery Network,即內容分發網絡。CDN是構建在現有網絡基礎之上的智能虛擬網絡,依靠部署在各地的邊緣服務器,通過中心平臺的負載均衡、內容分發、調度等功能模塊,使用戶就近獲取所需內容,降低網絡擁塞,提高用戶訪問響應速度和命中率。CDN的關鍵技術主要有內容存儲和分發技術。
以上是來自來自百度百科的解釋,簡單的說CDN就是用空間換時間,空間的話就是分部在離終端用戶較近的邊緣節點,時間上就是終端用戶直接從邊緣節點直接獲取資源,這樣就不需要直接訪問源站,從而提升用戶體驗。
舉一個不是很恰當的類比,比如現在國內電商平臺建立物流系統:在一城市會建一二個大型物流中心(源站),三四線城市會建立小型物流中心(邊緣節點),像雙十一這種大促,會根據大數據統計算提前在各地的小物流中心準備好商品(預熱),這樣用戶就可以快速獲取包裹(就近獲取)。所以CDN可以認為是目前整個互聯網的物流系統,只不過CDN分發的不是包裹,而是圖片、視頻、軟件安裝包。一般一家CDN服務商需要有成百上千個邊緣節點,才可以具備比較好的服務質量。
CDN已經是一個充分驗證過的成熟技術,可以不夸張地說,CDN扛住了整個互聯網大部分的流量,沒有CDN就沒有現在繁榮的各種視頻網站、直播平臺和小視頻APP。同時經過長期的發展,CDN在供應鏈體系、節點建設、網絡運維都有非常成熟的經驗和沉淀。
隨著互聯網智能終端設備數量的急劇增加,以及5G和物聯網時代的到來,傳統云計算中心集中存儲、計算的模式已經無法滿足終端設備對于時效、容量、算力的需求。將云計算的能力下沉到邊緣側、設備側,并通過中心進行統一交付、運維、管控,將是云計算的重要發展趨勢,這個就是邊緣計算。
IDC預計,到2020年全球將有超過500億的終端與設備聯網,超過40%的數據要在網絡邊緣側進行分析、處理與存儲,這對邊緣計算提供了充分的場景和想象空間。
邊緣計算分層結構包括云、邊、端:
云,Centralized Cloud:傳統云計算的中心節點,資源豐富,計算力強,擴展性強,服務多區域,但離終端用戶遠。同時云中心是邊緣計算的管控端,負責全網算力和數據的統一管理、調度、存儲;
邊,Infrastructure Edge:通常服務特定的一個區域,如市、縣、區等,部署在目標服務區域10~30公里的地方,提供滿足目標服務區域的計算、存儲、網絡服務。Infrastructure Edge邊緣通常位于IDC內,擁有充足的算力和存儲容量,和中心有專線或骨干網連接,如CDN節點等。Infrastructure Edge又可分為Access Edge和Aggregation Edge兩層,其中Access Edge靠近Device Edge,與用戶或設備端更近,Aggregation Edge聚合一個或多個Access Edge的數據,與云端進行交互。
端,Device Edge:終端設備,如手機、智能家電、各類傳感器、攝像頭等。
可以認為CDN是邊緣計算的一種形態,并且是當前來看規模最大、算力最強的形態、也是成熟度最高的業務形態。但是CDN的業務形態也需要做技術架構升級,才能支撐更多的邊緣計算場景。
邊緣計算的技術形態
邊緣計算技術形態也可以按照傳統的邏輯劃分為IaaS、PaaS和SaaS:
IaaS:在邊緣測提供虛擬機,這個跟在云中心購買ECS差不多,只不過機器是部署在邊緣IDC(這里的邊緣IDC其實是相對于云中心IDC),但是在網絡情況和穩定性上是跟云中心不一樣的,畢竟云中心有幾萬臺機器的規模冗余,有專門的駐場人員、機房和網絡維護,而邊緣節點有時候是不具備這些條件的,但是在使用場景上肯定也是不一樣的,比如:不建議在邊緣部署對數據可靠性要求非常高的業務。
PaaS:提供虛擬機的方式對于有些用戶來說,可能運維起來有點麻煩:比如機器是分部在不同地方和不同運營商的,各地的網絡不大一樣,機房也有網絡割接的時候,管理這些虛擬機也會有不小的成本,難以快速進行業務切換調度。這樣一來就需要有個邊緣場景的PaaS服務,來幫助用戶管理和調度邊緣的資源,容器和K8S的話是一個在運維調度層面很好的解決方案。在解決運維的問題后,用戶對于PaaS的需求也會上升到更加多樣的能力,特別對于各種中間件的需求,EdgeKV,EdgeStore等等,比如KV需要具備全網數據同步的能力。
SaaS:CDN就是典型的SaaS服務,主要包含包含靜態文件(文件、圖片、視頻)加速、流媒體加速、動態加速,衍生的形態還包括安全、P2P。另外視頻AI也是后續一個重要的SaaS能力,比如自動駕駛、IOT場景的一個重要需求就是需要在邊緣能夠直接進行視頻AI處理來保證延時。
可編程CDN:除了往通用計算轉型,CDN的一個重要方向是往可編程CDN轉型,簡單的說就是通過函數計算或者腳本來控制CDN邏輯,比如Cloudfare的EdgeWorker,在邊緣支持V8引擎來運行JS腳本,這種技術方案相比于容器的優勢在于更加輕量級、成本更低、啟動時間更快。
可以看出邊緣計算并不是孤立存在的,邊緣計算一定是需要跟云計算進行協同,所謂云邊端協同。
一種比較形象的說法:如果把云計算比作整個計算機智能系統的大腦。那么邊緣計算就是這個系統的眼睛耳朵和手腳。完全依賴云計算的計算機系統就好比每一件事都要請示司令部的軍隊,在需要大量和外界互動的時候會顯得僵化,反應遲緩,而且一旦網絡有點問題就徹底歇菜。加上邊緣計算之后就好比讓中低層軍官也開始發揮主觀能動性,能一定程度上自主做出智能判斷和行動決策,同時也只需要把一部分經過篩選的信息上傳到司令部。大大緩解了網絡通訊的壓力。即使在和總司令部暫時失去聯系的情況下,也能自主做出部分決策。
邊緣計算跟云計算相比也面臨著諸多挑戰,以CDN為例,邊緣節點分布廣,單節點規模小(1~100機器左右),大部分節點是沒有駐場人員,所以維修周期長(1~2周)。同時節點的網絡復雜并且不可控,網絡割接、運營商封禁是常有的事情,省與省,國與國(海外)之間都有種非常復雜的調用鏈路。
面對這些問題,就需要對 調度/容災能力、運維能力要有比較高的要求,CDN本身的業務形態就是天然容災和可調度的:一個節點掛了,流量就可以切換到其他節點上。CDN節點架構也相對比較簡單,經典三層架構:四層負載均衡(LVS)+七層負載均衡(Nginx或者HaProxy)+緩存服務(Squid),所以CDN運維也是比較簡單的,機器上主要是緩存數據,機器掛了整體影響不大,不需要做數據遷移。
但是CDN要轉型到通用邊緣計算平臺,調度/容災能力和運維能力就會變成規模化的一個主要瓶頸,怎么做調度、怎么做容災、怎么做運維,這些問題在邊緣場景更加突出。
因此容器的輕量級和DevOps屬性,加上Kubernetes的調度,目前看來是非常是非常適合邊緣計算。
容器在邊緣計算的落地形態
容器和Kubernetes的落地場景主要還是在中心大集群場景,目前在邊緣的落地形態也是在探索和實踐中,目前針對邊緣場景的Kubernetes有:
K3S:K3S是Rancher開源的輕量級Kubernetes發行版,K3S是通過大量裁剪Kubernetes代碼,只保留主要核心代碼,這是是為了在邊緣計算環境中運行在x86、ARM64和ARMv7處理器上的小型、易于管理的Kubernetes集群日益增長的需求。可以看出K3S主要是適配端(Device Edge)上的場景,通過簡化Kubernetes來保證可以運行在終端設備上。
KubeEdge:KubeEdge是華為貢獻給開源社區的一個項目,從名字上可以看出也是真的邊緣場景, KubeEdge的優勢在于設備連接,它可以支持多種協議,并使用基于標準MQTT的通信,這有助于有效地使用新節點和設備擴展邊緣集群。KubeEdge主要的場景在于邊緣接入層(Access Edge),解決各種IOT終端設備接入的問題。
ACK@Edge:ACK@Edge是阿里云ACK(Kubernetes)適配邊緣的形態,ACK@Edge在實現上保存了原生Kubernetes的所有能力,所有邊緣相關的特性均通過Addon實現,Master是部署在云中心,Node在邊緣端。ACK@Edge比較適合基礎設施邊緣(Infrastructure Edge),比如CDN場景。
以CDN場景的落地場景來說,形態上就是在云中心部署Kubernetes Master,將云中心所在Region附近的CDN節點接入到Kubernetes中,最后Kubernetes之上構建Fedration能力,進行全局容器調度。這樣就能利用Kubernetes調度能力和容器的DevOps能力。具體可以參考https://yq.aliyun.com/articles/711767。
未來展望和趨勢判斷
CDN轉型邊緣計算平臺,CDN已經是一個非常成熟技術和業務,也是因為成熟,所以同質化嚴重,同時因為CDN的業務粘性不夠(改個DNS業務就切走了),所以目前國內CDN的商業環境并不是太好,CDN行業變成價格紅海,所以CDN廠商也紛紛在進行戰略轉型邊緣計算平臺,但是5G還未大規模商用,轉型之路面臨著諸多問題:落地場景存不確定因素,客戶接受程度不夠等等。但是改變可能失敗,不改變必定掉隊,所以當務之急是先修煉好內功,把新技術(虛擬化/容器/AI)在CDN進行落地和磨煉,同時積極挖掘各種新業務和場景。
安全容器是重要能力,容器天然適合邊緣計算,但是容器也是比較大的硬傷,那就是安全和隔離,這也是為什么現在邊緣計算的主要對外售賣形態還是虛擬機。所以安全容器就是一個最佳解決方案,具備容器的DevOps屬性,又有比較好的隔離和安全保證。今年Kata安全容器發展迅猛,所以安全容器是邊緣計算的一個關鍵技術。
視頻AI和邊緣計算天生一對,視頻AI目前已經有不少落地場景:人臉識別門禁、自動垃圾分類、食堂自助結賬等等,可以預見視頻AI將會繼續快速發展。但是隨著規模的擴大和場景的挖掘,視頻AI對于低延時的需求會日漸強烈,如果能把視頻AI能力部署在邊緣節點上:云中心進行大數據計算和AI訓練,AI訓練結果下沉到邊緣節點,邊緣負責視頻接入,直接在邊緣進行處理。
Q&A
Q:能否介紹一下,目前CND節點改造成邊緣計算節點,主要涉及哪些方面改造,阿里的實踐情況,謝謝。
A:目前CDN改造有3個部分:基礎設施到改造(交換機、機型),軟件層面的改造(容器化),CDN節點架構的改造(比如把傳統的7層負載均衡改成Kubernetes的Ingress Controller)。
Q:CDN場景的落地場景來說,形態上就是在云中心部署Kubernetes Master,將云中心所在Region附近的CDN節點接入到Kubernetes中 ,指的是在各個Region里面的節點當作Kubernetes的Node處理嗎?
A:比如我們在阿里云中心的杭州Region創建一個Kubernetes Master,然后會把杭州整個省的CDN節點,全部接入到這個Kubernetes Master里面,CDN節點指的是一個機房,一個機房會有1~100臺機器,整個CDN節點的機器都會接入。
Q:請問阿里邊緣計算有和5G結合的計劃嗎?具體有哪些結合點?
A:在今年云棲大會上,我們已經發布了5G邊緣計算戰略,這個可以網上找下視頻回放。具體的結合點目前來看是城市大腦和城市云。不過因為5G還未大規模商用,所以我們也在探索。https://yunqi.youku.com/2019/hangzhou/review?spm=a2c4e.11165380.1395223.1
Q:請問未來Docker會向安全容器轉型嗎?安全容器是趨勢,作為開發者要注意哪些點?
A:其實Kata和普通runC容器,在行為上沒有太大差別,如果非要說關注點的話,目前我覺得是內核部分,因為Kata容器對于內核要求是比較高的,穩定性方面還需要打磨。
Q:在云上部署Kubernetes Master節點,CDN節點作為邊緣節點。對Kubernetes來說,節點之前的網絡通訊要求會比較高,那當網絡不穩定時,邊緣節點和Master節點斷開,這時如何實現邊緣節點上的服務自治呢?
A:這個就是ACK@Edge解決的問題了,ACK@Edge在邊緣測機器上部署了一個Edgehub的組件,kubelet并不是直接請求kube-apiserver,而是通過Edgehub然后再請求到APIServer。Edgehub做了緩存和代理的能力,即使在斷網的情況下,也能保障邊緣節點的kubelet正常工作。這個能力叫做邊緣自治,是ACK加強的能力。
Q:請談談阿里看到的邊緣計算cover的真實價值場景或者客戶群,感覺很多現有場景中心計算也能滿足,不一定要用邊緣計算。特別是邊緣計算節點也賣虛機,價值不大。謝謝。
A:以CDN為例,CDN就是通過邊緣做加速來提高用戶體驗。虛擬只是一種形態,比如你購買虛擬機自建CDN。所以邊緣的場景肯定是跟中心不一樣,比如城市大腦,就是需要在就近有個節點可以做接入,如果全部回中心,對中心的壓力也很大。
Q:請問安全容器的存儲性能有考慮過么?接入點在邊緣還是放云端?
A:安全容器最終是跑著邊緣上的,安全容器的存儲目前是一個大的問題,Kata開源的存儲方案性能并不好。阿里云的內核團隊做了大量的優化,目前應該有了比較大的性能改進。
Q:容器安全方面有什么需要注意的?除了Kata之外,使用dockerd與Kubernetes有什么安全建議psp之類的?
A:安全容器的使用,第一Kubernetes需要做適配runtimeClass,第二內核也要求比較高(應該是要4.*內核比較穩定)。安全建議:就是加證書、改端口,不然容易被外部注入容器。其他的安全建議:就是直接使用云上產品,云上產品具備了比較高的安全能力。
Q:CDN的流量分配是在哪里做的?是DNS還是GSLB那種?異地災備也可以用同樣的方式?
A:CDN的流量分配就有DNS、HTTPDNS、302調度,CDN本身就是成熟的技術了,調度這塊都是非常成熟的技術。