云計算發展史，就是虛擬化技術的發展史。近 20 年來云計算與互聯網相互促進高速發展，中心云技術成為全社會通用的基礎設施。隨著物聯網、人工智能等技術的不斷發展，尤其是產業互聯網發展落地，中心云計算開始相形見絀，分散式邊緣計算在當下被重新寄予厚望。如果中心云計算是由技術創新驅動的，那么邊緣計算一定是業務價值驅動的。

邊緣計算的理解與思考 邊緣計算的定義

邊緣計算當前沒有準確定義，從 IT 云計算領域視角，邊緣計算被看作中心云計算的拓展。邊緣計算產業聯盟對邊緣計算的定義：“在靠近物或數據源頭的網絡邊緣側，融合網絡、計算、存儲、應用核心能力的開放平臺，就近提供邊緣智能服務，滿足行業數字化在敏捷連接、實時業務、數據優化、應用智能、安全與隱私保護等方面的關鍵需求”。從 CT 電信領域視角，邊緣計算最初也被稱為移動邊緣計算(MEC)。

歐洲電信標準協會(ETSI)對 MEC 的定義：“移動邊緣計算在移動網絡的邊緣、無線接入網(RAN)的內部以及移動用戶的近處提供了一個 IT 服務環境以及云計算能力”。

邊緣計算的定義各有側重，但核心思想基本一致——邊緣計算是基于云計算核心技術，構建在邊緣基礎設施之上的新型分布式計算形式，在邊緣端靠近最終用戶提供計算能力，是一種靠近數據源的現場云計算。中心云計算憑借其強大的數據中心，為業務應用提供大規模池化，彈性擴展的計算、存儲、網絡等基礎設施服務，更適用于非實時、長周期數據、業務決策場景;邊緣計算則聚焦在實時性、短周期數據、本地決策等業務場景，比如當下熱門的音視頻直播、IoT、產業互聯網、虛擬現實甚至元宇宙等，將工作負載下沉至離終端設備或者靠近最終用戶的地方，以此實現更低的網絡延遲，提升用戶的使用體驗。

“章魚式”邊緣計算

邊緣是相對中心式計算的邊緣分散式計算。邊緣計算的核心目標是快速決策，將中心云的計算能力拓展至“最后一公里”。因此它不能獨立于中心云，而是在云-邊-端的整體架構之下，有中心式管控決策，也有分散式邊緣自主決策，即章魚式邊緣計算。

如上圖漫畫中所示，章魚全身神經元中心式腦部占 40%，其余 60% 在分散式腿部，形成 1 個大腦總控協調 + N 個小腦分散執行的結構。1 個大腦擅長全局調度，進行非實時、長周期的大數據處理與分析;N 個小腦側重局部、小規模數據處理，適用于現場級、實時、短周期的智能分析與快速決策。

章魚式邊緣計算采用中心云+邊緣計算的分布式云邊一體化架構，海量終端采集到數據后，在邊緣完成小規模局部數據的實時決策處理，而復雜大規模的全局性決策處理則匯總至中心云深入分析處理。

邊緣計算的位置

邊緣計算位于中心云及終端之間，將云計算能力由中心下沉到邊緣，通過云邊協同的架構解決特定的業務需求，能大程度降低傳輸時延，這也是邊緣計算的核心價值。但中心云與終端之間的網絡傳輸路徑經由接入網(距離 30 公里，延遲 5 到10 毫秒)，匯聚網，城際網(距離 50 到 100 公里，延遲 15 到 30 毫秒)到骨干網(距離 200 公里，延遲 50 毫秒)，最后才到數據中心(假定數據中心 IDC 都在骨干網)，耗時數據是正常網絡擁塞的撥測統計值，即業務側感知的實際延遲數據，雖不是非常精確，但足夠輔助架構決策。

云計算能力由中心逐步下沉到邊緣，節點數量增多，覆蓋范圍縮小，運維服務成本快速增加。根據國內網絡(國內有多張骨干網，分別是電信 CHINANET 與 CN2，聯通 CNCNET 以及移動 CMNET)現狀，骨干網節點，城際網節點，匯聚網節點，接入網節點，以及數以萬計的業務現場計算節點都可以安置邊緣計算，因此范圍太廣難以形成統一標準。因此我們說中心云計算由技術定義，邊緣計算由網絡與業務需求定義。

