從中心走向邊緣——深度解析云原生邊緣計(jì)算落地痛點(diǎn)

段嘉/新勝
邊緣是相對中心式計(jì)算的邊緣分散式計(jì)算。邊緣計(jì)算的核心目標(biāo)是快速決策,將中心云的計(jì)算能力拓展至“最后一公里”。因此它不能獨(dú)立于中心云,而是在云-邊-端的整體架構(gòu)之下,有中心式管控決策,也有分散式邊緣自主決策,即章魚式邊緣計(jì)算。

2345截圖20211028093243.png

云計(jì)算發(fā)展史,就是虛擬化技術(shù)的發(fā)展史。近20年來云計(jì)算與互聯(lián)網(wǎng)相互促進(jìn)高速發(fā)展,中心云技術(shù)成為全社會通用的基礎(chǔ)設(shè)施。隨著物聯(lián)網(wǎng)、人工智能等技術(shù)的不斷發(fā)展,尤其是產(chǎn)業(yè)互聯(lián)網(wǎng)發(fā)展落地,中心云計(jì)算開始相形見絀,分散式邊緣計(jì)算在當(dāng)下被重新寄予厚望。如果中心云計(jì)算是由技術(shù)創(chuàng)新驅(qū)動的,那么邊緣計(jì)算一定是業(yè)務(wù)價(jià)值驅(qū)動的。

2345截圖20211028093243.png

那到底什么是邊緣計(jì)算?邊緣計(jì)算有哪些分類?邊緣計(jì)算與中心云的關(guān)系是什么?本文將抽絲剝繭,深入淺出,詳細(xì)闡述對邊緣計(jì)算與云原生的理解與思考。

一邊緣計(jì)算的理解與思考

1邊緣計(jì)算的定義

邊緣計(jì)算當(dāng)前沒有準(zhǔn)確定義,從IT云計(jì)算領(lǐng)域視角,邊緣計(jì)算被看作中心云計(jì)算的拓展。邊緣計(jì)算產(chǎn)業(yè)聯(lián)盟對邊緣計(jì)算的定義:“在靠近物或數(shù)據(jù)源頭的網(wǎng)絡(luò)邊緣側(cè),融合網(wǎng)絡(luò)、計(jì)算、存儲、應(yīng)用核心能力的開放平臺,就近提供邊緣智能服務(wù),滿足行業(yè)數(shù)字化在敏捷連接、實(shí)時(shí)業(yè)務(wù)、數(shù)據(jù)優(yōu)化、應(yīng)用智能、安全與隱私保護(hù)等方面的關(guān)鍵需求”。從CT電信領(lǐng)域視角,邊緣計(jì)算最初也被稱為移動邊緣計(jì)算(MEC)。歐洲電信標(biāo)準(zhǔn)協(xié)會(ETSI)對MEC的定義:“移動邊緣計(jì)算在移動網(wǎng)絡(luò)的邊緣、無線接入網(wǎng)(RAN)的內(nèi)部以及移動用戶的近處提供了一個(gè)IT服務(wù)環(huán)境以及云計(jì)算能力”。

邊緣計(jì)算的定義各有側(cè)重,但核心思想基本一致——邊緣計(jì)算是基于云計(jì)算核心技術(shù),構(gòu)建在邊緣基礎(chǔ)設(shè)施之上的新型分布式計(jì)算形式,在邊緣端靠近最終用戶提供計(jì)算能力,是一種靠近數(shù)據(jù)源的現(xiàn)場云計(jì)算。

中心云計(jì)算憑借其強(qiáng)大的數(shù)據(jù)中心,為業(yè)務(wù)應(yīng)用提供大規(guī)模池化,彈性擴(kuò)展的計(jì)算、存儲、網(wǎng)絡(luò)等基礎(chǔ)設(shè)施服務(wù),更適用于非實(shí)時(shí)、長周期數(shù)據(jù)、業(yè)務(wù)決策場景;邊緣計(jì)算則聚焦在實(shí)時(shí)性、短周期數(shù)據(jù)、本地決策等業(yè)務(wù)場景,比如當(dāng)下熱門的音視頻直播、IoT、產(chǎn)業(yè)互聯(lián)網(wǎng)、虛擬現(xiàn)實(shí)甚至元宇宙等,將工作負(fù)載下沉至離終端設(shè)備或者靠近最終用戶的地方,以此實(shí)現(xiàn)更低的網(wǎng)絡(luò)延遲,提升用戶的使用體驗(yàn)。

2“章魚式”邊緣計(jì)算

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

2345截圖20211028093243.png

如上圖漫畫中所示,章魚全身神經(jīng)元中心式腦部占40%,其余60%在分散式腿部,形成1個(gè)大腦總控協(xié)調(diào)+N個(gè)小腦分散執(zhí)行的結(jié)構(gòu)。1個(gè)大腦擅長全局調(diào)度,進(jìn)行非實(shí)時(shí)、長周期的大數(shù)據(jù)處理與分析;N個(gè)小腦側(cè)重局部、小規(guī)模數(shù)據(jù)處理,適用于現(xiàn)場級、實(shí)時(shí)、短周期的智能分析與快速決策。

章魚式邊緣計(jì)算采用中心云+邊緣計(jì)算的分布式云邊一體化架構(gòu),海量終端采集到數(shù)據(jù)后,在邊緣完成小規(guī)模局部數(shù)據(jù)的實(shí)時(shí)決策處理,而復(fù)雜大規(guī)模的全局性決策處理則匯總至中心云深入分析處理。

3邊緣計(jì)算的位置

2345截圖20211028093243.png

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

云計(jì)算能力由中心逐步下沉到邊緣,節(jié)點(diǎn)數(shù)量增多,覆蓋范圍縮小,運(yùn)維服務(wù)成本快速增加。根據(jù)國內(nèi)網(wǎng)絡(luò)(國內(nèi)有多張骨干網(wǎng),分別是電信CHINANET與CN2,聯(lián)通CNCNET以及移動CMNET)現(xiàn)狀,骨干網(wǎng)節(jié)點(diǎn),城際網(wǎng)節(jié)點(diǎn),匯聚網(wǎng)節(jié)點(diǎn),接入網(wǎng)節(jié)點(diǎn),以及數(shù)以萬計(jì)的業(yè)務(wù)現(xiàn)場計(jì)算節(jié)點(diǎn)都可以安置邊緣計(jì)算,因此范圍太廣難以形成統(tǒng)一標(biāo)準(zhǔn)。因此我們說中心云計(jì)算由技術(shù)定義,邊緣計(jì)算由網(wǎng)絡(luò)與業(yè)務(wù)需求定義。

