“邊緣雲原生”是雲原生社群最近幾年一個新的發展方向。它試圖将邊緣計算的應用場景也納入到現有雲原生技術體系中。這篇文章将讨論為什麼會出現“邊緣雲原生”這樣的技術方案，邊緣計算的場景會給傳統雲原生技術帶來哪些挑戰，以及現在的邊緣雲原生方案是如何應對這些挑戰的。 以下都是紙上談兵的一家之言，贻笑大方還請各位批評指教。
“雲原生”時代的到來
網際網路行業向來有喜歡造詞的傳統。隻要你在這個圈子裡，各式各樣的buzz word總會不斷跳入你的視線裡。而近年來湧現出的一批新詞，包括：容器化，微服務，持續內建持續傳遞，DevOps, Service Mesh等等這些其實都可以統一到“雲原生”這一大架構中來。在介紹什麼是雲原生之前，我想先聊聊軟體設計結構的演進過程。
傳統的軟體開發基本上都是以單體應用的形态出現的。所謂單體應用，顧名思義就是把所有的業務邏輯都塞到一個大的應用中去。就像我們在學校裡做過的課程項目，我們會有一個龐大的後端，也許會用上SpringBoot這樣的架構，遵循MVC範式來進行開發。當然這個應用也會有子產品設計與業務拆分，但是這些子產品基本上都是強耦合在一起而不能獨立存在的。單體式應用的優勢在于結構簡潔，易于開發，因為各個子產品都在同一個應用之中，可以直接互動。但是随着網際網路需求的爆發，單體應用的代碼庫會越來越臃腫，難以維護，擴充性差。
當部署在單台機器上的單體應用難以承載日益增長的使用者通路需求時，我們需要将這個龐大的系統進行拆分，将其分割成不同的業務子產品，部署到多台的機器上，各個子產品通過事先約定的接口進行網絡通信（比如RPC）。這也就是所謂的分布式架構。也許我們還可以更進一步，考慮使用分布式資料庫（比如TiDB）代替傳統的資料庫來滿足擴充性的需求。當然在這樣一個分布式系統中，通常我們還需要通過一個反向代理伺服器Nginx代理轉發使用者請求，完成負載均衡的任務。分布式架構提升了整個系統的負載能力，解決了高并發的需求，但是也同時帶來了一系列的問題。首先，分布式本身的複雜性增加了開發和運維的成本，比如這樣一個系統我們需要考慮系統可靠性，一緻性等問題。另外，用網絡請求代替本地函數調用讓子產品間的通信成本上升。
Docker為代表的容器技術誕生，将實體機器級别的分布式提升到容器級别的分布式水準。容器技術廣受推崇因為它解決了實體級别分布式的許多潛在問題。比如，如果我們将多個子產品（或叫服務）部署到一台機器上，這些服務都将會以一個個程序的形式共享這一台機器的資源。那首先會存在程序間資源競争的問題，假如某個服務的程序占用大量機器資源，不可避免地影響其他程序的運作，進而拖累整個系統的表現。其次，多個服務的程序可能還會帶來潛在的安全問題。容器技術讓各個服務運作在抽象的容器中，共享同一台實體機的資源的同時互相隔離，互不幹擾。而且相比于傳統的虛拟機技術它性能損失小，啟動快。微服務架構把一組服務以容器的形式部署到一個叢集中。
微服務架構催生出了管理一個叢集中大量容器的需求。2014年釋出的Kubernets（也叫K8s）在這個領域脫穎而出，已經形成了一個繁榮的社群生态。它能幫助監控容器運作狀态自動重新開機，管理容器間的網絡通信進行網絡代理，自動伸縮動态排程資源。K8s這種聲明式配置和自動化管理，減輕了微服務帶來的運維壓力。
如果我們從一個整體的視角看待整個架構變遷發展的過程，可以看到一個明顯的趨勢是，應用與“雲”的結合越來越緊密。從傳統的與“雲”完全無關的單體應用，到把使用雲上的基礎設施（比如把應用部署到雲伺服器），到使用雲上的服務（比如使用雲資料庫），到整個基于雲開發的微服務架構。這實際上就是“雲原生”概念提出的時代背景。
雲原生是指從雲的原生應用角度出發，一整套設計、開發、部署、運作、維護的流程、技術棧以及背後文化理念的統稱。
雲原生希望建立一套圍繞着雲進行軟體開發的标準化、系統化的流程方案。雲原生應用天然具備彈性擴充，快速疊代傳遞，開發成本低等優勢，另外雲帶來的運維成本正在被雲原生社群活躍的新架構新方案（如
Service Mesh）逐漸解決。在雲原生的願景中，開發與運維将會完全解耦，最終開發者隻需要關注業務開發而不是把開發和運維攪在一起。
雲原生 + 邊緣計算 = 邊緣雲原生
邊緣計算一定程度上是一個與雲計算相對的概念，它指的是一些需要發生在網絡邊緣的計算場景。計算發生在邊緣可能有多方考量，比如有些涉及圖像視訊處理的場景可能囿于網絡帶寬成本希望在網絡邊緣裝置上處理，比如自動駕駛中一些需要及時得到結果的計算一定要在本地完成，再比如一些涉及隐私的資料（人臉，人聲）使用者希望不要上傳到雲端。總之，随着萬物互聯時代的到來，邊緣計算的需求将會越來越強烈。
這裡有一個虛構的簡單邊緣計算案例。比如我們有一個人臉識别的邊緣計算需求，我們希望借助資料中心的算力來訓練一個人臉識别的AI模型，同時将訓練好的模型部署到邊緣裝置上完成及時的預測。整個流程可能要經曆這樣四個階段，首先在雲端訓練好模型，然後把模型分發部署到邊緣節點，之後邊緣節點用這個模型來進行預測并且把預測結果上報回雲端，接着雲端利用這些資料再進行模型疊代。至此構成了一個應用閉環。
從這樣一個簡單的案例，我們能看出在如今雲時代下邊緣計算的一些特點。
- 雲-邊雙向通信。雲計算與邊緣計算不是割裂的而是需要有互動的，邊緣是雲的延伸。在我們例子中，雲需要向邊緣分發部署模型，邊緣需要向雲上報模型預測結果。即使計算資源和裝置可能在邊緣，但是我們希望這些資源的注冊上報是由雲端來統一管理的，另外計算應用也是由雲端統一部署的。
- 雲-邊松耦合。即邊緣節點需要不依賴于雲端（甚至在斷網環境）可靠地完成本地任務，也就是所謂的邊緣自治。另外，可能還需要邊緣節點之間能夠不通過雲端，局部互相感覺通信。
- 邊緣計算自身的一些特性。裝置分散海量，網絡條件複雜，計算資源有限，裝置異構。
讓我們從雲原生的視角審視上述邊緣計算的特點，其實很多問題是現有雲原生技術已經解決的問題。比如大量裝置的統一傳遞，運維，部署，隻不過之前的節點還在雲上，現在需要部署到網絡邊緣。再比如我們仍然可以借助輕量化的容器化技術管理大量的異構計算資源。再加上，雲原生社群本身的繁榮和統一的标準，K8s也适合用于擴充和二次開發。是以借助雲原生現有技術，解決邊緣計算場景問題，實作“雲-邊一體化”的邊緣雲原生，也就理所當然成為了下一個熱點問題。
邊緣雲原生面臨的問題
雖然雲原生技術自身的優勢使其已經能夠解決邊緣計算場景裡的一些問題，但是直接将雲上的技術下放到邊緣還是難免有些水土不服。接下來我們看看邊緣雲原生會遇到哪些問題？
在介紹這些問題之前，首先我們要對雲原生社群中的核心技術——K8s有一定的了解。K8s被稱為雲時代的作業系統，它已經成為雲原生領域事實上的标準。與其說它是一個管理容器的工具，它更像是一個可定制可拓展的平台，已經形成了繁榮的生态。很多邊緣雲原生技術方案都是基于K8s進行二次開發完成的。我們這裡簡單的介紹一下K8s的功能和特點。
K8s使用Master-Slave架構來管理叢集。
Master：
- etcd: 叢集資訊資料庫，以key-value形式持久化儲存叢集所有資料資訊。
- API Server：Kubernetes與外界互動的門戶，同時也是Node節點與Master節點互動的門戶。它将K8s所有的功能以REST API的形式暴露出來。為了防止請求壓力過載，一個叢集中可以部署多個API Server執行個體。
- Scheduller: 根據軟硬體環境，排程叢集節點上的容器資源。
- Controller: 監控節點狀态，管理節點任務。
Node：
- Network Proxy: 代理節點的網絡通信。
- Kubelet： 管理節點上所有K8s叢集中的容器。
- Container Runtime：嚴格來說不屬于K8s，但是K8s需要Node上有一個符合K8s CRI接口标準的容器運作時來運作容器。
通過這些元件，K8s可以管理容器叢集的工作負載和服務。但是由于它最初是為部署在資料中心的叢集設計的，而這種對叢集運作環境的假定和預設不适合邊緣計算的環境。也就是說如果我們直接把K8s擴充到邊緣計算場景中，會遇到一些問題，這展現在以下幾個方面：
- 邊緣離線自治能力的缺失。如果我們直接把Node部署到邊緣，那麼在一些場景中，Node節點失去與Master的聯系後不能正常工作。
- 邊緣網絡環境的不确定性。資料中心中的網絡一般都是穩定連通的，但是邊緣計算場景中網絡環境可能較為複雜。比如K8s中的List-Watch異步消息處理機制，這種全量擷取，增量更新的方式在網絡頻繁斷接的情況下會帶來較大的網絡負載壓力。
- 邊緣計算資源的有限性。在一些特殊場景中，很難保證邊緣節點上的資源可以同時滿足K8s Node各個元件以及計算應用的需求。
一個邊緣雲原生解決方案執行個體
針對這些問題，現有的基于K8s的邊緣雲原生解決方案都給出了各自的解法。比如輕量化K8s使可以将叢集獨立部署在邊緣的K3S，對Kubelet進行精簡改造的KubeEdge，主打“非侵入式雲邊一體化”的OpenYurt。
下面以騰訊開源的SuperEdge為例介紹一下它如何應對這些問題。
SuperEdge是一個騰訊開源的邊緣雲原生解決方案。它和OpenYurt一樣基于K8s現有功能以一種無侵入式的方式進行二次開發（直接以go mod形式引入K8s），可以說是一個标準的K8s“套殼”應用。這樣帶來的優勢是減輕了後續與K8s同步更新的維護壓力。它在K8s的基礎上擴充出了下面👇幾個功能：
- 邊緣自治，使邊緣節點不依賴于與Master的聯系，可以自主運作。
- 複雜網絡下的雲邊協同，即使邊緣節點部署在區域網路内沒有公網IP，也能實作雲邊雙向通信
- 邊緣節點分布式健康檢查，邊緣節點的狀态不僅由其與Master的連接配接确定，而且由與其一組的邊緣節點組内連接配接共同确定。
- Service Group服務級别的控制粒度
大體來說，SuperEdge通過在邊緣側添加一層代理服務來緩存請求的方式讓Node端在斷網情況下也可以正常運作。另外，它使用gRPC中bidirectional streaming解決了邊緣測無公網IP情況下的雙向通信問題。而且通過邊緣測分布式健康檢查可以保證在弱網條件下workload的正常運作。ServiceGroup可以便捷地在共屬同一個叢集的不同機房或區域中各自部署一組服務，并且使得各個服務間的請求在本機房或本地域内部即可完成，避免服務跨地域通路。
總結
- “雲原生” 正在成為IT領域的新範式，它對軟體行業的影響将展現在從軟體開發流程到軟體體系架構設計等方方面面。
- 邊緣計算場景對傳統“雲原生”技術提出了新的要求，比如雲邊協同，邊緣自治，複雜網絡環境下通信等。
- KubeEdge, OpenYurt, SuperEdge等一批基于k8s的雲原生社群開源解決方案，擴充了傳統“雲原生”的能力，使其能夠服務邊緣計算場景。