邊緣計算生態參與者眾多，云廠商、設備廠商、運營商三大關鍵服務商方以及一些新型 AI 服務商等，都是從各自現有優勢延伸，拓展更多客戶及市場空間。設備商借助物聯網逐漸構建單一功能的專業云;云廠商從中心化的公有云開始下沉，走向分布式區域云，區域云之間通過云聯網打通，形成一個覆蓋更大的云。運營商在互聯網時代被公有云及繁榮的移動應用完全屏蔽只能充當管道，但在邊緣計算時代，業務及網絡定義邊緣計算，運營商重新回歸焦點，不可替代。

邊緣計算的類型

1、網絡定義的邊緣計算

通過優化終端與云中心網絡路徑，將中心云能力逐漸下沉至靠近終端，實現業務就近接入訪問。從中心到邊緣依次分為區域云/中心云，邊緣云/邊緣計算，邊緣計算/本地計算三大類型：

區域云/中心云：將中心云計算的服務在骨干網拓展延伸，將中心化云能力拓展至區域，實現區域全覆蓋，解決在骨干網上耗時，將網絡延遲優化至 30ms 左右，但邏輯上仍是中心云服務。

邊緣云/邊緣計算：將中心云計算的服務沿著運營商的網絡節點延伸，構建中小規模云服務或類云服務能力，將網絡延遲優化至 15ms 左右，比如多接入邊緣計算(MEC)、CDN。

邊緣計算/本地計算：主要是接近終端的現場設備及服務能力，將終端部分邏輯剝離出來，實現邊緣自主的智能服務，由云端控制邊緣的資源調度、應用管理與業務編排等能力，將網絡延遲優化至 5ms 左右，比如多功能一體機、智能路由器等。

總的來說，基于網絡定義的邊緣計算，更多是面向消費互聯業務及新型 2C 業務，將云中心的能力及數據提前下沉至邊緣，除了經典的 CDN，視頻語音業務外，還有今年大火的元宇宙等。當前大部分面向消費互聯業務都是通過安置在骨干網的中心云計算能力支持，時延在 30ms 到 50ms，遠小于本身云端后端業務處理的延遲;算力下沉至邊緣的初衷，主要是實現中心云海量請求壓力分散，用戶體驗優化等，對業務都屬于錦上添花，而非雪中送炭。

這里說一下運營商網絡，中心云計算技術，是將數據中心內部網絡全部虛擬化，即云內網絡，衍生出 VPC，負載均衡等諸多產品;數據中心外部幾乎完全屏蔽運營商網絡，只提供彈性公網 IP 及互聯網出口帶寬服務，中心云計算與運營商網絡沒有融合;但從中心云計算演進到邊緣計算，是強依賴網絡將中心云與邊緣鏈接起來，如果中心云是大腦，邊緣計算是智能觸角，那么網絡就是神經，就是動脈血管，但實際上整體網絡規劃與建設發生在云計算發展之前，并不是專門服務云計算的，所以中心云計算與運營商網需要融合，即云網融合，云網融合最終目標是實現云能力的網絡化調度編排，網絡能力的云化快速定義。希望借助新型業務需求和云技術創新，驅動運營商網絡架構深刻變革升級開放。

當前，網絡的能力極大限制了云計算的發展，在邊緣計算及物聯網建設過程中尤為明顯。云網融合與算力網絡依然還是運營商的游戲，新一代 5G 顛覆性技術變革，引爆整個領域的顛覆性巨變，也只解決了海量設備接入及設備低延遲接入的問題，后端整體配套及解決方案明顯跟不上。就當前情況來看，依然還是 5G 找業務的尷尬局面，未來 5G 在實體產業領域(港口、 碼頭、礦山等)領域，相比消費者領域，相信會帶來更大變革與價值。

2、業務定義的邊緣計算

除了面向消費者的互聯網邊緣場景，邊緣計算更多的是面向實體產業及智慧化社會衍生的場景。

對于實體產業場景來說，由于歷史原因，在邊緣及現場存在大量異構的基礎設施資源;通過業務需求驅動邊緣計算平臺的建設，不僅要整合利用現有基礎設施資源，還要將中心云計算技術及能力下沉至邊緣及現場，實現大量存量業務運營管控上云，海量數據統一入湖，以此支持整個企業的數字化轉型。對于智慧化社會衍生場景來說，越是新型的業務，對網絡時延敏感越高，數據量越大，結構化數據逐漸轉化成非結構化數據，需要人工智能，神經網絡等高等智能化技術支持。當前對網絡時延敏感的新型業務場景，都是通過云端總控管理，設備現場實時計算這種分布式架構策略，以此減弱對網絡的強依賴。面向業務將邊緣計算分為智能設備/專業云及產業邊緣/行業云兩種類型：

智能設備/專業云：基于云計算能力之上，圍繞智能設備提供整體化，有競爭力的解決方案，包含智能設備、云端的服務以及端到云之間的邊緣側服務，比如視頻監控云、G7 貨運物聯等;