邊緣計(jì)算生態(tài)參與者眾多,云廠商、設(shè)備廠商、運(yùn)營商三大關(guān)鍵服務(wù)商方以及一些新型AI服務(wù)商等,都是從各自現(xiàn)有優(yōu)勢延伸,拓展更多客戶及市場空間。設(shè)備商借助物聯(lián)網(wǎng)逐漸構(gòu)建單一功能的專業(yè)云;云廠商從中心化的公有云開始下沉,走向分布式區(qū)域云,區(qū)域云之間通過云聯(lián)網(wǎng)打通,形成一個(gè)覆蓋更大的云。運(yùn)營商在互聯(lián)網(wǎng)時(shí)代被公有云及繁榮的移動應(yīng)用完全屏蔽只能充當(dāng)管道,但在邊緣計(jì)算時(shí)代,業(yè)務(wù)及網(wǎng)絡(luò)定義邊緣計(jì)算,運(yùn)營商重新回歸焦點(diǎn),不可替代。

4邊緣計(jì)算的類型

2345截圖20211028093243.png

(1)網(wǎng)絡(luò)定義的邊緣計(jì)算:

通過優(yōu)化終端與云中心網(wǎng)絡(luò)路徑,將中心云能力逐漸下沉至靠近終端,實(shí)現(xiàn)業(yè)務(wù)就近接入訪問。從中心到邊緣依次分為區(qū)域云/中心云,邊緣云/邊緣計(jì)算,邊緣計(jì)算/本地計(jì)算三大類型:

區(qū)域云/中心云:將中心云計(jì)算的服務(wù)在骨干網(wǎng)拓展延伸,將中心化云能力拓展至區(qū)域,實(shí)現(xiàn)區(qū)域全覆蓋,解決在骨干網(wǎng)上耗時(shí),將網(wǎng)絡(luò)延遲優(yōu)化至30ms左右,但邏輯上仍是中心云服務(wù)。

邊緣云/邊緣計(jì)算:將中心云計(jì)算的服務(wù)沿著運(yùn)營商的網(wǎng)絡(luò)節(jié)點(diǎn)延伸,構(gòu)建中小規(guī)模云服務(wù)或類云服務(wù)能力,將網(wǎng)絡(luò)延遲優(yōu)化至15ms左右,比如多接入邊緣計(jì)算(MEC)、CDN。

邊緣計(jì)算/本地計(jì)算:主要是接近終端的現(xiàn)場設(shè)備及服務(wù)能力,將終端部分邏輯剝離出來,實(shí)現(xiàn)邊緣自主的智能服務(wù),由云端控制邊緣的資源調(diào)度、應(yīng)用管理與業(yè)務(wù)編排等能力,將網(wǎng)絡(luò)延遲優(yōu)化至5ms左右,比如多功能一體機(jī)、智能路由器等。

總的來說,基于網(wǎng)絡(luò)定義的邊緣計(jì)算,更多是面向消費(fèi)互聯(lián)業(yè)務(wù)及新型2C業(yè)務(wù),將云中心的能力及數(shù)據(jù)提前下沉至邊緣,除了經(jīng)典的CDN,視頻語音業(yè)務(wù)外,還有今年大火的元宇宙等。

當(dāng)前大部分面向消費(fèi)互聯(lián)業(yè)務(wù)都是通過安置在骨干網(wǎng)的中心云計(jì)算能力支持,時(shí)延在30ms到50ms,遠(yuǎn)小于本身云端后端業(yè)務(wù)處理的延遲;算力下沉至邊緣的初衷,主要是實(shí)現(xiàn)中心云海量請求壓力分散,用戶體驗(yàn)優(yōu)化等,對業(yè)務(wù)都屬于錦上添花,而非雪中送炭。

2345截圖20211028093243.png

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

當(dāng)前,網(wǎng)絡(luò)的能力極大限制了云計(jì)算的發(fā)展,在邊緣計(jì)算及物聯(lián)網(wǎng)建設(shè)過程中尤為明顯;云網(wǎng)融合與算力網(wǎng)絡(luò)依然還是運(yùn)營商的獨(dú)家游戲,新一代5G顛覆性技術(shù)變革,引爆整個(gè)領(lǐng)域的顛覆性巨變,也只解決了海量設(shè)備接入及設(shè)備低延遲接入的問題,后端整體配套及解決方案明顯跟不上。就當(dāng)前情況來看,依然還是5G找業(yè)務(wù)的尷尬局面,未來5G在實(shí)體產(chǎn)業(yè)領(lǐng)域(港口,碼頭,礦山等)領(lǐng)域,相比消費(fèi)者領(lǐng)域,相信會帶來更大變革與價(jià)值。

(2)業(yè)務(wù)定義的邊緣計(jì)算:

2345截圖20211028093243.png

除了面向消費(fèi)者的互聯(lián)網(wǎng)邊緣場景,邊緣計(jì)算更多的是面向?qū)嶓w產(chǎn)業(yè)及智慧化社會衍生的場景。

對于實(shí)體產(chǎn)業(yè)場景來說,由于歷史原因,在邊緣及現(xiàn)場存在大量異構(gòu)的基礎(chǔ)設(shè)施資源;通過業(yè)務(wù)需求驅(qū)動邊緣計(jì)算平臺的建設(shè),不僅要整合利用現(xiàn)有基礎(chǔ)設(shè)施資源,還要將中心云計(jì)算技術(shù)及能力下沉至邊緣及現(xiàn)場,實(shí)現(xiàn)大量存量業(yè)務(wù)運(yùn)營管控上云,海量數(shù)據(jù)統(tǒng)一入湖,以此支持整個(gè)企業(yè)的數(shù)字化轉(zhuǎn)型。

