近日，火山引擎邊緣雲原生團隊的同學在QCon全球軟體開發大會上分享了火山引擎容器技術在邊緣計算場景下的應用實踐與探索，并在一衆AIGC、LLM等當下熱門議題中脫穎而出，入選觀衆滿意度投票中“叫好又叫座議題Top5”。
以下是演講全文：
大家上午好！
我是來自火山引擎邊緣雲原生團隊的李志明。今天給大家分享的議題是關于容器技術在邊緣計算場景怎麼去落地，以及我們在哪些場景下做了實踐。
首先做一下自我介紹。我自己一直在CDN和邊緣計算行業從事技術研發和架構設計工作，個人比較擅長像比如Kubernetes、服務網格、容器網絡相關的雲原生技術，對于高性能的Nginx和高性能緩存伺服器也比較了解，目前主要是負責火山引擎邊緣容器平台，以及邊緣容器執行個體産品的研發落地。
今天我的分享議題主要從四個方面。第一個給大家介紹什麼是邊緣計算和邊緣容器。然後就是給大家講一下在邊緣計算場景下，我們落地邊緣容器這樣的雲原生技術，面臨着什麼樣的技術挑戰，然後我們在技術方案上是怎麼去解決的。接下來也給大家分享一下我們邊緣容器技術在哪些内外部場景進行了落地，打造了什麼樣的産品技術能力。最後給大家分享我們後續在雲原生相關領域會做哪些探索。
01 邊緣計算和邊緣容器
邊緣計算主要就是在靠近客戶的終端放一些邊緣計算的算力資源，主要是給一些應用開發和服務商提供IaaS的計算存儲網絡的資源，降低客戶的延時，降低客戶的帶寬。簡單了解，相對于中心雲的産品，邊緣計算主要廣泛分布在二、三、四線城市，它從資源分布上肯定是比中心雲分布得更廣，更靠近客戶。在規模上，它一般都是幾台到幾十台伺服器，然後在一些區域中心上可能會有幾百台伺服器，就是規模肯定比中心雲更小。
邊緣計算主要有三個方面的價值：
- 第一個，相對于把服務部署在中心的場景，把服務部署在更靠近客戶的端上能夠大大降低客戶通路的延遲。另外，比如提到像RTC、CDN、内容分發這樣的一些場景，肯定比直接去通路客戶中心要更短，響應時延一般都會在100毫秒以内。
- 第二個就是帶寬層面。傳統的RTC或者一些服務直接回源到中心，它的回源帶寬成本是比較高的。這個時候當你把一些政策和執行的算法放到邊緣上執行的話，可以大大減少客戶的帶寬，可以降低客戶的成本。當然因為我們邊緣的帶寬相對于中心的BGP帶寬肯定也是比較低的。
- 另外，還有一些本地計算的場景，有些客戶的資料有安全或者合規的要求，這種場景下是比較适合邊緣計算這樣一些場景的。
介紹完邊緣計算的介紹和邊緣計算的價值，接下來重點介紹火山引擎邊緣雲的邊緣容器。
什麼是邊緣容器呢？相對于目前的中心容器，邊緣容器分布于剛才介紹的廣泛的邊緣計算的節點，主要分布在二、三、四線這樣的城市，依托于像Kubernetes這樣一些雲原生的技術，給客戶提供場景化的解決方案。
火山引擎邊緣雲的邊緣容器主要是有以下的四個主要的特性：
資源覆寫廣
相對于中心容器，我們的資源覆寫面肯定會更廣。因為廣泛分布在大量的邊緣節點上，是以說我們資源分布面更廣，離客戶更近。
快速彈性傳遞
相對于邊緣虛機這樣的産品，因為傳統客戶之前在中心雲使用，比如像一些函數的服務或者RTC的服務，這些場景如果直接下沉到邊緣，大部分的客戶會面臨一個問題就是如何去管理邊緣的這些節點和機房，以及原來傳統的釋出系統也是基于中心或者單機房去設計的，當服務下沉到邊緣機房的時候，怎麼去運維。是以說邊緣容器第二個特性，就是相對于邊緣虛機的産品，能夠提供快速的彈性傳遞，客戶不需要去感覺廣州有幾個機房，深圳有幾個機房，甚至華東區電信有幾個機房，怎麼去開通，怎麼去維護。火山引擎會基于雲原生的技術屏蔽底層的整體資源覆寫的差異，然後批量傳遞。舉個簡單的例子，廣東電信的客戶需要1000個幾核幾GB的算力資源，我們就可以進行快速傳遞，而不需要客戶去針對于廣東電信100個邊緣節點逐個去開通，我們可以達到快速傳遞能力。
全生命周期管理
很多客戶，特别一些創新性場景，從中心下沉邊緣，或者某些新業務場景是沒有針對邊緣場景去部署和運維的能力的。因為邊緣機房太多了，節點也會面臨裁撤、下線。是以說火山引擎邊緣容器會屏蔽這些差異，給客戶統一提供像邊緣應用的部署、版本的管理，包括一些應用的遷移等等一系列的Devops的全應用生命周期管理的能力。
全局規劃排程
另相對于一些中心容器的排程，一般都是基于Region的排程，而邊緣的話，火山引擎有一個叫全局規劃排程。因為我們會把邊緣所有的邊緣機房的算力資源統一進行管理和管控，按照客戶的算力需求來進行批量傳遞。比如客戶說廣東電信需要1000個，這個時候我們就會看整個廣東電信整體的算力分布情況，給客戶進行批量傳遞，是以我們有一個全局規劃排程的技術能力。
02 火山引擎邊緣容器技術挑戰與應對
火山引擎邊緣容器技術挑戰
介紹完了邊緣容器，來講講火山引擎邊緣容器有哪些核心的産品技術挑戰，重點介紹以下幾個技術層面。
容器技術在邊緣計算場景落地會面臨什麼樣的技術挑戰呢？
因為傳統的就像Kubernetes這樣的技術，一般會去管理一個機房或者是管理多個Region，這樣是比較常見的。但是邊緣機房，第一個我們叫資源分散。因為邊緣的IDC機房分布太多了，有幾百個，甚至上千個IDC機房。而且不同的IDC機房實體環境、硬體環境，甚至伺服器數目都不太一樣，有的隻有幾台，有的有幾百台。怎麼基于Kubernetes合理地去管理不同的業務以及不同的資源，其實就是我們會面臨的第一個問題。
第二個，相對于中心的一些機房，其實邊緣的網絡環境是比較差的。像弱網、中心跟邊緣斷網、邊緣機房裁撤割接，這樣的情況是比較頻繁的。當客戶的業務下沉到邊緣的時候，特别是在邊緣跟中心斷網的時候，怎麼解決客戶邊緣容器上的業務、保證不會出現被驅逐這樣的一些情況，這就是我們面臨的第二個問題，怎麼去解決這樣的問題。
第三個，我們邊緣的機房規模太小了，不可能去做資源分池處理；不可能一部分機器去生産虛機，一部分去生産容器。有些機房可能總共就是幾台伺服器。那麼如何去實作虛機、容器的混合生産，混合排程，達到資源高密的生産和使用。這是我們面臨的第三個技術問題。
最後，由于邊緣IDC機房太多，很多客戶，比如說我這個應用，需要在廣州電信1發1.0.0的版本，在廣東電信2發1.0.2版本，不同的機房，要部署不同的版本。同時它在應用更新的時候，要實作灰階釋出。同時還有一種情況，很多客戶是多個應用組合部署才可以對外提供服務。比如說它在一個機房内同時要部署日志服務、監控服務，以及它自己的一些計算服務。如何去幫客戶解決這種多應用的組合部署 以及多應用之間的版本灰階，其實也是我們面臨的另外一個技術問題。這些問題都是在單機房或者說單kubernetes場景下不會遇到的。
我接下來重點講一下火山引擎容器團隊針對這四個技術難點，是選擇什麼樣的技術方案解決的。
火山引擎邊緣容器技術解決方案
首先就是重點給大家介紹一下我們整體火山容器平台的技術架構，就是邊緣容器平台架構。
最底層我們定義為整個IaaS、PaaS的資源層。在資源層面，邊緣的資源覆寫差異性是非常多的，我們有自建的IDC資源，甚至有一些CDN的自建機房資源，包括多雲的虛機資源以及其他場景的一些異構資源、三方資源。這些資源，我們會按照節點、屬性、位置、區域，按照标簽進行統一的管理，進行區分和分類。
當資源被标準化之後，我們會引入一層PaaS的資源管控層，這一層我們重點建構了第一個能力，就是解決第一個問題：海量資源的納管問題。整個技術其實我們也是基于Kubernetes技術打造的。後面我會重點去解釋一下我們整個PaaS資源層，怎麼基于Kubernetes進行設計。當我們把整個資源都納入Kubernetes體系之後，再上一層我們就需要對這些邊緣的資源進行編排、進行應用的管理、進行鏡像的管理，這一層叫metakubernetes，就是我們的管控叢集，我們叫PaaS管控層。這一層會統一給客戶提供，比如說像一些邊緣的Kubernetes叢集的管理，像叢集聯邦這樣的一些能力，以及比如說客戶業務部署的時候怎麼基于Kubernetes幫客戶主動熔斷業務，或者我們平台自身導緻的一些故障，能夠自動去熔斷，我們叫風控，就是風控的能力建設。
此外，因為邊緣的環境比較差，當客戶的容器大量更新的時候，怎麼去解決一個鏡像分發的問題。
針對于海量納管的資源之後，我們需要給客戶提供排程以及高密的生産，我們怎麼去解決這種融合排程、融合生産的問題呢？
最後就是一些監控計費的通用能力。
當我們整個PaaS管控層，整體建設了這些系統之後，容器平台側就會提供不同語義來使用整個火山引擎邊緣計算的資源；比如基于應用次元的，客戶完全不去感覺底層的資源差異，叫應用托管的形式。另外一種，使用者可能隻希望使用容器算力資源，它有自己的釋出系統，我們就可以直接傳遞邊緣容器執行個體，就是類似于中心ECI的資源形态。此外，我們也支援一種彈性的資源傳遞形态，比如按照分時、或者容器的負載自動擴縮容，我們叫邊緣Serverless這種形态。此外，有些使用者已經基于Kubernetes去建設運維釋出平台了，他希望基于Kubernetes的語義來使用容器資源，那麼針對這種場景，我們也會支援基于Kubernetes語義接口來使用邊緣容器資源的能力。最上層就是我們面對不同的業務場景，像一些點播、直播、RTC、動态加速、邊緣函數、撥測、壓測這樣的場景，我們基于PaaS整個服務層，針對不同使用者提供不同的使用形态。這是我們整個邊緣容器的技術架構。
接下來重點講講針對于以上的技術問題，我們到底怎麼去設計和落地的。
邊緣自治與資源納管
第一個問題是我們怎麼去解決邊緣海量資源的納管問題，以及像邊緣這種弱網關系下，我們怎麼去解決斷網情況下客戶的pod不驅逐，達到邊緣自治的能力。
針對第一個，因為邊緣資源比較分散，其實我們這邊也是分兩種場景進行解決的。第一種叫邊緣計算的資源，就是說我們自建IDC資源。我們自建的IDC資源，相對而言是比較穩定的，然後基本上規模相對比較穩定。這種情況下，因為它要去混合生産虛機和容器，在這種場景下，我們采用的是Kubernetes下沉的方案，在邊緣機房内部内置一個Kubernetes叢集。第二種就是相對于一些單台伺服器就是一個結點，或者是多雲的一些異構機器，這種機器，它的網絡環境不太标準，機型也不太标準，容易出現一些硬體的故障。這樣一些特殊的機器，我們是采用了一個叫邊緣托管kubernetes的方案。
在這個時候，我們在資源入庫存的時候，我們會針對不同的節點和機器進行标簽管理，最上層的有一個叫異構資源納管的容器管控平台。這個時候我們自動會根據目前的一個節點的規模和機器的形态，根據自動規劃的結果納入到不同的像邊緣托管的kubernetes叢集或者說是節點内部的一個kubernetes叢集。而我們異構納管平台，它就會自動去感覺不同區域的資源分布情況，自動去管控邊緣托管kubernetes叢集，自适應的去納管不同區域的資源。現在我們落地一般都是按照大區次元去規劃。一個邊緣托管kubernetes，我們大概會去納管2000-3000台伺服器。
通過這樣的模式，從這裡看到我們這個架構是分布式的架構，當邊緣機器越多的時候，我們會自動規劃出更多的kubernetes叢集來納管資源。這樣其實是能夠做到像邊緣數萬級别的機器，甚至數十萬級别機器基于邊緣的kubernetes進行納管的。
當我們解決了資源管理的問題之後，我們必然要解決第二個問題。弱網環境下，我們怎麼去解決不會因為邊緣跟中心的網絡斷連，導緻使用者的Workload或者pod被驅逐。在我們這個方案裡面就解決了這個問題。第一個，比如說像一些異構的資源池裡面，我們采用的是邊緣托管kubernetes的方案，邊緣托管kubernetes這個方案，當出現異構的機器跟中心的托管kubernetes斷連的時候，它原生的一些機制是會把原先的一些Workload，包括一些關鍵的網絡資源維護到邊緣節點上。這個時候它并不會影響已經生效的政策，進而也不會去驅逐在這些機器上的pod和關鍵的使用者網絡配置、存儲的一些配置。
針對于邊緣計算節點，就是我們自建比較穩定的IDC機房，因為我們采用的是邊緣kubernetes下沉的方案。這個方案裡面，當中心跟邊緣斷網了之後，邊緣的kubernetes，它原生就已經緩存了原先中心已經下發的各種Workload，各種的一些客戶的網絡配置，是以說它也是能夠達到邊緣自治的效果的。我們主要是通過這樣的一個技術架構來解決剛才講的面臨的資源分散管理以及像弱網環境下的資源管控問題、弱網環境下的邊緣自治的問題
混合排程&融合生産
接下來主要講一下第二個問題。剛才講邊緣的機房很少，當然行業的解決方案也很多，有很多采用分池的方案，我們整體的技術架構都是基于Kubernetes來設計的。因為我們需要達到高密生産，就是需要在一台機器上直接去融合生産容器和虛機。第二個，我們需要在排程層面融合去排程容器和虛機。先講第一個問題，我們怎麼去解決在一台伺服器上融合去生産容器和虛機，同時在底層的網絡和存儲能力上是能夠統一使用的。因為我們整體的設計方案都是按照超融合這樣的技術方案去設計。在虛機場景下，原生的Kubernetes是沒法生産虛機的，我們這裡是引入了kubevirt這樣一個技術架構。kubevirt這個技術架構裡面，它是可以通過kubelet這樣一個方案去拉起客戶的虛機，這樣我們就可以把虛機的生産納入到整個Kubernetes的體系裡面。
第二個在容器場景，我們需要在一台機上混合生産容器和虛機，就要解決一個安全的問題。在這裡面我們采用的是安全容器的方案。安全容器現在發展是比較成熟的，就是直接基于Kubernetes可以生産。底層像我們自研的VPC、基于DPDK自研的EVS網絡、基于Ceph的塊存儲，或者基于SPDK的本地盤，由于安全容器和虛拟機底層采用是統一虛拟化方案，是以我們Iaas層的存儲和網絡能力是可以統一複用的。兩種計算形态，像虛機和容器，底層的技術方案、實作體系是一緻的，這裡完全可以進行複用，這樣就可以達到我們在一台實體機上去混合生産容器、虛機這樣的能力。
當我們達到了混合生産虛機和容器的技術能力之後，其實也面臨着另外一個問題。舉個例子，比如說我在廣東電信1這個節點上，我總共就有10000核vcpu，這時候來了一個虛機大客戶，他要8000核vcpu，來了一個容器客戶，他要5000核vcpu，這個時候必然就會超過整個kubernetes可以排程的資源，其實就是超過了我們整個資源的售賣情況。在這種情況下，如果直接排程到邊緣的kubernetes叢集，其實會出現很多客戶的虛機或者很多客戶的容器出現大量生産失敗的情況。在這個情況下，我們針對大客戶，提出資源需求比較多的時候，其實我們在中心層面是做了統一排程的，我們叫全局規劃排程。
怎麼去了解這個事情呢？當我們要在某個IDC機房去給某個客戶擴容資源的時候，我們在排程體系裡面可以通過一定的資源營運政策來實作這樣一個能力，我們叫資源預占的方案。當這個節點，虛機需要8000核vcpu，但是客戶又不一定立馬部署。在這個時候，在整個資源排程，在生産之前，就會針對這個節點把庫存進行預占，我們叫預占的方案。這個時候容器有一個客戶來進行生産的時候，因為資源在中心層面已經被預占掉了，是以說這個時候就會回報失敗，這樣就可以解決當一個節點同時生産虛機和容器，資源沒有做規劃之前，導緻大量客戶生産失敗的情況。我們這個方案叫基于全局次元的資源預占。
應用生命周期管理
除了剛才解決問題之外，我們面臨另外一個問題，很多客戶從中心部署到邊緣的時候，其實是沒有邊緣的運維能力的。比如說我們之前接了一些HttpDns的服務或者函數的場景，因為他們之前都是基于中心服務去部署的，隻需要去管理一個Region或者兩個Region，但是邊緣的節點太多了，讓客戶直接去下沉維護，其實維護的複雜度非常高。另外因為邊緣不同的機房，在能力上會存在一定的差異，因為不同的機房伺服器數目不一樣，有的機房可能提供正常的7層LB，有的可能不提供7層LB，其實這個标準能力是不一樣的，包括有的機房可能提供本地盤，有的機房隻提供雲盤。
因為我們沒法像中心那樣每個機房都提供全套标準雲産品能力，這種情景對于客戶的運維複雜度是非常高的。就算他的業務想下沉邊緣，對他原生的業務系統改造也是非常大的。是以在這裡面，客戶就希望我們能夠把邊緣的資源這些能力進行一個高度的抽象，他不需要去感覺底層的差異，産品層面可以統一解決像邊緣應用編排、針對叢集的釋出、針對叢集的版本管理等問題。
在這個裡面，我們首先講第一個，我們怎麼去解決應用的多功能編排以及應用的版本管理呢？針對不同的叢集去管理客戶不同的版本。這裡面IDC1，客戶需要釋出V1.0.1版本，同時在IDC1上肯定隻提供了本地盤，在IDC2上提供了雲盤，客戶可能隻有存儲需求，他不想感覺這些差異，同時客戶又需要配套的LB、負載均衡的能力，甚至包括一定服務發現能力。
這個裡面我們主要是引入了兩層抽象的概念。第一個叫應用叢集，一個叫應用，就是我們整體一個應用編排的體系設計是基于這兩個次元在設計的，在應用叢集裡面有幾個關鍵的語義，就是把我們雲産品的能力會融合到應用叢集描述的語義裡面。比如說網絡的LB、ALB、Nat、PIP、存儲的本地盤、雲盤等，包括算力規格，針對叢集級别，我們抽象出來了一個叫應用叢集的概念。這個應用叢集裡面會把這些網絡和存儲能力融合進去。
這樣的話，我們針對于IDC1和IDC2做應用生産的時候，其實是打包生産的模式，當我們要部署到IDC1的時候，我們會把客戶配套需要的LB、Workload、存儲，統一會下發下去，然後在邊緣IDC1上再進行真正的一個基于Kubernetes的生産，生産Pod的同時，然後把LB的配置生産出來，把存儲的配置給它生産出來。
在這一層主要是在PaaS層實作。第二層抽象，我們叫應用(Application)。客戶隻需要針對應用去配置他的LB、配置他的Workload、配置他的EIP、配置他的存儲。這樣的話，當客戶需要部署到IDC1、IDC2的時候，這個時候客戶隻需要在應用描述他針對于網絡存儲以及自己應用的描述。描述之後，我們整個PaaS排程就會針對我們的應用叢集去打包部署到IDC1、IDC2，這樣客戶就不需要感覺到底層不同網絡、不同存儲的情況。同時針對這個架構，我們就可以實作客戶針對不同叢集的版本管理能力。比如剛剛講的客戶在應用裡面就可以去描述，我需要在IDC1裡面部署V1.0.1版本，我要在IDC2裡面部署V1.0.2版本。當我們PaaS平台打包部署到IDC1和IDC2的時候，這個時候我們就會感覺客戶到選擇的對應版本，然後去部署對應的版本。通過這樣一個應用叢集以及面向客戶的應用的設計概念，我們解決了客戶多叢集的部署以及版本管理的問題。
其實還會面臨另外一個問題，就是說很多客戶業務部署到邊緣的時候，不止有一個應用，會面臨什麼問題？其實他會部署多個應用，客戶需要部署一個日志服務，同時要部署一個計算服務，還要部署一個監控服務。它隻有多個服務同時在一個IDC上生産出來之後，才可以真正對外提供服務，這個叫多應用的編排。
在多應用的編排場景下，我們這裡引入了一個新的設計思路，叫主從應用的思路。當客戶要選擇多應用編排的時候，他需要去選擇一個主應用(master application)，當客戶建立完成多個子應用之後，在部署之前需要去配置哪些子應用和主應用去綁定。在這個時候我們整個PaaS排程體系裡面就會去感覺到這樣的主應用跟子應用之間的綁定關系，在資源排程和業務部署的時候就會按照客戶的綁定關系進行整體的一個資源排程以及整體應用的部署。
同時針對剛剛講的，我們基于應用叢集，客戶可以配置部署的版本，基于應用叢集的版本管理也可以同時實作客戶就算在多個應用綁定部署的情況下，也可以去實作不同的應用在不同的叢集，部署不同的版本。主要就是通過應用叢集、應用和主從應用，在我們設計裡面引入這樣的幾個設計思路，最終能夠解決客戶在使用邊緣算力資源的時候面臨的版本管理、應用管理的問題。
穩定性體系建設
最後，給大家講一下我們整個邊緣容器平台在穩定性上是怎麼去設計和落地的。
穩定性設計主要是三塊，監控、告警，還有當平台發現客戶的業務出現問題的時候，我們要能夠熔斷。在監控、告警上，跟通用的Kubernetes方案差不多，我們也是将邊緣托管Kubernets叢集以及邊緣的kubernetes叢集，像事件、一些日志、名額統一都收集到中心，再去建構我們整個監控大盤，再基于我們自己的告警中心，當發現客戶的異常名額的時候，進行業務告警。比如說客戶某個關鍵的網絡資源被删除掉了，客戶自己的應用被删除掉了，我們會觸發一些告警。
重點講一下我們的整個風控。什麼叫風控呢？我們做風控的本質原因，是因為很多客戶上容器平台的時候，之前客戶在虛機的運維模式下或者裸機的運維模式下不會面臨虛機資源被批量删除的問題，因為是比較穩定的IaaS資源，它是不會出現批量釋放、批量銷毀、批量當機的情況的。但是當客戶去使用容器的場景下，可能因為客戶自己的誤操作，或者容器平台自身的一些問題，導緻客戶的容器或者一些關鍵的資源被錯誤的批量删除掉。
我們為了解決這個問題，引入了一個風控熔斷的設計思路。我們這裡實作的方案就是基于Kubernetes的webhook。基于webhook的這個架構體系進行設計的，把客戶的事件進行統一的收集和處理，在政策層面，我們引入了兩個政策，一個叫靜态政策，一個叫動态政策。靜态政策比較簡單，就是針對一些大客戶或者一些關鍵的，比如像網絡、存儲，我們會進入封禁，當發現客戶做了這樣一些删除操作，或者我們自己的系統出現問題了，在執行删除之前，我們會直接熔斷，或者客戶做了删除，我們會直接給他傳回失敗，這樣客戶的操作就會失敗，這時候客戶就不會因為誤操作出現規模故障。
第二個時間次元的，我們叫動态政策。動态政策主要是做了基于時間次元的管控政策。最終實作的效果就是客戶可以配過去的某一個時間段，客戶的容器或者某個關鍵的資源不允許被删除，比如客戶配置過去5分鐘不允許删除超過100個Pod，如果發生了超過100個Pod被删除的情況，就認為是客戶自己誤操作或者平台自身出現了問題，這個時候容器平台就會主動觸發熔斷，并且觸發告警，進而解決客戶規模故障的問題。
03 邊緣容器的應用探索與實踐
講了我們整個穩定性方案之後，接下來重點給大家講一下我們在邊緣的場景下，我們怎麼去落地的，有哪些典型的案例。
邊緣函數場景的應用實踐
第一個案例，重點給大家介紹一下創新型業務。什麼叫做創新型業務呢？比如邊緣函數的業務，隻有兩個左右的研發同學，在邊緣函數的業務場景下，他希望使用邊緣的資源去降低整個邊緣的延遲，它需要在邊緣給客戶提供一些類似SSR渲染的産品能力。這個時候讓它去開發一個針對邊緣的資源管控和釋出平台肯定是不現實的。針對函數場景，它需要如下幾個能力，因為它是多個應用部署，就需要提供多應用部署的能力，同時它的應用之間是要支援服務發現的，就是函數的日志服務、計算服務、配置服務等是需要互互相動的。
針對這個場景，我們主要是讓他們使用我們邊緣容器應用托管的解決方案。一個就是針對于應用的部署，我們提供了多應用編排部署的能力，可以滿足函數的多應用部署編排需求。同時在叢集内，我們是支援基于kubernetes的coredns服務發現産品能力的。此外，它的函數場景也要支援http、https這樣的7層接入能力。這種場景下，我們基于自研的ealb負載均衡産品，結合類似ingress controller的實作機制，在邊緣上會動态感覺客戶在這個節點部署的pod，這個7層LB就會把函數的請求轉發給函數的容器裡面。通過這樣一個方案可以讓函數業務基于邊緣容器快速部署起來，進而實作對外産品化。
另外針對函數場景，因為它其實是需要做就近接入的，它本身是沒有dns接入排程能力的，我們結合GTM産品能力給函數提供相應的邊緣dns接入排程能力。客戶将函數的業務部署到邊緣的節點之後，拿到了整個邊緣節點的部署情況，這個時候就會通過火山的GTM産品生成出它的排程域，這個時候就會達到什麼效果呢？當容器平台把函數的業務部署到廣東電信的時候，廣東電信的客戶去通路函數服務的時候，就隻會解析到廣東電信的節點。同樣的道理，深圳的就會解析到深圳，西北的解析到西北，海外的解析到海外。通過這樣一套解決方案，就可以使函數的業務對外快速産品化，可以把整個産品快速孵化出來。
動态加速場景的應用實踐
第二個，動态加速場景，是一種典型的傳統VCDN業務場景。什麼叫傳統業務呢？有些業務，像CDN、RTC這樣的場景，它本身是有邊緣資源的運維能力的。但是在一些大促活動的時候，希望能夠使用一些邊緣容器算力資源，能夠快速擴容一批資源出來。但是它并不需要使用容器一些更高階的産品能力，比如應用部署、版本釋出等。因為他們已經基于邊緣的實體機或者虛拟機進行部署，有一套自有的排程體系和釋出體系。是以他們使用邊緣容器更希望什麼效果呢？首先希望能夠用到容器的快速彈性排程能力，在大促活動的時候、春節活動的時候能夠快速部署。另外又能兼顧老的運維能力和釋出系統，希望你的容器能夠支援遠端ssh、systemd，甚至能夠支援核心協定棧優化、支援TOA、UOA等核心子產品安裝，這類場景其實我們也是做了一套技術方案。
首先我們基于客戶原生實體機使用的核心，定制了滿足客戶需求的安全容器核心，此外，将ntp、systemd、ssh等元件內建到基礎鏡像裡面，提供了一個類似富容器的基礎鏡像。基于這個富容器，我們可以給客戶提供一系列跟虛機持平的技術能力。這樣達到一個什麼效果呢？像動态加速這樣的場景，比如說我需要廣東電信擴充100個32C96G的容器執行個體，這時候我們給它排程出來之後，相對DCDN的SRE而言，他就可以把這些資源直接納入到原生的運維釋出平台裡面，進而他可以基于他原來的釋出平台去部署對應的DCDN業務。它原生的業務，包括自有的一些應用和子產品安裝都是可以相容的，這樣就可以達到像這種基于實體機運維的傳統場景也可以使用容器資源。
APM業務場景的應用實踐
最後一個場景就是彈性場景，像撥測、壓測，他們的主要需求就是希望在大促活動的時候，或者說有一些特殊場景的時候，希望快速傳遞，比如全國1000個容器，但是具體分布在哪些節點，客戶并不關心，分布在哪些城市，客戶也不關心，另外客戶可能就隻用一天或者半天，用完之後就要快速釋放掉，因為這樣可以大大減少他們的成本。這樣的場景就是基于容器執行個體産品直接托管他們的應用，使用邊緣容器執行個體的批量資源傳遞這樣一個方案就可以達到這樣的效果。
04 總結與展望
最後給大家講一講後面整個雲原生在邊緣計算場景上，我們有什麼樣的産品技術規劃。
因為剛剛講了，第一個就是很多業務從中心下沉到邊緣的時候，可能需要去跟中心做一些協同，它沒法脫離中心完全在邊緣就可以對外提供服務，可能需要和中心的管控服務或者信令服務做一些協同。當它的服務部署在多個邊緣節點之後，它也希望做一些協同。這樣的場景下，我們會結合servicemesh的技術，給客戶提供雲邊、邊邊協同的産品技術能力。
另外就是彈性排程場景，比如分時排程，就是不同時間片算力資源需求不一樣，希望按照不同時間片動态排程出來算力資源，這樣可以大大減少成本，或者某些場景需要跨節點容災排程，我們後續也會重點建設彈性排程的産品技術能力。
此外像AI、推理，這些場景，需要對應的GPU容器執行個體，這個時候我們也會在這個技術方向做一些技術的落地。此外，我們也會針對不同場景的需求去打磨對應場景的解決方案。這是火山邊緣容器團隊在後面會做的一些産品技術規劃。
接下來就是我們火山引擎微信公衆号、飛書交流群，大家感興趣可以加入，有問題可以在裡面問，我們也會在裡面進行回答，謝謝大家！