產業邊緣/行業云：也基于云計算能力之上，圍繞行業應用及場景，提供套件產品及解決方案，比如物流云、航天云等。

總的來說，基于業務定義的邊緣計算，更多是面向智能設備及實體產業，對智能設備，從 AVG，密集式存儲，機械手臂等單一功能的智能設備，到無人機，無人駕駛車等超復雜的智能設備，云計算能力不僅支撐設備控制管理應用的運行，同時借助中心云計算能力拓展至邊緣側，解決這種產品上云，無法集中化標準化管理難題;對產業邊緣，通過云計算技術，結合行業場景的抽象總結，構建行業通用的產品及解決方案，隨著整個產業互聯網加速建設，是邊緣計算未來發展的重點方向。

小結

對于規模較大的企業，云邊場景非常復雜，中心云計算平臺與邊緣計算平臺建設，不僅應對業務需求，還要面臨諸多基礎設施問題：在中心云計算面臨多云使用多云互通問題;在邊緣網絡鏈路面臨多運營商的骨干網，多云運營商網絡及多云的云網融合問題;在端側接入網面臨多運營商 5G 網絡的共享的問題等，很多問題只能通過治理的手段應對，無法從技術平臺層面徹底解決。

總的來說，邊緣計算范圍大，場景泛，目前整個行業缺少經典的案例及標準。因此推動邊緣計算落地，一定是面向真實的業務場景及需求整體規劃，面向價值逐步建設。

Kubernetes 從中心走向邊緣

Kubernetes 遵循以應用為中心的技術架構與思想，以一套技術體系支持任意負載，運行于任意基礎設施之上;向下屏蔽基礎設施差異，實現底層基礎資源統一調度及編排;向上通過容器鏡像標準化應用，實現應用負載自動化部署;向外突破中心云計算的邊界，將云計算能力無縫拓展至邊緣及現場，快速構建云邊一體基礎設施。

將云原生技術從中心拓展到邊緣，不僅實現了云邊基礎設施技術架構大一統，業務也實現了云邊自由編排部署。相對于 Kubernetes 在中心云的革命性創新，在邊緣場景雖優勢明顯，但缺點也很致命，因為邊緣側存在資源有限、網絡受限不穩定等特殊情況，需要根據不同業務場景，選擇不同 Kubernetes 邊緣方案。

Kubernetes 架構及邊緣化的挑戰

Kubernetes 是典型的分布式架構，Master 控制節點是集群“大腦”，負責管理節點，調度 Pod 以及控制集群運行狀態。Node 工作節點，負責運行容器(Container)，監控/上報運行狀態。邊緣計算場景存在以下比較明顯的挑戰：

狀態強一致且集中式存儲架構，屬于中心云計算的大成產品，基于大規模的池化資源的編排調度實現業務持續服務。 Master 管控節點與 Worker 工作節點通過 List-Watch 機制，實現狀態任務實時同步，但是流量較大，Worker 工作節點完全依賴 Master 節點持久化數據，無自治能力。 Kubelet 承載太多邏輯處理，各種容器運行時各種實現的兼容，還有 Device Plugin 硬件設備驅動，運行占用資源高達 700M;對資源有限的邊緣節點負擔太重，尤其是低配的邊緣設備。

邊緣計算涉及的范圍大、場景復雜，尚無統一標準;Kubernetes 開源社區的主線版本并無邊緣場景的適配計劃。

Kubernetes 邊緣化運行方案

針對中心云計算及邊緣計算這種云邊分布式架構，需要將 Kubernetes 適配成適合邊緣分布式部署的架構，通過多集群管理實現統一管理，實現中心云管理邊緣運行，整體分為三種方案：

集群 Cluster：將 Kubernetes 標準集群下沉至邊緣，優點是無需 Kubernetes 做定制化研發，同時可以支持 Kubernetes 多版本，支持業務真正實現云邊架構一致;缺點是管理資源占用多。方案比較適合區域云/中心云、邊緣計算/本地計算以及規模較大的產業邊緣場景。 單節點 Single Node：將 Kubernetes 精簡，部署在單節點設備之上，優點與集群 Cluster 方案一致，缺點是 Kubernetes 能力不完整，資源的占用會增加設備的成本，對業務應用無法保證云邊一致的架構部署運行，沒有解決實際問題。 邊緣節點 Remote Node：基于Kubernetes 二次開發增強擴展，將 Kubernetes 解耦適配成云邊分布式架構的場景，中心化部署 Master 管理節點，分散式部署 Worker 管理節點。