對于智慧化社會衍生場景來說,越是新型的業(yè)務(wù),對網(wǎng)絡(luò)時(shí)延敏感越高,數(shù)據(jù)量越大,結(jié)構(gòu)化數(shù)據(jù)逐漸轉(zhuǎn)化成非結(jié)構(gòu)化數(shù)據(jù),需要人工智能,神經(jīng)網(wǎng)絡(luò)等高等智能化技術(shù)支持。

當(dāng)前對網(wǎng)絡(luò)時(shí)延敏感的新型業(yè)務(wù)場景,都是通過云端總控管理,設(shè)備現(xiàn)場實(shí)時(shí)計(jì)算這種分布式架構(gòu)策略,以此減弱對網(wǎng)絡(luò)的強(qiáng)依賴。面向業(yè)務(wù)將邊緣計(jì)算分為智能設(shè)備/專業(yè)云及產(chǎn)業(yè)邊緣/行業(yè)云兩種類型:

智能設(shè)備/專業(yè)云:基于云計(jì)算能力之上,圍繞智能設(shè)備提供整體化,有競爭力的解決方案,包含智能設(shè)備、云端的服務(wù)以及端到云之間的邊緣側(cè)服務(wù),比如視頻監(jiān)控云、G7貨運(yùn)物聯(lián)等;

產(chǎn)業(yè)邊緣/行業(yè)云:也基于云計(jì)算能力之上,圍繞行業(yè)應(yīng)用及場景,提供套件產(chǎn)品及解決方案,比如物流云、航天云等。

總的來說,基于業(yè)務(wù)定義的邊緣計(jì)算,更多是面向智能設(shè)備及實(shí)體產(chǎn)業(yè),對智能設(shè)備,從AVG,密集式存儲,機(jī)械手臂等單一功能的智能設(shè)備,到無人機(jī),無人駕駛車等超復(fù)雜的智能設(shè)備,云計(jì)算能力不僅支撐設(shè)備控制管理應(yīng)用的運(yùn)行,同時(shí)借助中心云計(jì)算能力拓展至邊緣側(cè),解決這種產(chǎn)品上云,無法集中化標(biāo)準(zhǔn)化管理難題;對產(chǎn)業(yè)邊緣,通過云計(jì)算技術(shù),結(jié)合行業(yè)場景的抽象總結(jié),構(gòu)建行業(yè)通用的產(chǎn)品及解決方案,隨著整個(gè)產(chǎn)業(yè)互聯(lián)網(wǎng)加速建設(shè),是邊緣計(jì)算未來發(fā)展的重點(diǎn)方向。

5小結(jié)

2345截圖20211028093243.png

對于規(guī)模較大的企業(yè),云邊場景非常復(fù)雜,中心云計(jì)算平臺與邊緣計(jì)算平臺建設(shè),不僅應(yīng)對業(yè)務(wù)需求,還要面臨諸多基礎(chǔ)設(shè)施問題:在中心云計(jì)算面臨多云使用多云互通問題;在邊緣網(wǎng)絡(luò)鏈路面臨多運(yùn)營商的骨干網(wǎng),多云運(yùn)營商網(wǎng)絡(luò)及多云的云網(wǎng)融合問題;在端側(cè)接入網(wǎng)面臨多運(yùn)營商5G網(wǎng)絡(luò)的共享的問題等,很多問題只能通過治理的手段應(yīng)對,無法從技術(shù)平臺層面徹底解決。

總的來說,邊緣計(jì)算范圍大,場景泛,目前整個(gè)行業(yè)缺少經(jīng)典的案例及標(biāo)準(zhǔn)。因此推動邊緣計(jì)算落地,一定是面向真實(shí)的業(yè)務(wù)場景及需求整體規(guī)劃,面向價(jià)值逐步建設(shè)。

二Kubernetes從中心走向邊緣

Kubernetes遵循以應(yīng)用為中心的技術(shù)架構(gòu)與思想,以一套技術(shù)體系支持任意負(fù)載,運(yùn)行于任意基礎(chǔ)設(shè)施之上;向下屏蔽基礎(chǔ)設(shè)施差異,實(shí)現(xiàn)底層基礎(chǔ)資源統(tǒng)一調(diào)度及編排;向上通過容器鏡像標(biāo)準(zhǔn)化應(yīng)用,實(shí)現(xiàn)應(yīng)用負(fù)載自動化部署;向外突破中心云計(jì)算的邊界,將云計(jì)算能力無縫拓展至邊緣及現(xiàn)場,快速構(gòu)建云邊一體基礎(chǔ)設(shè)施。

2345截圖20211028093243.png

將云原生技術(shù)從中心拓展到邊緣,不僅實(shí)現(xiàn)了云邊基礎(chǔ)設(shè)施技術(shù)架構(gòu)大一統(tǒng),業(yè)務(wù)也實(shí)現(xiàn)了云邊自由編排部署。相對于Kubernetes在中心云的革命性創(chuàng)新,在邊緣場景雖優(yōu)勢明顯,但缺點(diǎn)也很致命,因?yàn)檫吘墏?cè)存在資源有限、網(wǎng)絡(luò)受限不穩(wěn)定等特殊情況,需要根據(jù)不同業(yè)務(wù)場景,選擇不同Kubernetes邊緣方案。

1 Kubernetes架構(gòu)及邊緣化的挑戰(zhàn)

Kubernetes是典型的分布式架構(gòu),Master控制節(jié)點(diǎn)是集群“大腦”,負(fù)責(zé)管理節(jié)點(diǎn),調(diào)度Pod以及控制集群運(yùn)行狀態(tài)。Node工作節(jié)點(diǎn),負(fù)責(zé)運(yùn)行容器(Container),監(jiān)控/上報(bào)運(yùn)行狀態(tài)。邊緣計(jì)算場景存在以下比較明顯的挑戰(zhàn):

狀態(tài)強(qiáng)一致且集中式存儲架構(gòu),屬于中心云計(jì)算的大成產(chǎn)品,基于大規(guī)模的池化資源的編排調(diào)度實(shí)現(xiàn)業(yè)務(wù)持續(xù)服務(wù)。

Master管控節(jié)點(diǎn)與Worker工作節(jié)點(diǎn)通過List-Watch機(jī)制,實(shí)現(xiàn)狀態(tài)任務(wù)實(shí)時(shí)同步,但是流量較大,Worker工作節(jié)點(diǎn)完全依賴Master節(jié)點(diǎn)持久化數(shù)據(jù),無自治能力。

