- 多接入邊緣計算實戰
- (意)達里奧·薩貝拉 (美)亞歷克斯·列茲尼克 (德)魯伊·弗拉贊
- 2028字
- 2021-12-01 13:48:35
1.3 MEC的邊緣部分
邊緣計算之所以現在成為云計算和電信領域的熱門話題,不是因為它是一項熱門的新技術,而是有很多重要的原因。邊緣計算的起源至少可以追溯到2000~2005年開發的邊緣內容分發網絡(CDN)。可以從CloudFlare網站(www.cloudflare.com/learning/cdn/glossary/edge-server/)上找到一個很好的簡短摘要:
邊緣服務器是一種提供網絡入口點的邊緣設備。其他邊緣設備包括路由器和路由式交換機。邊緣設備通常放置在互聯網交換點(IxP)內,以允許不同的網絡來連接和共享傳輸。
CloudFlare網站上還有一個很好的圖示,如圖1.1所示。

圖1.1 邊緣CDN圖示(來自CloudFlare)
這里我們要做一個重要的觀察。CloudFlare定義的邊緣CDN服務器實際上位于用戶與通信服務提供商(CSP)網絡(互聯網服務提供商(ISP)是CSP的一種特殊情況)的最遠點。在某種程度上,這是由一個簡單的必然情況決定的——邊緣CDN提供商(如CloudFlare和Akamai)根本無法將它們的設備離用戶更近,因為這意味著要離開互聯網,將它們的設備放在CSP的專有網絡中。
這導致了一個自然的下一步,即開發盡可能靠近用戶的CSP所有的“邊緣CDN”。
在移動網絡的情況下,這意味著將其定位在無線接入網(RAN)上,或者更確切地說,將RAN連接到核心網絡的“S1”接口上。不幸的是,這樣做需要截獲正常的流量,在5G之前的移動核心網絡中,這些流量是在RAN(例如基站)和分組網關(PGW)之間進行隧道傳輸的。PGW位于移動網絡最遠的邊緣,即“正常”邊緣CDN所在的位置[1]。圖1.2顯示了這種情況,即4G核心網絡(稱為“演進的分組核心”(ePC))的高度簡化圖。ePC接口有標簽,但其中的S1接口(注意:有兩個!)和SGi接口將非常重要,它們將多次出現在本書的多個討論點上,如關于“S1上的MEC”和“SGi上的MEC”實現選項部分。S1-U接口(用于S1用戶面)將RAN連接到服務網關(SGW)并承載用戶流量,而S1-MME接口將RAN連接到移動性管理實體(MME)并承載控制最終用戶設備訪問RAN的各個方面的流量。S1接口應該被視為“控制面”。SGi接口是3GPP給予進出ePC的“普通IP流量”接口的“架構參考”。雖然邊緣CDN可以放置在ePC中的其他邏輯位置(例如:S5上,SGW中),但一般來說,假設你要進入移動網絡,會希望其位于RAN中,也就是在S1接口上。

圖1.2 高度簡化的4G核心網絡顯示了邊緣CDN的位置
在S1上有一個“邊緣CDN”節點以及提供其他服務的可能性的需求,導致了標準定義架構(LIPA)和“透明的”本地突破方法的開發,S1上的通道被打破。在2005年左右,這兩種方法都是被積極開發和產品化的主題,并且預計MEC將被用于比“邊緣數據緩存”更廣泛的應用中。有關與邊緣緩存完全不同的示例,以及如何在“S1上”定位處理的較完善討論,請參見參考文獻[3]。這里需要注意的是,在目前由3GPP定義的5G架構中,通過一個正確定位的用戶面功能(UPF),在RAN旁邊的應用程序功能的放置將以本地方式支持。我們將在后面更詳細地討論這個問題。
然而,回到傳統的邊緣CDN,我們注意到它在CSP網絡的遠端位置是由另一個附加因素決定的——這些實體的工作方式。至少在一定程度上,它們使用復雜的算法來分析用戶數量統計和內容請求統計,并試圖預測哪些內容可能會被哪些用戶群請求。只有當用戶和內容總體統計數據足夠大,并且“邊緣”站點的存儲也足以容納大量內容時,這才有效。將邊緣CDN移近用戶還會減少在任意給定時間服務的用戶群體的數量大小(也就是統計樣本),以及通過緩存點的內容量(同樣是統計樣本)。這可以通過增加緩存的大小來抵消。不幸的是,轉向邊緣的經濟性決定了恰恰相反的情況——必須減少存儲量。因此,傳統的邊緣緩存方法不會比CSP網絡的邊緣更有效。
解決這一問題的方法是充分利用處于最邊緣的豐富環境。例如:為咖啡店提供服務的一個非常小的小區是高度情景化的,它的用戶群很可能喜歡咖啡,并且有一個與該咖啡店相關聯的特定配置文件。如果該內容可以公開給應用,應用就會知道如何去處理它。如果它隨后在小區中為其內容提供一個著陸區(landing zone),那么它很可能會非常明確該如何處理這些存儲。這個想法得到了小蜂窩(Small Cells)社區的認可,小蜂窩論壇(Small Cells Forum)在這個領域的工作記錄可參見參考文獻[4-7]。然而,它的實現還需要等待邊緣計算的實現。畢竟,一旦為應用提供了內容的著陸區,下一步自然就是為應用的計算建立一個著陸區,至少對于一些可能在邊緣運行的組件來說是這樣。
顯然,在邊緣做點什么的想法既不新鮮,也沒有某些技術的支持,但這仍然留下了一些開放性的問題:什么是邊緣?邊緣在哪里?邊緣和傳統云的邊界在哪里?現在讓我們發表以下大膽的聲明。讀者可能會被問到一個更難回答的問題:在“邊緣計算”的背景下,什么是“邊緣”呢?舉一些好例子很容易。此外,如果你深深地沉浸在你自己的領域,你可能會認為你的例子才是實際上的邊緣。但是,當你和一個在相關領域工作的熟人交談時,你會驚訝地發現,他們的“邊緣”與你的不同,事實上很難界定“深層”云的終點和“邊緣”的起點。然而,這正是我們需要做的事情——否則,本書的其余部分就沒有意義了。除非我們與讀者對本書的內容有一些共同的理解,否則我們不可能寫出一本對廣大讀者有用的書(或是一篇文章)。
[1]參見參考文獻[1-2],了解4G網絡的優秀背景。
- 國際大學生程序設計競賽中山大學內部選拔真題解(二)
- Testing with JUnit
- Python Tools for Visual Studio
- 深入理解Java7:核心技術與最佳實踐
- Banana Pi Cookbook
- Building Mapping Applications with QGIS
- Building Minecraft Server Modifications
- 焊接機器人系統操作、編程與維護
- JBoss:Developer's Guide
- 超簡單:用Python讓Excel飛起來(實戰150例)
- Qt 5.12實戰
- Kohana 3.0 Beginner's Guide
- Java Script從入門到精通(第5版)
- Mastering Unity Scripting
- JavaWeb入門經典