此外，一致性是邊緣計算的痛點，在邊緣增加一個 Cache 即可實現斷網特殊情況的邊緣自治，同時可以保證正常網絡情況的數據一致;還有就是 Kubelet 比較重的問題，隨著 Kubernetes 放棄 Docker 已經開始精簡;同時硬件更新迭代較快，相比少量硬件成本，保持 Kubernetes 原生及通用性為大。其實更希望Kubernetes 社區本身提供適配邊緣化方案，同時考慮為 Kubelet 增加緩存機制。

Kubernetes 邊緣容器快速發展

Kubernetes 已成為容器編排和調度的事實標準，針對邊緣計算場景，目前國內各個公有云廠商都開源了各自基于 Kubernetes 的邊緣計算云原生項目，比如阿里云向 CNCF 貢獻的 OpenYurt，采用邊緣節點 Remote Node 方案，是業界首個開源的非侵入式邊緣計算云原生平臺，秉承“Extending your native Kubernetes to Edge”的非侵入式設計理念，擁有可實現邊緣計算全場景覆蓋的能力。

華為、騰訊、百度等，也都開源了自己的邊緣容器平臺。邊緣容器的快速發展帶動了領域的創新，但一定程度上也導致構建邊緣計算平臺時難以抉擇。從技術架構來看，幾個邊緣容器產品總的架構思路主要是將 Kubernetes 解耦成適合云邊、弱網絡及資源稀缺的邊緣計算場景，本質上無太大差異;從產品功能來看也是如此，基本上都涵蓋云邊協同、邊緣自治、單元化部署功能等。

如何構建云邊一體化云原生平臺

現階段，圍繞 Kubernetes 容器平臺，構建云邊一體化云原生基礎設施平臺能力是邊緣計算平臺的好選擇，通過云端統一的容器多集群管理，實現分散式集群統一管理，同時標準化 Kubernetes 集群規格配置：

標準集群(大規模)：支持超過 400 個節點的大規模集群，配置為 ETCD + Master 3 臺 8c16G，Prometheus + Ingress 5 臺 8C16G， N * Work 節點;主要是業務規模較大的云原生應用運行場景; 標準集群(中等規模)：支持超過 100 個節點以內的集群，ETCD + Master + Prometheus 3 臺 8c16G，N * Work 節點;主要是業務規模中等的場景; 邊緣原生容器集群：在云端部署集群管理節點，將邊緣節點單獨部署業務現場，支持運行單業務場景的應用，比如 IoT 物理設備接入協議解析應用，視頻監控分析 AI 算法模型等業務場景。

按照業務場景需求選擇最優容器集群方案，其中邊緣容器集群方案，與其他集群方案差別較大，其他集群依然保持中心云集群服務一致，基礎資源集中并且池化，所有應用共享整個集群資源;而邊緣容器集群Master 管理節點集中部署，共享使用;Worker 節點都是分散在業務現場，按需自助增加，自運維且獨占使用。當前邊緣容器領域短時間內很難有大一統的開源產品，因此現階段建議通過標準的 Kubernetes API 來集成邊緣原生容器集群，這種兼容所有邊緣容器的中庸方案，如果非要擇其一，建議是 OpenYurt，非侵入式設計，整體技術架構及實現更加優雅。OpenYurt 以上游開源項目 Kubernetes 為基礎，針對邊緣場景適配的發行版。是業界首個依托云原生技術體系、“零”侵入實現的智能邊緣計算平臺。具備全方位的“云、邊、端一體化”能力，能夠快速實現海量邊緣計算業務和異構算力的高效交付、運維及管理。

總結

邊緣計算平臺的建設，以 Kubernetes 為核心的云原生技術體系，無疑是當前好的選擇與建設路徑。但是云原生體系龐大，組件復雜，將體系下沉至邊緣會面臨很大的挑戰與困難，同時充滿巨大的機遇及想象空間。業務應用想要真正踐行邊緣的云原生體系，需要從理念、系統設計、架構設計等多方面來共同實現，才能充分發揮邊緣的優勢及價值。

當前標題：對邊緣計算與云原生的理解與思考
分享網址：http://m.newbst.com/news16/201566.html

成都網站建設公司_創新互聯，為您提供自適應網站、電子商務、網站維護、App開發、全網營銷推廣、手機網站建設

廣告

聲明：本網站發布的內容（圖片、視頻和文字）以用戶投稿、用戶轉載內容為主，如果涉及侵權請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網站立場，如需處理請聯系客服。電話：028-86922220；郵箱：631063699@qq.com。內容未經允許不得轉載，或轉載時需注明來源： 創新互聯