Kubelet承載太多邏輯處理,各種容器運(yùn)行時(shí)各種實(shí)現(xiàn)的兼容,還有Device Plugin硬件設(shè)備驅(qū)動,運(yùn)行占用資源高達(dá)700M;對資源有限的邊緣節(jié)點(diǎn)負(fù)擔(dān)太重,尤其是低配的邊緣設(shè)備。

邊緣計(jì)算涉及的范圍大、場景復(fù)雜,尚無統(tǒng)一標(biāo)準(zhǔn);Kubernetes開源社區(qū)的主線版本并無邊緣場景的適配計(jì)劃。

2 Kubernetes邊緣化運(yùn)行方案

2345截圖20211028093243.png

針對中心云計(jì)算及邊緣計(jì)算這種云邊分布式架構(gòu),需要將Kubernetes適配成適合邊緣分布式部署的架構(gòu),通過多集群管理實(shí)現(xiàn)統(tǒng)一管理,實(shí)現(xiàn)中心云管理邊緣運(yùn)行,整體分為三種方案:

集群Cluster:將Kubernetes標(biāo)準(zhǔn)集群下沉至邊緣,優(yōu)點(diǎn)是無需Kubernetes做定制化研發(fā),同時(shí)可以支持Kubernetes多版本,支持業(yè)務(wù)真正實(shí)現(xiàn)云邊架構(gòu)一致;缺點(diǎn)是管理資源占用多。方案比較適合區(qū)域云/中心云、邊緣計(jì)算/本地計(jì)算以及規(guī)模較大的產(chǎn)業(yè)邊緣場景。

單節(jié)點(diǎn)Single Node:將Kubernetes精簡,部署在單節(jié)點(diǎn)設(shè)備之上,優(yōu)點(diǎn)與集群Cluster方案一致,缺點(diǎn)是Kubernetes能力不完整,資源的占用會增加設(shè)備的成本,對業(yè)務(wù)應(yīng)用無法保證云邊一致的架構(gòu)部署運(yùn)行,沒有解決實(shí)際問題。

邊緣節(jié)點(diǎn)Remote Node:基于Kubernetes二次開發(fā)增強(qiáng)擴(kuò)展,將Kubernetes解耦適配成云邊分布式架構(gòu)的場景,中心化部署Master管理節(jié)點(diǎn),分散式部署Worker管理節(jié)點(diǎn)。

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

3 Kubernetes邊緣容器快速發(fā)展

Kubernetes已成為容器編排和調(diào)度的事實(shí)標(biāo)準(zhǔn),針對邊緣計(jì)算場景,目前國內(nèi)各個(gè)公有云廠商都開源了各自基于Kubernetes的邊緣計(jì)算云原生項(xiàng)目,比如阿里云向CNCF貢獻(xiàn)的OpenYurt,采用邊緣節(jié)點(diǎn)Remote Node方案,是業(yè)界首個(gè)開源的非侵入式邊緣計(jì)算云原生平臺,秉承“Extending your native Kubernetes to Edge”的非侵入式設(shè)計(jì)理念,擁有可實(shí)現(xiàn)邊緣計(jì)算全場景覆蓋的能力。華為、騰訊、百度等,也都開源了自己的邊緣容器平臺。

邊緣容器的快速發(fā)展帶動了領(lǐng)域的創(chuàng)新,但一定程度上也導(dǎo)致構(gòu)建邊緣計(jì)算平臺時(shí)難以抉擇。從技術(shù)架構(gòu)來看,幾個(gè)邊緣容器產(chǎn)品總的架構(gòu)思路主要是將Kubernetes解耦成適合云邊、弱網(wǎng)絡(luò)及資源稀缺的邊緣計(jì)算場景,本質(zhì)上無太大差異;從產(chǎn)品功能來看也是如此,基本上都涵蓋云邊協(xié)同、邊緣自治、單元化部署功能等。

4如何構(gòu)建云邊一體化云原生平臺

2345截圖20211028093243.png

現(xiàn)階段,圍繞Kubernetes容器平臺,構(gòu)建云邊一體化云原生基礎(chǔ)設(shè)施平臺能力是邊緣計(jì)算平臺的最佳選擇,通過云端統(tǒng)一的容器多集群管理,實(shí)現(xiàn)分散式集群統(tǒng)一管理,同時(shí)標(biāo)準(zhǔn)化Kubernetes集群規(guī)格配置:

標(biāo)準(zhǔn)集群(大規(guī)模):支持超過400個(gè)節(jié)點(diǎn)的大規(guī)模集群,配置為ETCD+Master 3臺8c16G,Prometheus+Ingress 5臺8C16G,N*Work節(jié)點(diǎn);主要是業(yè)務(wù)規(guī)模較大的云原生應(yīng)用運(yùn)行場景;

標(biāo)準(zhǔn)集群(中等規(guī)模):支持超過100個(gè)節(jié)點(diǎn)以內(nèi)的集群,ETCD+Master+Prometheus 3臺8c16G,N*Work節(jié)點(diǎn);主要是業(yè)務(wù)規(guī)模中等的場景;

邊緣原生容器集群:在云端部署集群管理節(jié)點(diǎn),將邊緣節(jié)點(diǎn)單獨(dú)部署業(yè)務(wù)現(xiàn)場,支持運(yùn)行單業(yè)務(wù)場景的應(yīng)用,比如IoT物理設(shè)備接入?yún)f(xié)議解析應(yīng)用,視頻監(jiān)控分析AI算法模型等業(yè)務(wù)場景。

按照業(yè)務(wù)場景需求選擇最優(yōu)容器集群方案,其中邊緣容器集群方案,與其他集群方案差別較大,其他集群依然保持中心云集群服務(wù)一致,基礎(chǔ)資源集中并且池化,所有應(yīng)用共享整個(gè)集群資源;而邊緣容器集群Master管理節(jié)點(diǎn)集中部署,共享使用;Worker節(jié)點(diǎn)都是分散在業(yè)務(wù)現(xiàn)場,按需自助增加,自運(yùn)維且獨(dú)占使用。

