“新基建”正在成為中國拉動經濟增長的新方式。近日，國家發改委提出將聯合相關部門，深化研究、強化統籌，研究出臺推動新型基礎設施發展的有關指導意見。在“新基建”大潮下，邊緣計算將展露出巨大的價值。
5G作為“新基建”的核心，讓雲遊戲、超高清視頻直播、VR/AR、V2X、智慧城市/製造等新興行業蓬勃發展，但隨之而來的是海量計算數據。傳統的雲計算架構已無法滿足此類“低延遲&大帶寬”的需求，雲+邊+端三位一體的分佈式計算架構成為更好的解決方案。
這樣的背景下，百度智能雲率先基於CDN節點網絡推出邊緣計算產品BEC(Baidu Edge Computing)，一站式提供更靠近終端用戶的、全面覆蓋的、彈性分佈式算力資源，通過終端數據就近計算和處理，大幅度優化響應時延、降低中心負荷和整體成本;同時賦予用戶更快、更省、更靈活、更高效的邊緣算力資源和平臺能力。
支撐新場景落地
在百度智能雲的邊緣計算產品BEC中，邊緣計算節點不僅提供了用戶邊緣算力資源，更把中心雲的核心能力下沉到了邊緣節點，如存儲、網絡、安全等能力，完成了眾多新興場景的落地，同時打造了雲邊協同的最佳解決方案：
在直播/點播場景，通過使用就近基於邊緣構建的分佈式源站，大幅度節省中心帶寬成本，降低用戶觀看延遲、提升體驗。同時支持客戶將自有協議及轉碼能力快速部署至邊緣節點，降低改造成本。
在視頻上傳場景，邊緣節點提供就近落盤存儲。視頻文件上傳速度提升50%，同時因減少傳輸鏈路使得上傳成功率提高至99%以上。也可引入多個節點存儲集群，保證邊緣環境存儲功能的可靠性。
在安防場景，邊緣計算節點可提供就近視頻匯聚及處理能力，在同一城域網的距離內解決視頻流/圖片的合流、存儲、分析，提供低成本、高質量的智慧安防監控能力。對終端設備無特殊要求，擴展性強、易改造，由邊緣來做統一納管，大幅度降低運營成本。
在雲遊戲場景，邊緣計算節點可提供高實時性的GPU計算資源，完成遊戲場景的渲染工作。在特定區域內，從用戶遊戲指令上傳至邊緣節點處理到視頻渲染後下發，整體可在25ms內完成處理。支持遊戲即開即玩，無需下載，大幅度提升拉新率。同時也不會因遊戲更新虛用戶重新下載，導致用戶流失。
為支撐以上眾多場景落地，BEC在產品功能和技術架構方面，做了非常多的創新嘗試，同時也在實際業務使用中，一一驗證了技術的先進性，以下是創新的重點方向。
安全容器和標準虛機的混部調度
近年來，容器技術快速發展，並呈現出與Kubernetes融合的趨勢。
2019年Kubernetes社區的一份指南綱要中，討論了虛擬機迴歸的話題，而在生產實踐中也發現，以docker為代表的runc容器技術，在安全性、隔離性上有不少隱患。這使得微虛機或者安全容器技術逐漸被業界重視起來，比較有代表性的如Kata Containers，Firecracker和gVisor。
BEC就使用了其中的Kata Container安全容器做為邊緣容器方案，實現容器內核隔離，保證非受信工作負載的運行，為客戶提供更高的安全性。但是Kata Container也有一定的侷限性，比如容器內核版本比較高，內核版本、虛機鏡像不支持容器粒度的動態配置等問題。此外，也可支持客戶在標準虛機上的使用習慣上。
在這個背景下，BEC開啟了對邊緣虛機的支持。這也和業界的發展趨勢相同，隨著像Kubevirt這樣的開源項目興起，Kubernetes強大的編排能力可以直接管理標準虛擬機。而且BEC實現了安全容器和標準虛機的混部調度，整體架構如下：
簡明邊緣虛機架構
邊緣虛機使用了開源的kubevirt方案來實現，通過Kubernetes的自定義資源API(CRD)，增加虛機和虛機實例資源，使Kubernetes能夠方便地編排管理虛機對象。Kubevirt的整體架構如下：
可自定義虛機鏡像
BEC通過與百度智能雲BCC雲服務器產品打通，充分利用中心雲產品能力，為用戶提供自定義虛機鏡像的能力。用戶在BEC上啟動邊緣虛機時，可以選擇在BCC中製作的虛機鏡像啟動。
Kubevirt支持多種存儲掛載方式，在BEC中，系統盤的掛載使用的是dataVolume的方式，結合CDI(
Containerized-Data-Importer)工具，完成虛機系統盤的準備。如下圖：
支持虛機資源整體調度
BEC為了提升性能，邊緣使用本地盤作為虛機的系統盤，在系統盤pv準備完成後，importer Pod會被刪除，BEC通過設置vm pod的親和性，保證vm pod會調度到pv所在的節點。但是importer pod刪除和vm pod創建過程中可能會有新的pod調度到此節點，並佔用資源，會導致vm pod因資源不足而調度失敗。
為了解決這個問題，BEC增加了對虛機生命週期過程中所有資源的整體調度能力。重點是保障importer刪除後，vm pod可以保證在同節點啟動，另外一個是保障虛機關機開機時pod能在同節點重建。
BEC對kube-scheduler組件進行了改造，在原有的節點資源管理模塊增加了資源預留機制，為vm的pod預留出資源配額，不參與調度。對應上面提到的importer pod刪除或者因vm關機導致的virt-launcher pod刪除，對應的資源不會從scheduler的資源緩存中清理，並且通過hook資源同步邏輯，防止緩存被更新，從而保證了vm啟動的穩定性。
讓邊緣業務日誌處理更簡單
在業務運維中，日誌是觀察業務運行狀態，排查業務問題的重要依據。在邊緣服務場景中也是如此，但是邊緣側缺少中心雲中完備的平臺化日誌服務。為了解決這個問題，BEC結合雲原生生態，實現了一套業務容器日誌推送和監控指標採集的工具。
該工具以sidecar容器的形式與業務容器共同運行在同一pod中，支持通過emptydir的方式與業務容器實現日誌共享，也支持採集業務容器的標準輸出。控制面通過configmap實現配置熱更新下發，整體架構如下：
日誌指標提取 提升可讀性
日誌指標提取使用的是grok-exporter，grok-exporter是個輕量級的指標提取項目，可以很好對接prometheus。但是成熟度上還有待提升，主要問題有以下幾點：
一是原生grok-exporter只能支持從一個文件或一個目錄下的日誌中提取指標，在生產環境中，客戶多個容器的日誌存儲路徑可能是不一致的，為此，BEC對grok-exporter進行了改造，使其支持從多個文件或目錄提取指標，並將文件名添加為label用於區分。
二是原生grok-exporter不支持日誌文件路徑包含軟鏈接或者環境變量，而生成環境中，很多日誌文件，特別是標準輸出日誌，都是以軟鏈接的方式來實現日誌輪轉，BEC團隊對此進行了改造，解決了該問題。
三是提取指標時，對日誌的偏移量沒有做記錄，在進程重啟後會從文件開始處再次提取。為此，BEC對該偏移量進行了持久化存儲，進程重啟後可以重新加載，繼續從上一位置開始提取。而且BEC使用“inode+設備號+文件擴展屬性”唯一標識一個文件，保證文件刪除後，新建的同名文件可以被識別。
此外，之前grok-exporter自身的日誌格式不夠友好，在組件運維過程中成本較高。為此，BEC更換了日誌庫，對優化日誌格式，提升日誌可讀性。以配置化方式支持日誌輪轉，方便日誌清理，防止sidecar容器中的日誌堆積佔用過多資源。
多種日誌輸出
BEC在日誌傳輸上使用了開源的fluent bit，對接了百度智能雲ElasticSearch，除此之外，fluent bit原生還支持kafka、fluentd、http、nats等輸出。
基於以上眾多業界首發的功能和先進技術，百度智能雲以邊緣計算開闢全新賽道，完成率先搶跑，充分迎接5G新時代。同時，百度智能雲也在和運營商共同探索移動邊緣計算，旨在提供用戶更下沉的邊緣資源，更低延遲的網絡響應，更豐富的5G網絡能力，面向未來無限可能。
