邊緣計算面臨的一個艱鉅挑戰是如何處理這樣的情況：在不同地理位置的數千個集羣上運行的千兆字節數據。這種描述讓你想到擁有物聯網傳感器數據的大型工業用例，但它們並不是唯一重要的優勢所在。
邊緣計算在很多行業中變得非常重要。銀行在用它，在線服務供應商需要它，而健康供應商、電信、公用事業和汽車製造商則使用它。這篇文章介紹了激發邊緣計算的需求，這樣讀者就可以決定邊緣設計是否對他們有用。它還分析了邊緣的挑戰--包括經常被忽視的挑戰--並提供了一些在現實世界中行之有效的解決方案。
爲什麼要使用邊緣計算？
邊緣計算是一種很有吸引力的（通常甚至是必需的）體系結構選擇，由於有限的容許時延、網絡故障的潛在風險和法規要求，或者僅僅是對邊緣產生的不能划算地將其傳輸到中心站點的數據規模做出反應等原因，邊緣計算便可以在數據源附近進行計算。
邊緣計算的廣泛採用是由於以下幾個因素：
● 由於傳感器成本的降低和多樣性的增加，它比以往任何時候都更容易獲取數據。今天生產的幾乎所有產品都內置了更多的傳感器和數據通信功能。
● 網絡基礎設施使得將比特移到邊緣的變得更便宜。
● 由於Kubernetes的進步，在覈心和邊緣集羣中管理分佈式計算變得越來越容易。
● 加固的硬件可以進行必要的數據過濾和預處理，即使在可能發生在邊緣的惡劣條件下也能保持運行。
令人驚訝的是，邊緣計算的最大挑戰之一不是計算部分。邊緣與核心之間的通信幾乎是一種普遍的需求。指標和診斷數據需要移回核心計算中心，在某些情況下，數據或模型需要移動到邊緣。
架構師和實施者通常假設與核心的通信是很容易處理的，然而事實的情況往往並非如此。
邊緣的工作原理是什麼?與核心的溝通
下面的實際用例說明了如何解決邊緣計算中的挑戰，包括與核心的通信。幾年前，我們有一個客戶，他開發了一個視頻流系統。需要邊緣計算，以便提供視頻內容的系統接近最終用戶，以最小化延遲和最大化正常運行時間。我們的客戶所構建的系統運行良好，但是他們在構建遙測系統時遇到了麻煩，無法將系統健康狀況和客戶視頻消費的數據傳送回核心——這是在出現問題時向核心支持團隊發出警報並進行計費所必需的數據。
這個特殊的問題非常具體，但是問題的形式——邊緣計算加上從邊緣到核心的遙測——對於許多其他行業來說是普遍的。在這個例子中，和通常一樣，遙測技術被推遲到項目的末尾;困難被大大低估了。這就是我們的切入點。
我們所做的
爲了解決將數據返回核心的典型邊緣問題，我們添加了一個分佈式數據結構，並使用其消息傳輸功能創建了一個簡單可靠的解決方案。
我們的目標是支持從幾十個小型邊緣數據中心獲取數據，並以合理的低延遲將得到的數據可靠地傳輸到核心數據中心進行分析和計費。臨時網絡分區不應影響數據完整性，並且數據應在這些分區被修復後立即傳輸。該系統還需要儘量減少物理故障造成的停機時間。下圖說明了如何使用數據結構來滿足這些需求。
上圖所示，數據結構的使用將邊緣與核心連接起來，而不需要在任何一邊使用複雜的系統。虛線塊表示數據中心——包括邊緣和核心——並提醒我們數據結構跨越了整個體系結構。深色虛線箭頭顯示了通過數據結構的消息傳輸系統(水平圓柱體)從多個邊緣位置返回到總部的度量數據流。
在此之前，我們客戶的開發人員曾嘗試過幾種遙測技術的實現，但都沒有成功，結果大大落後於計劃進度。相比之下，我們基於數據組的設計的傳輸程序能夠非常簡單地將消息插入到邊緣的消息流中。然後數據結構處理從邊緣到核心的所有數據傳輸。消息流中的主題記錄了數據中心名、源機器名、傳感器名或事件類型，因此來自所有邊緣中心的所有數據都可以合併到單個消息流中，同時仍然允許對數據的任何子集進行分析。數據結構處理靜態和動態數據的安全性。
這個設計非常容易實現和操作，並且能很快地使客戶的開發人員按計劃行事。這種設計在數年內也是非常可靠的。這種最終數據結構設計的一個特別好處是高度的關注點分離。例如，邊緣數據採集獨立於處理數據的中央程序。數據結構的地理位置完全由管理員指定，管理員現在可以專注於配置數據運動和訪問控制，而不關心數據內容。這種關注點的分離意味着在覈心和邊緣運行的程序可以簡單得多，只關注單個問題。這一優勢適用於廣泛的用例。
我們今天會做什麼不同的事情(或不做)？
如果我們今天要設計這個邊緣解決方案，我們仍將使用數據結構來傳輸數據----保留數據結構的優點來處理數據安全、數據移動、複製和高可用性容錯等所有方面。但今天，通過使用Kubernetes進行容器編排，我們還將從中央軟件的完全雲本機實現中受益匪淺。五年前，與Kubernetes現在的位置相比，容器編排還相當原始。
具有適當功能的數據結構爲在Kubernetes下運行的容器化應用程序提供數據訪問和狀態持久性。
補充Kubernetes在編排計算中的角色的數據持久層對於獲得雲原生計算的全部功能至關重要。數據將比處理它的容器壽命長。
然而，在邊緣集羣上，我們可能不會有什麼改變——至少今天不會。然而，明天可能會是另一番景象。
剩下的挑戰：會發生什麼？
我們正處於邊緣容器編排的關鍵時期，這一編排非常有用。這使得現在成爲邊緣計算的一個輝煌時刻。有了真正的邊緣編排，就可以在邊緣系統上執行比我們在原始設計中能夠證明的更高級的處理，並使邊緣羣集的提供變得更容易。
邊緣作爲目的地
這個用例突出了數據進入核心的常見邊緣問題。但是數據向邊緣的出口呢?我們需要向邊緣部署人工智能/機器學習模型，向邊緣推送狀態信息或報告數據，或更新運行在邊緣的軟件。數據結構可以使所有這些都變得非常簡單，同時還可以最小化通過開放互聯網訪問存儲庫所帶來的安全風險。
讓數據雙向移動使我們能夠真正“在本地行動，但在全球學習”。
安全情況是怎樣的呢?
邊緣系統的安全性至關重要，因爲它們面臨着巨大的威脅。至少，不可能形成新的邊緣集羣，不可能模擬現有的集羣，也不可能竊聽從邊緣移動到核心的數據。理想情況下，這種安全級別是基於某種信任的硅根，這種信任一直延伸到最低的硬件級別。它還應該向上擴展，以便在執行之前對所有OS和容器映像進行驗證，並且數據在靜止或傳輸時受到保護，而不需要對應用程序進行任何專門設計。
在安全硬件平臺上運行的安全容器執行框架以及默認安全數據結構可以滿足這些需求。但是，任何低於這一點的東西都可能會大大降低安全性。
關鍵的問題
● 比許多人想象的要多的行業需要邊緣計算。
● 邊緣計算不僅僅是在邊緣計算或運行模型；將指標和操作數據拉回到核心是一個幾乎無處不在且通常被忽略的需求。
● 一個從邊緣到核心的統一數據結構可以處理數據在邊緣之間可靠移動的問題。
● Kubernetes已經爲核心的容器化計算提供了巨大的好處，在邊緣使用Kubernetes的能力正在迅速成熟。
作者：Ted Dunning
Ted是HPE旗下MapR的首席技術官，他擁有着博士學位，是計算機科學專業的作者，著有超過10本專注數據科學的書。他在高級計算領域擁有25項專利。
原文鏈接：
https://thenewstack.io/using-data-fabric-and-kubernetes-in-edge-computing/
翻譯&編輯：秦天鈺
感謝閱讀，歡迎擴散傳播！感謝！
邊緣計算社區：促進邊緣計算領域知識傳播，中立，客觀，如果您關注邊緣計算、5G、物聯網、雲原生等領域請關注我們。