當(dāng)前邊緣容器領(lǐng)域短時(shí)間內(nèi)很難有大一統(tǒng)的開源產(chǎn)品,因此現(xiàn)階段建議通過標(biāo)準(zhǔn)的Kubernetes API來集成邊緣原生容器集群,這種兼容所有邊緣容器的中庸方案,如果非要擇其一,建議是OpenYurt,非侵入式設(shè)計(jì),整體技術(shù)架構(gòu)及實(shí)現(xiàn)更加優(yōu)雅。

三OpenYurt:智能邊緣計(jì)算平臺開源實(shí)踐

OpenYurt以上游開源項(xiàng)目Kubernetes為基礎(chǔ),針對邊緣場景適配的發(fā)行版。是業(yè)界首個(gè)依托云原生技術(shù)體系、“零”侵入實(shí)現(xiàn)的智能邊緣計(jì)算平臺。具備全方位的“云、邊、端一體化”能力,能夠快速實(shí)現(xiàn)海量邊緣計(jì)算業(yè)務(wù)和異構(gòu)算力的高效交付、運(yùn)維及管理。

1設(shè)計(jì)原則

2345截圖20211028093243.png

OpenYurt采用當(dāng)前業(yè)界主流的“中心管控、邊緣運(yùn)行”的云邊分布式協(xié)同技術(shù)架構(gòu),始終貫徹“Extending your native Kubernetes to Edge”理念,同時(shí)遵守以下設(shè)計(jì)原則:

“云邊一體化”原則:保證與中心云一致的用戶體驗(yàn)及產(chǎn)品能力的基礎(chǔ)上,通過云邊管控通道將云原生能力下沉至邊緣,實(shí)現(xiàn)海量的智能邊緣節(jié)點(diǎn)及業(yè)務(wù)應(yīng)用,基礎(chǔ)架構(gòu)提升至業(yè)界領(lǐng)的云原生架構(gòu)的重大突破。

“零侵入”原則:確保面向用戶開放的API與原生Kubernetes完全一致。通過節(jié)點(diǎn)網(wǎng)絡(luò)流量代理方式(proxy node network traffic),對Worker工作節(jié)點(diǎn)應(yīng)用生命周期管理新增一層封裝抽象,實(shí)現(xiàn)分散式工作節(jié)點(diǎn)資源及應(yīng)用統(tǒng)一管理及調(diào)度。同時(shí)遵循“UpStream First”開源法則;

“低負(fù)載”原則:在保障平臺功能特性及可靠性的基礎(chǔ)上,兼顧平臺的通用性,嚴(yán)格限制所有組件的資源,遵循最小化,最簡化的設(shè)計(jì)理念,以此實(shí)現(xiàn)最大化覆蓋邊緣設(shè)備及場景。

“一棧式”原則:OpenYurt不僅實(shí)現(xiàn)了邊緣運(yùn)行及管理的增強(qiáng)功能,還提供了配套的運(yùn)維管理工具,實(shí)現(xiàn)將原生Kubernetes與支持邊緣計(jì)算能力的Kubernetes集群的相互一鍵高效轉(zhuǎn)換;

2功能特性

2345截圖20211028093243.png

OpenYurt基于Kubernetes強(qiáng)大的容器編排、調(diào)度能力,針對邊緣資源有限,網(wǎng)絡(luò)受限不穩(wěn)定等情況適配增強(qiáng);將中心云原生能力拓展至分散式邊緣節(jié)點(diǎn),實(shí)現(xiàn)面向邊緣業(yè)務(wù)就近低延遲服務(wù);同時(shí)打通反向安全控制運(yùn)維鏈路,提供便捷高效的,云端集中式邊緣設(shè)備及應(yīng)用的統(tǒng)一運(yùn)維管理能力。其核心功能特性如下:

邊緣節(jié)點(diǎn)自治:在邊緣計(jì)算場景,云邊管控網(wǎng)絡(luò)無法保證持續(xù)穩(wěn)定,通過增強(qiáng)適配解決原生Worker工作節(jié)點(diǎn)無狀態(tài)數(shù)據(jù),強(qiáng)依賴Master管控節(jié)點(diǎn)數(shù)據(jù)且狀態(tài)強(qiáng)一致機(jī)制,這些在邊緣場景不適配的問題。從而實(shí)現(xiàn)在云邊網(wǎng)絡(luò)不暢的情況下,邊緣工作負(fù)載不被驅(qū)逐,業(yè)務(wù)持續(xù)正常服務(wù);即使斷網(wǎng)時(shí)邊緣節(jié)點(diǎn)重啟,業(yè)務(wù)依然能恢復(fù)正常;即邊緣節(jié)點(diǎn)臨時(shí)自治能力。

協(xié)同運(yùn)維通道:在邊緣計(jì)算場景,云邊網(wǎng)絡(luò)不在同一網(wǎng)絡(luò)平面,邊緣節(jié)點(diǎn)也不會暴露在公網(wǎng)之上,中心管控?zé)o法與邊緣節(jié)點(diǎn)建立有效的網(wǎng)絡(luò)鏈路通道,導(dǎo)致所有原生的Kubernetes運(yùn)維APIs(logs/exec/metrics)失效。適配增強(qiáng)Kubernetes能力,在邊緣點(diǎn)初始化時(shí),在中心管控與邊緣節(jié)點(diǎn)之間建立反向通道,承接原生的Kubernetes運(yùn)維APIs(logs/exec/metrics)流量,實(shí)現(xiàn)中心化統(tǒng)一運(yùn)維;

邊緣單元化負(fù)載:在邊緣計(jì)算場景,面向業(yè)務(wù)一般都是“集中式管控,分散式運(yùn)行”這種云邊協(xié)同分布式架構(gòu);對于管理端,需要將相同的業(yè)務(wù)同時(shí)部署到不同地域節(jié)點(diǎn);對于邊緣端,Worker工作節(jié)是一般是分散在廣域空間,并且具有較強(qiáng)的地域性,跨地域的節(jié)點(diǎn)之間網(wǎng)絡(luò)不互通、資源不共享、資源異構(gòu)等明顯的隔離屬性。適配增強(qiáng)Kubernetes能力,基于資源,應(yīng)用及流量三層實(shí)現(xiàn)對邊緣負(fù)載進(jìn)行單元化管理調(diào)度。

