電子發燒友App
編者按：面對海量數據新的應用形態對低時延和分布式架構的需求，邊緣計算將成為新一代邊緣計算云基礎設施，火山引擎覆蓋了全國海量邊緣節點，儲備了上百T帶寬，承載了視頻直播、游戲娛樂、智慧交通、影視特效等多場景客戶服務， LiveVideoStackCon 2023上海站邀請到火山引擎邊緣云邊緣計算架構師——郭少巍，為大家分享《擁抱云原生——下一代邊緣計算云基礎設施》。
文/郭少巍
大家好，我是郭少巍，目前在火山引擎擔任邊緣計算架構師，個人擅長的領域是云原生和IaaS相關技術研發，近年來一直從事邊緣計算相關的架構設計和研發工作。
本次分享的主題是《擁抱云原生——下一代邊緣計算云基礎設施》。
演講主要包括以下五方面：一、業務走向邊緣；二、業務發展為邊緣計算云基礎設施帶來的新挑戰；三、應對挑戰，邊緣計算云基礎設施逐步完善；四、火山引擎如何構建內外統一、邊緣原生的云基礎設施架構；五、未來展望。
-01-
業務走向邊緣
云計算經過十幾年的發展，對大家來說并不陌生。在使用云計算的過程中，我們享受到了云計算帶來的諸多好處，例如云計算的彈性、可靠性。這十幾年眾多云廠商紛紛涌現，出現了基礎設施即服務、平臺即服務、軟件即服務，云計算的形態上演變出了公有云、私有云和混合云等多種模式，當前“云”已經觸達了企業應用的方方面面。
據Gartner預計，至2027年，將會有超過90%的企業會將“云”作為首選的基礎設施。在如此大規模的應用之下，云計算下一階段的發展方向又在何處？下面讓我們帶著這個問題一起來看下云計算演變的驅動力。
云計算演變有三個關鍵的驅動力：
①應用驅動：越來越多本地化應用的出現，包括云游戲、AR/VR、工業制造、網絡直播、智慧園區、自動駕駛、輔助駕駛等，這些本地商業驅動多樣化的應用部署在更靠近用戶的地方。
②基礎設施的演變：應用驅動基礎設施的完善，基礎設施正在從中心逐步向邊緣演進，形成三種新型邊緣基礎設施形態：現場邊緣、近場邊緣和云邊緣，它們分別提供不同的延時保證和計算能力，現場邊緣的延時是1-5ms，近場邊緣是5-20ms，云邊緣是20-40ms。
③算力和網絡的結合：有了應用和基礎設施的驅動，用戶更希望在邊緣基礎設施上擁有與云上一致的體驗，于是我們將云上的功能放在邊緣基礎設施上。通過將算力和網絡進行融合，為企業提供更好的云上服務。
接下來，我們來一起看業務架構的演進：
我們把資源分為三類：
①終端資源：為用戶提供實時的服務響應，可能就是用戶使用的手機、平板、車機系統。雖然終端資源最靠近用戶，但是它的算力有限，于是便有了邊緣資源。
②邊緣資源：為用戶提供就近的接入服務、廣域的業務覆蓋及精準的網絡感知能力。雖然邊緣能夠為終端提供更強的算力，但它分布在全國各地，而單個邊緣節點的規模有限，為了達成更強的彈性能力及算力，需要結合中心資源。
③中心資源：中心資源可以為用戶提供更加彈性的系統容量，并且提供更加強大的數據聚合能力。
傳統的中心式部署架構已無法滿足新型資源下的部署模式，業務架構采取云邊端配合的模式進行部署，才能夠充分地發揮云邊端的優勢，未來會有越來越多的業務向著云邊端混合部署的新架構方向發展。
邊緣計算發展的歷程可以追溯到1998年，Akamai首次提出CDN的概念，基于互聯網的內容緩存網絡CDN，就近緩存內容，降低網絡擁塞，提高訪問效率和命中率。CDN成為了APP、網站、客戶端背后的基礎服務。
2002年，微軟、IBM與Akamai等公司進行合作，在CDN PoP節點部署.Net和J2EE服務，邊緣計算的概念首次出現。
2009年，CMU提出Cloudlet的概念，將VM與邊緣基礎設施結合，出現了一個部署在網絡邊緣、且資源豐富的可信主機，這便是邊緣 IaaS服務的雛形。
2012年在萬物互聯背景下，移動邊緣計算MEC、霧計算等技術被提出，用于解決萬物互聯帶來的海量數據增長問題。隨后云計算和邊緣結合，出現了邊緣計算概念，在數據源和云中心路徑之間提供輕量、彈性、智能、異構、低時延的邊緣計算服務能力。
對此，我有兩個觀點：首先，邊緣計算是對云計算最有力的補充，兩者互相補充而非簡單的替代概念；其次，云邊協同放大了云計算和邊緣計算的價值，只有更好地協同云和邊，才能發揮兩者最大的價值。
-02-
業務發展，為邊緣計算云基礎設施帶來新的挑戰
邊緣計算的發展帶來好處的同時，也在云基礎設施架構方面帶來許多挑戰。
邊緣計算的優勢如下：
低延遲：邊緣計算節點分布在全國各地，并且覆蓋全鏈路運營商，為用戶提供低延遲體驗。
高帶寬：邊緣計算就近處理和傳輸，能夠承載更大的帶寬。
節約成本：邊緣計算可以減少客戶端與中心節點通信的數據量，從而幫助客戶節約了較多的帶寬成本。
數據安全：數據在邊緣節點進行預處理和預聚合，無需在整個網絡傳輸，從而降低數據在公網傳輸被竊取的風險。
邊緣計算主要帶來以下四點挑戰：
資源限制：邊緣計算節點規模通常較小，機器數量通常為幾臺到幾十臺的規模，甚至有些邊緣節點只有一臺服務器，因此必須考慮如何在小規模節點下管理資源，在有限的資源下盡可能提高資源售賣率。
分布式管理：邊緣計算節點的數百個集群分布在全國各地，存在弱網管理及邊緣自治問題。
需求多樣：由于客戶的業務是多種多樣的，客戶在邊緣節點的需求也比較多，客戶需要在邊緣提供云主機/容器/裸金屬等各種資源類型。此外，在網絡層面客戶希望我們提供VPC、PIP、EIP等能力，在存儲層面客戶希望我們提供云盤、本地盤、文件存儲、對象存儲等能力。
安全管理：需要在很小的節點之內實現租戶隔離，并保證公網和邊緣節點協同的公網傳輸的安全性。
-03-
應對挑戰：邊緣計算云基礎設施逐步完善
為了應對以上挑戰，邊緣計算云基礎設施正在逐步完善。
正如上文提到，邊緣計算面臨著小型化、分布式和安全隔離等挑戰。 對此，我們首先想到的是云原生技術，它具有以下特點： 資源管理方面，云原生技術支持彈性伸縮和資源按需分配，為在邊緣小型節點構建一個彈性伸縮的邊緣節點提供可能性。 技術架構方面，云原生技術具有松耦合、可插拔和良好的擴展性。為邊緣節點異構及按需部署提供可能性。 應用部署方面，云原生技術提供了標準部署、自動化運維和可觀測性。為在邊緣構建簡單化運維及可自動恢復的能力提供可能性。 云原生是面向云應用設計的一種思想理念，有助于構建彈性可靠、松耦合、易管理、可觀測的系統。
邊緣計算的架構演進與業務架構演進相契合，經歷了三個階段：
面向資源階段：業務初期基本都是直接運行在虛擬機或物理機上的，這時的業務直接面向資源，并沒有解決應用如何編排、如何快速部署、如何運維，如何觀測等面向應用云上使用的能力。
面向應用：隨著容器技術的興起，2014年出現kubernetes，2018年出現Cloud Native的概念，與此同時，邊緣也演進到了以云原生為主流架構的時期。
然而，云原生并沒有解決所有邊緣的問題，邊緣場景其自身特點：
在資源層面，邊緣有著廣泛的節點覆蓋，單個節點資源十分有限，這對海量節點管控和單節點資源優化提出了非常高的要求。
在網絡層面，存在云邊弱網環境的問題，這對邊緣自治提出了要求。
由此，迎來了邊緣云技術架構的第三個階段，將云原生與邊緣特性結合，形成邊緣獨有的技術方案，即邊緣原生。
接下來，我將分階段為大家介紹邊緣計算架構演進。
第一個階段是傳統虛擬化階段，此階段將虛擬化技術和邊緣結合，提供將大粒度資源拆分成小粒度資源，以及資源間的隔離能力，其主要著力點是面向資源?？蛻粜枰孕薪鉀Q部署，運維，監控等一系列問題，這種管控模式對客戶基礎運維能力要求極高，要求客戶有非常專業的運維和管控系統。
隨著容器技術和云原生技術的成熟，云原生應用越來越多，此時出現了在虛擬機中部署容器，容器和虛擬機相互嵌套。這一方案中，虛擬化仍然是主要技術，容器是輔助，是傳統超融合應對云原生趨勢的“過渡”方案。此階段雖然解決了部分編排能力，但容器的彈性能力受限于虛擬機的彈性能力。
基于邊緣計算的特色，最終演變出了云原生超融合的架構。在同一套資源池上既實現了虛擬機也實現了容器和裸金屬的管控和部署，具有以下兩點優勢：
第一，資源共池。三種資源形態共享一個資源池，可以靈活調配不同的資源池，提升整體的資源售賣率。
第二，滿足更多業務形態，通過不同容器為云原生應用提供服務。用虛擬機為有基礎運維能力的客戶提供服務，用虛擬機解決Windows生態問題，在邊緣的大流量場景下，用裸金屬為用戶提供更高性能的資源。
邊緣原生結合了邊緣和云原生技術的特點和優勢，因此它具有云原生的應用和服務的可移植性，可觀測性，易管理、統一編排的能力，同時也具有云邊協同、邊邊協同、中心管控和邊緣自治能力。在全局調度方面，具有全局資源調度和局部資源優化能力，在邊緣節點具有異構能力。結合云原生和邊緣的特性，使得應用和服務能夠充分發揮邊緣的能力。
-04-
內外統一、邊緣原生的云基礎設施架構
接著我為大家介紹火山引擎如何構建邊緣原生的云基礎設施。
圖示為整體的技術方案，從底層開始介紹：
火山引擎邊緣計算節點分布在全國各省市、各個運營商、具有優質的網絡線路。同時，結合豐富的邊緣硬件設備，如定制X86服務器、ARM服務器、GPU異構服務器資源、高性能NVMe存儲、100G帶寬的智能網卡設備。
基于這些高質量的基礎設施，我們設計出了邊緣云原生操作系統的能力，包含邊緣自治管理、系統組件管理、以及面向邊緣的鏡像服務能力。自治管理包含集群管理、應用生命周期管理。系統組件包含網絡組件、服務發現、消息隊列。鏡像組件包含公共鏡像、自定義鏡像、鏡像預熱及鏡像加速。
云邊管理提供云邊通道、集群管理、智能調度等子系統，優化了云邊協同。
數據管理提供數據采集、監控告警、數據大屏及數據倉庫。將邊緣數據進行預處理后發送到中心進行分析告警。
最終在產品形態層面為客戶提供邊緣計算服務，包含邊緣虛擬機、裸金屬、容器等多種形態，同時提供云上一致的邊緣網絡、邊緣存儲等多種云服務能力。此外，我們還構建了FaaS和SaaS等邊緣服務。
場景應用層面能夠支撐CDN、視頻直播、實時音視頻、云游戲、動態加速、邊緣智能等各個業務場景的需求。
架構設計的整體理念為云邊協同，邊緣自治，分層治理。
邊緣原生操作系統融合了云原生和邊緣特點，提供以下四點關鍵能力：
①統一編排：通過云原生操作系統，可以實現對算力資源、存儲資源、網絡資源、以及自身云服務資源的統一編排。
②協同管控：支持中心和邊緣協同管控，實現中心與邊緣的高效融合。
③按需部署：通過算力混合部署和服務混合部署及組件可插拔，能夠在不同資源場景下的提供異構算力和異構產品能力。
④云邊協同：實現了云邊通道、邊邊協同等能力。
邊緣節點對資源編排的需求可以歸納為小型化和多樣化：
小型化：通常節點規模較小，只有數臺機器，甚至有的節點只有1臺機器。
計算需求：由于業務的訴求多樣，需要在邊緣節點同時支持虛擬機、容器和裸金屬等多種產品形態。
存儲層面：需要塊存儲，文件存儲和對象存儲等能力。
網絡方面：需要自定義VPC網絡、負載均衡、彈性公網IP等能力。
對此，我們采用的方案是統一資源編排。
最底層是Kubernetes，在此之上通過CRD統一抽象，比如需要虛擬機，定一個Virtual Machine的CRD，通過CRD實現控制器邏輯，從而實現對資源的管控。生態方面，可以直接復用在Kubernetes之上現有的網絡、存儲、GPU等資源類型，實現容器和虛擬機存儲和網絡資源的統一。
統一服務編排的需求是組件統一管理。包括兩點訴求：
輕量化：邊緣集群通常較小，因此管控服務需要實現輕量化。
服務運行依賴：由于服務種類繁多，因此底層依賴的組件庫也多種多樣，部分服務對OS也有特定場景訴求。
對此的方案是統一服務編排，將所有的組件進行微服務化設計，將組件統一容器化打包和發布，使得組件運行時不依賴特定宿主機的OS和組件庫版本。
右圖最底層是引擎層，通過復用Kubernetes的基礎管理能力，直接接入Kubernetes提供的網絡、存儲等基本能力。在引擎層之上自研了日志、監控、報警等能力，使用并強化了云原生的擴縮容、健康探測、故障遷移及自動恢復能力。在此之上，對外統一提供虛擬機、容器實例、裸金屬等外部能力。
協同管控的需求是統一管控和調度，包括云邊聯動管控和統一資源調度。方案是自研的云邊協同管控系統，包括三個關鍵點：
全局感知：在中心基于Watch機制，實現了對邊緣資源的實時感知，更快感知到資源和庫存變化。
邊緣自治：利用多Master機制保障邊緣的可用性，即使與中心失聯，邊緣仍可以獨立工作。
統一調度：實現了虛擬機、容器統一庫存管理。
右圖是創建虛機調度的過程，首先用戶發起創建虛機實例請求，虛機管控收到后再向庫存服務發起請求，調度系統經過全局最優的調度策略，返回結果，管控系統將資源下發至對應的邊緣節點，通過邊緣管控及邊緣調度器執行輕量化調度，最終將實例運行到具體節點之上。
按需部署的需求是能力多樣性，主要包括以下幾點： 規模異構：有的節點會比較小，有的節點規模會比較大 資源異構：不同節點提供的服務器類型包括X86、ARM、GPU 存儲資源：不同節點提供的存儲能力包括云盤、本地盤、文件存儲等 產品能力：不同節點會提供X86虛擬機或ARM虛擬機 對此的方案是組件標準化和按需部署。 首先是標準化節點規格，我們對節點類型及組件進行標準化，前者分為小規格節點、通用型節點、大規格節點等，后者分為虛擬機、容器、網絡等。 同時在部署方案針對不同節點類型和產品需求做了固定編排，在節點建設時，根據節點類型和產品需求，選擇不同的部署方案。右圖可以看到，在小規格節點為用戶提供標準的虛擬機、容器和LB能力，在通用節點還額外提供裸金屬能力，只需在通用節點基礎上部署裸金屬插件即可。在大規格節點之上為用戶提供更多能力如GPU和文件存儲產品能力，同樣只需在大規格節點基礎上部署對應插件即可。
云邊協同解決了云邊弱網問題，包括網絡和安全層面。前者包括網絡丟包、鏈路不穩定、網絡鏈路中斷等問題。后者主要是公網鏈路傳輸安全問題。
相應方案是自研的云邊通道。
首先，通過邊緣與中心建立長鏈接的方式，復用邊緣與中心的鏈路，在中心實現了各個邊緣節點的數據緩存，保障中心更快地感知到邊緣變化，中心組件在操作邊緣時能夠對讀請求加速。
其次，在安全性保障方面，通過身份認證、雙向證書等機制保證客戶端和服務端雙向認證的安全性。在傳輸安全方面，通過全鏈路SSL加解密，保障傳輸數據的安全性。在SSL、ACL訪問控制方面，保證只有白名單的邊緣節點才可以注冊到中心，增強了云邊通信的安全性。
最后在網絡容災方面，采用多機房、多副本、負載均衡和故障自動遷移等技術，確保云邊通道的高可用性。
以下是邊緣節點的幾個最佳技術實踐。
第一個是實例創建加速，其問題是邊緣節點創建實例慢，包括兩方面原因：一是鏡像下載慢，由于邊緣節點從中心下載鏡像較慢，由于鏡像下載需要走公網進行傳輸，因此鏡像下載的時間是不可控的。二是實例創建需要從基礎鏡像完整拷貝一份，如果鏡像較大，拷貝也會較耗時
對此采用的方案是預熱及快照。
首先，將虛擬機鏡像和用戶自定義鏡像提前預熱到邊緣節點。再對邊緣的鏡像預創建快照，當需要創建虛擬機時直接基于快照進行創建，虛擬機底層共享同一快照層，快照采用Copy On Write 機制，虛擬機創建時并不會完全拷貝鏡像數據，而是當真正要寫入數據時才對需要變動的數據進行拷貝，通過快照機制，可以做到虛擬機的秒級創建。
我們在性能優化層面進行了虛擬化性能優化。顧名思義，虛擬機是由軟件虛擬而來，因此虛擬機在一定程度上存在性能損耗，體現在以下三點：
?第一，vCPU在操作系統上是被當做普通用戶態進程進行調度的，因此vCPU之間可能會存在性能爭搶。
?第二，由于虛擬機是大顆粒內存拆分為小顆粒內存，存在內存轉化性能開銷。
?第三，VMM Exit可能影響CPU性能。
為了更加深入地了解以上問題，現為大家介紹一下虛擬機的基本原理：
CPU的運行級別分為Ring0~3這4個運行狀態等級，Linux只使用了其中的Ring0和Ring3，分別表示內核態和用戶態。
虛擬機主要由VMM(Hypervisor)和Guest組成，X86服務器為了支持虛擬化提供了兩種運行模式，root模式和non-root模式。CPU的虛擬機運行過程實際上就是CPU受控制地在root和non-root兩個操作模式之間進行切換。
VMM與Guest的操作模式切換主要分為兩個部分。假設當前運行的代碼在VMM層，如果想要運行客戶的代碼，就需要進入到Guest層，可以手動調用VMLAUNCH或VMRESUME指令將當前運行的代碼切換到客戶側，這個過程我們叫做 VM Entry。假設在客戶側運行過程中需要響應外部中斷或缺頁異常（page fault），此時 CPU 運行會切換到 VMM，我們將這個過程叫做 VM Exit。
為了減少虛擬機的性能損耗，我們做了以下幾件事：
?vCPU綁定：通過將vCPU和物理機CPU一對一綁定，減少了CPU的頻繁切換，從而減低了CPU的上下文切換損耗；
?Hugepage：通過利用內存大頁，減少內存頁表，降低了TLB的miss，提升虛機的訪存性能；
?Exit優化：通過將Timer/IPI等Exit透傳，消除了大部分的VM Exit，使虛擬化損耗降至5%以下。
I/O層面的優化主要包括兩點：
?網絡I/O：超大帶寬，例如vCDN場景
?存儲層面：本地化緩存場景需要較強的存儲帶寬和IOPS能力
對應方案是采用硬件Offloading、硬件直通、Polled I/O等方式。
?硬件Offloading：將網絡流量卸載到專用網卡設備中，使用專用網絡設備做網絡包的轉發，不僅提升了轉發的吞吐能力，還可以釋放部分CPU資源
?設備直通：將磁盤或網卡設備直通到虛擬機中，減少軟件轉發路徑提升了整體 IO 性能
?Polled I/O：通過用戶態Polling，減少對于通知機制的依賴，更快感知數據變化
-05-
未來展望
未來，邊緣計算會繼續呈現增長的趨勢，邊緣計算的崛起也會帶來更多便利。最后為大家介紹一下未來邊緣計算主要努力的方向。
主要是輕量化、算網融合和開放生態。
當前我們在邊緣提供了標準的虛擬化能力及非常完善的功能。但當前存在虛擬化較重的問題。
未來，我們會通過優化Hypervisor實現更輕量的Overhead，進一步降低虛擬化損耗。此外，在管控層面通過云邊協同將部分管控能力統一在中心，邊緣做輕量的自治能力，做到邊緣的管控面和Hypervisor輕量級。
其次是算網的深度融合，當前我們更依賴于單個節點的彈性能力以及單個節點的算力資源調度。應用需要自己做多機房的容災能力，未來我們會做算力網絡深度融合，統一調度網絡資源和CPU算力資源，實現跨節點的彈性伸縮能力，使得部分業務在不同節點間自由遷移，更好地利用不同節點的資源。
最后是更加開放的生態。當前，我們基于云原生技術構建了邊緣原生的操作系統，對外統一提供虛擬機、容器及裸金屬等公有云服務。
未來，我們會為用戶開放更多云原生能力，吸納更多云原生生態的合作伙伴，通過更加開放的模式，使得云原生技術不僅可以服務于自身，也可以讓更多的客戶享受云原生帶來的生態便利。
編輯：黃飛
?
工商網監
評論