通過OpenYurt開源社區(qū)引入更多的參與方共建,聯(lián)合研發(fā)方式提供更多的可選的專業(yè)功能,OpenYurt特性正在逐步完善,并擴(kuò)大覆蓋能力:

邊緣設(shè)備管理:在邊緣計(jì)算場景,端側(cè)設(shè)備才是平臺真正的服務(wù)對象;基于云原生理念,抽象非侵入、可擴(kuò)展的設(shè)備管理標(biāo)準(zhǔn)模型,無縫融合Kubernetes工作負(fù)載模型與IoT設(shè)備管理模型,實(shí)現(xiàn)平臺賦能業(yè)務(wù)的最后一公里。目前,通過標(biāo)準(zhǔn)模型完成EdgeX Foundry開源項(xiàng)目的集成,極大的提升了邊緣設(shè)備的管理效率。

本地資源管理:在邊緣計(jì)算場景,將邊緣節(jié)點(diǎn)上已有的塊設(shè)備或者持久化內(nèi)存設(shè)備,初始化成云原生便捷使用的容器存儲,支持兩種本地存儲設(shè)備:(一)基于塊設(shè)備或者是持久化內(nèi)存設(shè)備創(chuàng)建的LVM;(二)基于塊設(shè)備或者是持久化內(nèi)存設(shè)備創(chuàng)建的QuotaPath。

3 OpenYurt設(shè)計(jì)架構(gòu)及原理

(1)設(shè)計(jì)架構(gòu)

2345截圖20211028093243.png

原生Kubernetes是一個(gè)中心式的分布式架構(gòu),Master控制節(jié)點(diǎn)負(fù)責(zé)管理調(diào)度及控制集群運(yùn)行狀態(tài);Worker工作節(jié)點(diǎn)負(fù)責(zé)運(yùn)行容器(Container)及監(jiān)控/上報(bào)運(yùn)行狀態(tài);

OpenYurt以原生Kubernetes為基礎(chǔ),針對邊緣場景將中,心式分布式架構(gòu)(Cloud Master,Cloud Worker)解耦適配為中心化管控分散式邊緣運(yùn)行(Cloud Master,Edge Worker),形成一個(gè)中心式大腦,多個(gè)分散式小腦的章魚式云邊協(xié)同分布式架構(gòu),其主要核心點(diǎn)是:

將元數(shù)據(jù)集中式且強(qiáng)一致的狀態(tài)存儲,分散至邊緣節(jié)點(diǎn),并且調(diào)整原生Kubernetes調(diào)度機(jī)制,實(shí)現(xiàn)自治節(jié)點(diǎn)狀態(tài)異常不觸發(fā)重新調(diào)度,以此實(shí)現(xiàn)邊緣節(jié)點(diǎn)臨時(shí)自治能力;

保證Kubernetes能力完整一致,同時(shí)兼容現(xiàn)有的云原生生態(tài)體系的同時(shí),盡最大肯能將云原生體系下沉至邊緣;

將中心大規(guī)模資源池化,多應(yīng)用委托調(diào)度共享資源的模式,適配為面向地域小規(guī)模甚至單節(jié)點(diǎn)資源,實(shí)現(xiàn)邊緣場景下,更精細(xì)化的單元化工作負(fù)載編排管理;

面向邊緣實(shí)際業(yè)務(wù)場景需求,通過開放式社區(qū),無縫集成設(shè)備管理、邊緣AI、流式數(shù)據(jù)等,面向邊緣實(shí)際業(yè)務(wù)場景的開箱的通用平臺能力,賦能更多的邊緣應(yīng)用場景。

(2)實(shí)現(xiàn)原理

2345截圖20211028093243.png

OpenYurt踐行云原生架構(gòu)理念,面向邊緣計(jì)算場景實(shí)現(xiàn)云邊協(xié)同分布式架構(gòu)及中心管控邊緣運(yùn)行的能力:

針對邊緣節(jié)點(diǎn)自治能力,一方面,通過新增YurtHub組件實(shí)現(xiàn)邊緣向中心管控請求(Edge To Cloud Request)代理,并緩存機(jī)制將最新的元數(shù)據(jù)持久化在邊緣節(jié)點(diǎn);另一方面新增YurtControllerManager組件接管原生Kubernetes調(diào)度,實(shí)現(xiàn)邊緣自治節(jié)點(diǎn)狀態(tài)異常不觸發(fā)重新調(diào)度;

針對Kubernetes能力完整及生態(tài)兼容,通過新增YurtTunnel組件,構(gòu)建云邊(Cloud To Edge Request)反向通道,保證Kubectl,Promethus等中心運(yùn)維管控產(chǎn)品一致能力及用戶體驗(yàn);同時(shí)將中心其他能力下沉至邊緣,包含各不同的工作負(fù)載及Ingress路由等;

針對邊緣單元化管理能力,通過新增YurtAppManager組件,同時(shí)搭配NodePool,YurtAppSet(原UnitedDeployment),YurtAppDaemon,ServiceTopology等實(shí)現(xiàn)邊緣資源,工作負(fù)載及流量三層單元化管理;

針對賦能邊緣實(shí)際業(yè)務(wù)平臺能力,通過新增NodeResourceManager實(shí)現(xiàn)邊緣存儲便捷使用,通過引入YurtEdgeXManager/YurtDeviceController實(shí)現(xiàn)通過云原生模式管理邊緣設(shè)備。

4核心組件

2345截圖20211028093243.png

OpenYurt所有新增功能及組件,均是通過Addon與Controller方式來實(shí)現(xiàn)其核心必選與可選組件如下:

1.YurtHub(必選):有邊緣(edge)和云中心(cloud)兩種運(yùn)行模式;以Static Pod形態(tài)運(yùn)行在云邊所有節(jié)點(diǎn)上,作為節(jié)點(diǎn)流量的SideCar,代理節(jié)點(diǎn)上組件和kube-apiserver的訪問流量,其中邊緣YurtHub會緩存的數(shù)據(jù),實(shí)現(xiàn)臨時(shí)邊緣節(jié)點(diǎn)自治能力。

2.YurtTunnel(必選):由Server服務(wù)端與Agent客戶端組成,構(gòu)建雙向認(rèn)證加密的云邊反向隧道,轉(zhuǎn)發(fā)云中心(cloud)到邊緣(edge)原生的Kubernetes運(yùn)維APIs(logs/exec/metrics)請求流量。其中Server以Deployment工作負(fù)載部署在云中心,Agent以DaemonSet工作負(fù)載部署在邊緣節(jié)點(diǎn)。

3.YurtControllerManager(必選):云中心控制器,接管原生Kubernetes的NodeLifeCycle Controller,實(shí)現(xiàn)在云邊網(wǎng)絡(luò)異常時(shí),不驅(qū)逐自治邊緣節(jié)點(diǎn)的Pod應(yīng)用;還有YurtCSRController,用以審批邊緣節(jié)點(diǎn)的證書申請。

4.YurtAppManager(必選):實(shí)現(xiàn)對邊緣負(fù)載進(jìn)行單元化管理調(diào)度,包括NodePool:節(jié)點(diǎn)池管理;YurtAppSet:原UnitedDeployment,節(jié)點(diǎn)池維度的業(yè)務(wù)負(fù)載;YurtAppDaemon:節(jié)點(diǎn)池維度的Daemonset工作負(fù)載。以Deploymen工作負(fù)載部署在云中心。

5.NodeResourceManager(可選):邊緣節(jié)點(diǎn)本地存儲資源的管理組件,通過修改ConfigMap來動態(tài)配置宿主機(jī)本地資源。以DaemonSet工作負(fù)載部署在邊緣節(jié)點(diǎn)。

6.YurtEdgeXManager/YurtDeviceController(可選):通過云原生模式管控邊緣設(shè)備,當(dāng)前支持EdgeX Foundry的集成。YurtEdgeXManager以Deployment工作負(fù)載署在云中心,YurtDeviceController以YurtAppSet工作負(fù)載署部署在邊緣節(jié)點(diǎn),并且以節(jié)點(diǎn)池NodePool為單位部署一套YurtDeviceController即可。

7.運(yùn)維管理組件(可選):為了標(biāo)準(zhǔn)化集群管理,OpenYurt社區(qū)推出YurtCluster Operator組件,提供云原生聲名式Cluster API及配置,基于標(biāo)準(zhǔn)Kubernetes自動化部署及配置OpenYurt相關(guān)組件,實(shí)現(xiàn)OpenYurt集群的全生命周期。舊Yurtctl工具建議只在測試環(huán)境使用。

除了核心功能及可選的專業(yè)功能外,OpenYurt持續(xù)貫徹云邊一體化理念,將云原生豐富的生態(tài)能力最大程度推向邊緣,已經(jīng)實(shí)現(xiàn)了邊緣容器存儲,邊緣守護(hù)工作負(fù)載DaemonSet,邊緣網(wǎng)絡(luò)接入Ingress Controller等,還有規(guī)劃中的有Service Mesh,Kubeflow,Serverless等功能,拭目以待。

5當(dāng)前挑戰(zhàn)

2345截圖20211028093243.png

(1)云邊網(wǎng)絡(luò)

在邊緣計(jì)算場景中,被提到最多的就是云邊網(wǎng)絡(luò)差且不穩(wěn)定,其實(shí)國內(nèi)基礎(chǔ)網(wǎng)絡(luò)在2015年開始全面升級,尤其是在“雪亮工程”全面完成之后,基礎(chǔ)網(wǎng)絡(luò)有一個(gè)很大的提升。上圖摘自《第48次中國互聯(lián)網(wǎng)絡(luò)發(fā)展?fàn)顩r》報(bào)告,固網(wǎng)100Mbps接入占比已達(dá)91.5%;無線網(wǎng)絡(luò)接入已經(jīng)都是4G,5G的優(yōu)質(zhì)網(wǎng)絡(luò)。

而真正的挑戰(zhàn)在云邊網(wǎng)絡(luò)組網(wǎng),對于使用公有云的場景:公有云屏蔽數(shù)據(jù)中心網(wǎng)絡(luò),只提供了互聯(lián)網(wǎng)出口帶寬,通過互聯(lián)網(wǎng)打通云邊,通常只需要解決數(shù)據(jù)安全傳輸即可,接入不復(fù)雜。對于私有自建的IDC場景:打通云邊網(wǎng)絡(luò)并不容易,主要是運(yùn)營商網(wǎng)絡(luò)沒有完全產(chǎn)品化,同時(shí)私有IDC層層防火墻等其他復(fù)雜產(chǎn)品,需要專業(yè)的網(wǎng)絡(luò)人員才能完成實(shí)施工作。

(2)list-watch機(jī)制與云邊流量

2345截圖20211028093243.png

List-Watch機(jī)制是Kubernetes的設(shè)計(jì)精華,通過主動監(jiān)聽機(jī)制獲取相關(guān)的事件及數(shù)據(jù),從而保證所有組件松耦合相互獨(dú)立,邏輯上又渾然一體。List請求返回是全量的數(shù)據(jù),一旦Watch失敗,就需要重新Relist。但是Kubernetes有考慮管理數(shù)據(jù)同步優(yōu)化,節(jié)點(diǎn)的kubelet只監(jiān)聽本節(jié)點(diǎn)數(shù)據(jù),kube-proxy會監(jiān)聽所有的Service數(shù)據(jù),數(shù)據(jù)量相對可控;同時(shí)采用gRPC協(xié)議,文本報(bào)文數(shù)據(jù)相比業(yè)務(wù)數(shù)據(jù)非常小。上圖是在節(jié)點(diǎn)1200節(jié)點(diǎn)的集群規(guī)模,做的壓測數(shù)據(jù)監(jiān)控圖表。

真正的挑戰(zhàn)在基礎(chǔ)鏡像及應(yīng)用鏡像下發(fā),當(dāng)前的基礎(chǔ)鏡像及業(yè)務(wù)鏡像,即使在中心云,依然在探索各種技術(shù)來優(yōu)化鏡像快速分發(fā)的瓶頸;尤其是邊緣的AI應(yīng)用,一般都是由推送應(yīng)用+模型庫構(gòu)成,推算應(yīng)用的鏡像相對較小,模型庫的體積就非常,同時(shí)模型庫隨著自學(xué)習(xí)還需要頻繁的更新,如果更高效的更新模型庫,需要更多技術(shù)及方案來應(yīng)對。

(3)邊緣資源和算力

2345截圖20211028093243.png

邊緣的資源情況需要細(xì)分場景,針對運(yùn)營商網(wǎng)絡(luò)邊緣,面向消費(fèi)者的邊緣計(jì)算,資源相對比較充足,最大的挑戰(zhàn)是資源共享及隔離;針對實(shí)體產(chǎn)業(yè)的邊緣,都會有不小的IDC支持,邊緣資源非常充足,足以將整個(gè)云原生體系下沉;針對智能設(shè)備邊緣,資源相對比較稀缺,但一般都會通過一個(gè)智能邊緣盒子,一端連接設(shè)備,一端連接中心管控服務(wù),從上圖的AI邊緣盒子來看,整體配置提升速度較快,長期來看,邊緣的算力快速增強(qiáng)以此來滿足更復(fù)雜更智能化的場景需求。

(4)Kubelet比較重,運(yùn)行占用資源多

2345截圖20211028093243.png

對于Kubelet比較重,運(yùn)行占用資源多的問題,需要深入了解節(jié)點(diǎn)資源分配及使用情況,通常節(jié)點(diǎn)的資源自下而上分為四層:

1.運(yùn)行操作系統(tǒng)和系統(tǒng)守護(hù)進(jìn)程(如SSH、systemd等)所需的資源;

2.運(yùn)行Kubernetes代理所需的資源,如Kubelet、容器運(yùn)行時(shí)、節(jié)點(diǎn)問題檢測器等;

3.Pod可用的資源;

4.保留到驅(qū)逐閾值的資源。

2345截圖20211028093243.png

對于各層的資源分配設(shè)置的沒有標(biāo)準(zhǔn),需要根據(jù)集群的情況來權(quán)衡配置,Amazon Kubernetes對Kubelet資源配置算法是Reserved memory=255MiB+11MiB*MAX_POD_PER_INSTANCE;假設(shè)運(yùn)行32 Pods,高達(dá)90%的內(nèi)存都可以分配給業(yè)務(wù)使用,相對來說Kubelet資源占用并不高。

同時(shí)也要結(jié)合業(yè)務(wù)對高可用的要求,做響應(yīng)的調(diào)整。針對邊緣場景,一般不建議在一個(gè)節(jié)點(diǎn)上運(yùn)行大量的Pods穩(wěn)定為大。

四業(yè)務(wù)應(yīng)用的云邊管運(yùn)協(xié)同模型

2345截圖20211028093243.png

基于中心云的分布式業(yè)務(wù)應(yīng)用架構(gòu),與云邊分布式協(xié)同業(yè)務(wù)應(yīng)用架構(gòu)本質(zhì)上有很大差別。在中心云更多的是基于DDD業(yè)務(wù)領(lǐng)域,將復(fù)雜的業(yè)務(wù)系統(tǒng)拆分成一個(gè)個(gè)相對獨(dú)立的服務(wù),整體構(gòu)建一個(gè)松耦合的分布式應(yīng)用;但在云邊分布式場景下,更多強(qiáng)調(diào)的是集中式管控運(yùn)營,分散式運(yùn)作支撐,將管理運(yùn)營系統(tǒng)集中在云中心,實(shí)現(xiàn)中心式管控,將支撐業(yè)務(wù)實(shí)時(shí)運(yùn)作的應(yīng)用分散至邊緣,實(shí)現(xiàn)低延遲快速響應(yīng)。

從業(yè)務(wù)應(yīng)用來看,財(cái)務(wù)/經(jīng)營,計(jì)劃/管理兩層屬于管控運(yùn)營類的應(yīng)用,就是需要通過中心云統(tǒng)一匯聚,實(shí)現(xiàn)集中化強(qiáng)管控;對延遲不敏感,對安全,大數(shù)據(jù)分析能力等要求較高;控制,傳感/執(zhí)行,生產(chǎn)過程三層屬于運(yùn)作支撐類應(yīng)用,也可以優(yōu)先考慮中心云;如果業(yè)務(wù)場景對延遲敏感,才考慮通過邊緣計(jì)算能力,實(shí)現(xiàn)分散式低時(shí)延響應(yīng);

從請求響應(yīng)來看,對時(shí)延不敏感(50ms以上)都有限考慮部署在中心云計(jì)算及云化的邊緣產(chǎn)品(CDN)實(shí)現(xiàn);對延遲敏感(小于10ms),運(yùn)營商骨干網(wǎng)完全無法支持的,考慮建設(shè)邊緣計(jì)算平臺,同時(shí)業(yè)務(wù)面臨不小的投入及人員;

以實(shí)體物流領(lǐng)域?yàn)槔?,?jīng)典的OTW系統(tǒng)(OMS訂單管理系統(tǒng),WMS倉庫管理系統(tǒng),TMS運(yùn)輸管理系統(tǒng))其中OT就屬于典型的管理運(yùn)營系統(tǒng),所以建議部署在中心云,通過中心云數(shù)據(jù)匯聚,實(shí)現(xiàn)拼單拆單,多式聯(lián)運(yùn)等跨區(qū)域業(yè)務(wù);W是倉庫管理系統(tǒng),管理四面墻的任務(wù),屬于運(yùn)作支撐應(yīng)用,并且倉庫一般都有一些自動化設(shè)備,就可以考慮將W部署在邊緣。

五總結(jié)

邊緣計(jì)算平臺的建設(shè),以Kubernetes為核心的云原生技術(shù)體系,無疑是當(dāng)前最佳的選擇與建設(shè)路徑;但是云原生體系龐大,組件復(fù)雜,將體系下沉至邊緣會面臨很大的挑戰(zhàn)與困難,同時(shí)充滿巨大的機(jī)遇及想象空間。業(yè)務(wù)應(yīng)用想要真正踐行邊緣的云原生體系,需要從理念、系統(tǒng)設(shè)計(jì)、架構(gòu)設(shè)計(jì)等多方面來共同實(shí)現(xiàn),才能充分發(fā)揮邊緣的優(yōu)勢及價(jià)值。

THEEND

最新評論(評論僅代表用戶觀點(diǎn))

更多
暫無評論