雲原生體系下 Serverless 彈性探索與實踐

Serverless 時代的來臨

Serverless 顧名思義，是一種“無伺服器”架構，因為屏蔽了伺服器的各種運維複雜度，讓開發人員可以将更多精力用于業務邏輯設計與實作。在 Serverless 架構下，開發者隻需要關注于上層應用邏輯的開發，而諸如資源申請，環境搭建，負載均衡，擴縮容等等伺服器相關的複雜操作都由平台來進行維護。在雲原生架構白皮書中，對Serverless 的特性有以下概括：​

• 全托管的計算服務，客戶隻需要編寫代碼建構應用，無需關注同質化的、負擔繁重的基于伺服器等基礎設施的開發、運維、安全、高可用等工作；
• 通用性，能夠支撐雲上所有重要類型的應用；
• 自動的彈性伸縮，讓使用者無需為資源使用提前進行容量規劃；
• 按量計費，讓企業使用成本得有效降低，無需為閑置資源付費。

回顧整個 Serverless 的發展曆程，我們可以看到從 2012 年首次提出 Serverless 概念為起點，再到 AWS 推出 Lambda 雲産品的這段時間内，人們對 Serverless 的關注度出現了爆發式的增長，對無伺服器的期待和暢想逐漸引爆整個行業，但 Serverless 的推廣和生産落地的過程卻不容樂觀，Serverless 理念與實操生産的過程中存在 Gap，挑戰着人們固有的使用體驗和習慣。

阿裡雲堅信 Serverless 将作為雲原生之後确定性的發展方向，相繼推出了FC,SAE 等多款雲産品來覆寫不同領域，不同類型的應用負載來使用 Serverless 技術，并且不斷在推進整個 Serverless 理念的普及與發展。

就目前 Serverless 整個市場格局而言，阿裡雲已經做到了 Serverless 産品能力中國第一，全球領先，在去年 Forrester 評測魔力象限中可以明顯的看到阿裡雲在 Serverless 領域已經與 AWS 不相上下，于此同時，阿裡雲 Serverless 使用者占比中國第一，在 2020 年中國雲原生使用者調研報告中整個阿裡雲 Serverless 使用者占比已經達到了66%，而在 Serverless 技術采用情況的調研中表明，已經有越來越多的開發者和企業使用者将 Serverless 技術應用于核心業務或者将要應用于核心業務之中。

Serverless 彈性探索

彈性能力作為雲的核心能力之一，所關注的問題是容量規劃與實際叢集負載間的沖突，通過兩幅圖的對比可以看到，如果采用預先規劃的方式進行資源安排，會由于資源準備量和資源需求量的不比對導緻資源浪費或者資源不足的情況，進而導緻成本上的過多開銷甚至業務受損，而我們期望極緻彈性能力，是準備的資源和實際需求的資源幾乎比對，這樣使得應用整體的資源使用率較高，成本也随業務的增減和相應的增減，同時不會出現因容量問題影響應用可用性的情況，這就是彈性的價值。

彈性其實作上分為可伸縮性和故障容忍性,可伸縮性意味着底層資源可以參照名額的變化有一定的自适應能力，而故障容忍性則是通過彈性自愈確定服務中的應用或執行個體處于健康的狀态。上述能力帶來的價值收益在于降成本的同時提升應用可用性，一方面，資源使用量貼合應用實際消耗量，另一方面，提升峰值的應用可用性，進而靈活适應市場的不斷發展與變化。​

下面将對目前較為普遍的三種彈性伸縮模式進行闡述和分析。

首先是 IaaS 彈性伸縮，其代表産品是各雲廠商雲伺服器彈性伸縮，如阿裡雲ess,可以通過配置雲監控的告警規則來觸發相應的 ECS 增減操作，同時支援動态增減 Slb 後端伺服器和 Rds 白名單來保證可用性，通過健康檢查功能實作彈性自愈能力。ESS 定義了伸縮組的概念，即彈性伸縮的基本機關，為相同應用場景的 ECS 執行個體的集合及關聯 Slb,Rds, 同時支援多種伸縮規則，如簡單規則，進步規則，目标追蹤規則，預測規則等，使用者的使用流程為建立伸縮組和伸縮配置，建立伸縮規則，監控檢視彈性執行情況。

Kubernetes 彈性伸縮，這裡主要關注于水準彈性 hpa，其代表産品為 K8s 以及其所對應的托管雲産品，如阿裡雲容器服務，K8s 做為面向應用運維的基礎設施和 Platform for Platform,提供的内置能力主要是圍繞着容器級别的管理和編排來展開的,而彈性能力聚焦于對底層 Pod 的動态水準伸縮，K8s hpa 通過輪詢 Pod 的監控資料并将它與目标期望值比較進行，通過算法實時計算來産生期望的副本數，進而對 Workload 的副本數進行增減操作，使用者在實際使用上需要建立并配置對應的名額源和彈性規則以及對應的 Workload，可以通過事件來檢視彈性的執行情況。

最後介紹一下應用畫像彈性伸縮，其主要用于網際網路公司内部，如阿裡 ASI 容量平台。容量平台提供容量預測服務和容量變更決策服務，指導底層容量變更元件如 AHPA/VPA 實作容量彈性伸縮，并根據彈性結果修正容量畫像。以畫像驅動為主 + 名額驅動為輔實作彈性伸縮能力，通過提前伸縮 + 實時修正來降低彈性伸縮風險。整個彈性伸縮會借助odps和機器學習能力對執行個體監控等資料進行處理并産生應用畫像，如基準畫像，彈性畫像，大促畫像等，并借助容量平台來完成畫像注入，變更管控和故障熔斷等操作。使用者使用流程為應用接入，基于曆史資料/經驗生成對應的容量畫像，實時監控名額修正畫像，并監控檢視彈性執行情況。

從對比可以看出各産品彈性伸縮功能模式上從抽象來講基本相同，均由觸發源，彈性決策和觸發動作組成，觸發源一般依賴外部監控系統，對節點名額，應用名額進行采集處理，彈性決策一般基于周期性輪詢并算法決策，有部分基于曆史資料分析預測以及使用者定義的定時政策，而觸發動作為對執行個體進行水準擴縮，并提供變更記錄與對外通知。各個産品在此基礎上做場景豐富度，效率，穩定性的競争力，并通過可觀測能力提升彈性系統的透明度，便于問題排查和指飛彈性優化，同時提升使用者使用體驗與粘性。

各産品彈性伸縮模型也存在這一定的差異，對于 IaaS 彈性伸縮，其作為老牌彈性伸縮能力，沉澱時間長，功能強大且豐富，雲廠商間能力趨于同質化。彈性效率相較容器受限，且強綁定各自底層 Iaas 資源。Kubernetes 作為開源産品，通過社群力量不斷優化疊代彈性能力和最佳實踐，更符合絕大部分開發運維人員訴求。對彈性行為和api進行高度抽象，但其可擴充性不強，無法支援自定義需求。而應用畫像彈性伸縮具有集團内部特色，根據集團應用現狀和彈性訴求進行設計，且更聚焦于資源池預算成本優化，縮容風險，複雜度等痛點。不易拷貝擴充，特别對于外部中小客戶不适用。​

從終态目标上，可以看出公有雲與網際網路企業方向的不同：

​

• 網際網路企業往往由于其内部應用具有顯著流量特征，應用啟動依賴多，速度慢，且對整體資源池容量水位，庫存财務管理，離線上混部有組織上的諸多訴求，因而更多的是以容量畫像提前彈性擴容為主，基于 Metrics 計算的容量資料作為實時修正，其目标是容量畫像足夠精準以至于資源使用率達到預期目标。
• 公有雲廠商服務于外部客戶，提供更為通用，普适的能力，并通過可拓展性滿足不同使用者的差異化需求。尤其在 Serverless 場景，更強調應用應對突發流量的能力，其目标在于無需容量規劃，通過名額監控配合極緻彈性能力實作應用資源的近乎按需使用且整個過程服務可用。

Serverless彈性落地

Serverless 作為雲計算的最佳實踐、雲原生發展的方向和未來演進趨勢，其核心價值在于快速傳遞、智能彈性、更低成本。​

在時代背景下，SAE 應運而生，SAE 是一款面向應用的 Serverless PaaS 平台，支援 Spring Cloud、Dubbo 等主流開發架構，使用者可以零代碼改造直接将應用部署到 SAE，并且按需使用，按量計費，可以充分發揮 Serverless 的優勢為客戶節省閑置資源成本，同時體驗上采用全托管，免運維的方式，使用者隻需聚焦于核心業務開發，而應用生命周期管理，微服務管理，日志，監控等功能交由SAE完成。

彈性的競争力主要在于場景豐富度，效率，穩定性的競争力，先講一下SAE在彈性效率上的優化。​

通過對 SAE 應用的整個生命周期進行資料統計和可視化分析，其包含排程，init container 建立，拉取使用者鏡像，建立使用者容器，啟動使用者容器&應用這幾個階段，示意圖中對其耗時的占比進行了簡化。我們可以看到整個應用生命周期耗時集中于排程，拉取使用者鏡像，應用冷啟動這幾個階段。針對于排程階段，其耗時主要在于 SAE 目前會執行打通使用者 VPC 操作，由于該步驟強耦合于排程，本身耗時較長，且存在建立長尾逾時，失敗重試等情況，導緻排程鍊路整體耗時較長。

由此産生的疑問是可否優化排程速度？可否跳過排程階段 ? 而對于拉取使用者鏡像，其包含拉取鏡像與解壓鏡像的時長，特别是在大容量鏡像部署的情況下尤為突出。優化的思路在于拉取鏡像是否可以優化使用緩存，解壓鏡像是否可以優化。而對于應用冷啟動，SAE 存在大量單體和微服務的 JAVA 應用，JAVA 類型應用往往啟動依賴多，加載配置慢，初始化過程長，導緻冷啟動速往往達到分鐘級。優化的方向在于可否避免冷啟動流程并使使用者盡量無感，應用無改造。

首先 SAE 采用了原地更新能力，SAE 起初使用了 K8s 原生的 Deployment 滾動更新政策進行釋出流程，會先建立新版本 Pod，再銷毀舊版本 Pod 進行更新，而所謂原地更新，即隻更新 Pod 中某一個或多個容器版本、而不影響整個 Pod 對象、其餘容器的更新。其原理是通過 K8s patch 能力，實作原地更新 Container，通過 K8s readinessGates 能力，實作更新過程中流量無損。

原地更新給SAE帶來了諸多價值，其中最重要的是避免重排程，避免 Sidecar 容器（ARMS,SLS,AHAS）重建,使得整個部署耗時從消耗整個 Pod 生命周期到隻需要拉取和建立業務容器，于此同時因為無需排程，可以預先在 Node 上緩存新鏡像，提高彈性效率。SAE 采用阿裡開源 Openkruise 項目提供的 Cloneset 作為新的應用負載，借助其提供的原地更新能力，使得整個彈性效率提升 42%。

同時 SAE 采用了鏡像預熱能力，其包含兩種預熱形式：排程前預熱，SAE 會對通用的基礎鏡像進行全節點緩存，以避免其頻繁的從遠端進行拉取。與此同時對于分批的場景支援排程中預熱，借助 Cloneset 原地更新能力，在更新的過程中可以感覺到執行個體的節點分布情況，這樣就可以在第一批部署新版本鏡像的同時，對後面批次的執行個體所在節點進行鏡像預拉取，進而實作排程與拉取使用者鏡像并行。通過這項技術，SAE 彈性效率提升了 30%。

剛才講述的優化點在于拉取鏡像部分，而對于解壓鏡像，傳統容器運作需要将全量鏡像資料下載下傳後再解包，然而容器啟動可能僅使用其中部分的内容，導緻容器啟動耗時長。SAE 通過鏡像加速技術，将原有标準鏡像格式自動轉化為支援随機讀取的加速鏡像，可以實作鏡像資料免全量下載下傳和線上解壓，大幅提升應用分發效率，同時利用 Acree 提供的 P2P 分發能力也可以有效減少鏡像分發的時間。

對于 Java 應用冷啟動較慢的痛點，SAE 聯合 Dragonwell 11 提供了增強的 AppCDS 啟動加速政策，AppCDS 即 Application Class Data Sharing，通過這項技術可以擷取應用啟動時的 Classlist 并 Dump 其中的共享的類檔案，當應用再次啟動時可以使用共享檔案來啟動應用，進而有效減少冷啟動耗時。映射到 SAE 的部署場景，應用啟動後會生成對應的緩存檔案在共享的 NAS 中，而在進行下一次釋出的過程中就可以使用緩存檔案進行啟動。整體冷啟動效率提升 45%。

除了對整個應用生命周期的效率進行優化外，SAE 也對彈性伸縮進行了優化，整個彈性伸縮流程包括彈性名額擷取，名額決策以及執行彈性擴縮操作三部分。對于彈性名額擷取，基礎監控名額資料已經達到了秒級擷取，而對于七層的應用監控名額，SAE 正在規劃采用流量透明攔截的方案保證名額擷取的實時性。而彈性決策階段，彈性元件啟用了多隊列并發進行 Reconcile，并實時監控隊列堆積，延時情況。

SAE 彈性伸縮包括強大的名額矩陣，豐富的政策配置，完善的通知告警機制及全方位可觀測能力,支援多種資料源：原生的 MetricsServer，MetricsAdapter，Prometheus，雲産品 SLS,CMS,SLB 以及外部的網關路由等，支援多種名額類型：CPU、MEM、QPS、RT、TCP 連接配接數，出入位元組數，磁盤使用率，Java線程數，GC 數還有自定義名額。對名額的抓取和預處理後，可以自定義配置彈性政策來适配應用的具體場景：快擴快縮，快擴慢縮，隻擴不縮，隻縮不擴，DRYRUN，自适應擴縮等。

同時可以進行更為精細化的彈性參數配置,如執行個體上下限，名額區間，步長比例範圍，冷卻、預熱時間，名額采集周期和聚和邏輯，CORN 表達式，後續也會支援事件驅動的能力。彈性觸發後會進行對應的擴縮容操作，并通過切流保證流量無損，并且可以借助完善的通知告警能力（釘釘，webhook,電話，郵件，短信）來實時觸達告知使用者。彈性伸縮提供了全方位的可觀測能力，對彈性的決策時間，決策上下文進行清晰化展現，并且做到執行個體狀态可回溯，執行個體 SLA 可監控。

SAE 彈性能力在場景豐富度上也有着相應的競争力，這裡重點介紹一下 SAE 目前支援的四種場景：​

• 定時彈性：在已知應用流量負載周期的情況下進行配置，應用執行個體數可以按照時間，星期，日期周期進行規律化擴縮，如在早 8 點到晚 8 點的時間段保持 10 個執行個體數應對白天流量，而在其餘時間由于流量較低則維持在 2 個執行個體數甚至縮 0。适用于資源使用率有周期性規律的應用場景，多用于證券、醫療、政府和教育等行業。
• 名額彈性：可以配置期望的監控名額規則，SAE 會時應用的名額穩定在所配置的名額規則内，并且預設采用快擴慢縮的模式來保證穩定性。如将應用的cpu名額目标值設定為 60%，QPS 設定為 1000，執行個體數範圍為 2-50。這種适用于突發流量和典型周期性流量的應用場景，多用于網際網路、遊戲和社交平台等行業。
• 混合彈性：将定時彈性與名額彈性相結合，可以配置不同時間，星期，日期下的名額規則，進而更加靈活的應對複雜場景的需求。如早 8 點到晚 8 點的時間段 CPU 名額目标值設定為 60%，執行個體數範圍為 10-50，而其餘時間則将執行個體數範圍降為 2-5，适用于兼備資源使用率有周期性規律和有突發流量、典型周期性流量的應用場景，多用于網際網路、教育和餐飲等行業。
• 自适應彈性：SAE 針對流量突增場景進行了優化，借助流量激增視窗，計算目前名額在這個時刻上是否出現了流量激增問題，并會根據流量激增的強烈程度在計算擴容所需的執行個體時會增加一部分的備援，并且在激增模式下，不允許縮容。

穩定性是 SAE 彈性能力建設的過程中非常重要的一環，保證使用者應用在彈性過程中按照預期行為進行擴縮，并保證整個過程的可用性是關注的重點。SAE 彈性伸縮整體遵循快擴慢縮的原則，通過多級平滑防抖保證執行穩定性，同時對于名額激增場景，借助自适應能力提前擴容。SAE 目前支援四級彈性平滑配置保證穩定性：​

• 一級平滑：對名額擷取周期，單次名額擷取的時間視窗，名額計算聚和邏輯進行配置
• 二級平滑：對名額數值容忍度，區間彈性進行配置
• 三級平滑：對機關時間擴縮步長，百分比，上下限進行配置
• 四級平滑：對擴縮冷卻視窗，執行個體預熱時間進行配置

Serverless 彈性最佳實踐

SAE 彈性伸縮可以有效解決瞬時流量波峰到來時應用自動擴容，波峰結束後自動縮容。高可靠性、免運維、低成本的保障應用平穩運作，在使用的過程中建議遵循以下最佳實踐進行彈性配置。​

• 配置健康檢查和生命周期管理

建議對應用健康檢查進行配置，以保證彈性擴縮過程中的應用整體可用性，確定您的應用僅在啟動、運作并且準備好接受流量時才接收流量 同時建議配置生命周期管理 Prestop，以確定縮容時按照預期優雅下線您的應用。​

• 采用指數重試機制

為避免因彈性不及時，應用啟動不及時或者應用沒有優雅上下線導緻的服務調用異常，建議調用方采用指數重試機制進行服務調用。​

• 應用啟動速度優化

為提升彈性效率，建議您優化應用的建立速度，可以從以下方面考慮優化：

• 軟體包優化：優化應用啟動時間，減少因類加載、緩存等外部依賴導緻的應用啟動過長
• 鏡像優化：精簡鏡像大小，減少建立執行個體時鏡像拉取耗時，可借助開源工具 Dive，分析鏡像層資訊，有針對性的精簡變更
• Java 應用啟動優化：借助 SAE 聯合 Dragonwell 11 ，為 Java 11 使用者提供了應用啟動加速功能

• 彈性伸縮名額配置

彈性伸縮名額配置，SAE 支援基礎監控，應用監控多名額組合配置，您可以根據目前應用的屬性（CPU敏感 /記憶體敏感 /io 敏感）進行靈活選擇。​

可以通過對基礎監控和應用監控對應名額曆史資料（ 如過去6h, 12h, 1天,7天峰值，P99,P95 數值）進行檢視并預估名額目标值，可借助 PTS 等壓測工具進行壓測，了解應用可以應對的并發請求數量、需要的 CPU 和記憶體數量，以及高負載狀态下的應用響應方式，以評估應用容量峰值大小。

名額目标值需要權衡可用性與成本進行政策選擇，如

• 可用性優化政策 配置名額值為40%
• 可用性成本平衡政策 配置名額值為50%
• 成本優化政策 配置名額值為70%

​同時彈性配置應考慮梳理上下遊，中間件，db等相關依賴，配置對應的彈性規則或者限流降級手段，確定擴容時全鍊路可以保證可用性。

在配置彈性規則後，通過不斷監視和調整彈性規則以使容量更加接近應用實際負載。

• 記憶體名額配置

關于記憶體名額，考慮部分應用類型采用動态記憶體管理進行記憶體配置設定（如 Java jvm記憶體管理，Glibc Malloc 和 Free 操作），應用閑置記憶體并沒有及時釋放給作業系統，執行個體消耗的實體記憶體并不會及時減少且新增執行個體并不能減少平均記憶體消耗，進而無法觸發縮容，針對于該類應用不建議采用記憶體名額。​

• Java 應用運作時優化：釋放實體記憶體，增強記憶體名額與業務關聯性

​借助 Dragonwell 運作時環境，通過增加 JVM 參數開啟 ElasticHeap 能力，支援 Java 堆記憶體的動态彈性伸縮，節約 Java 程序實際使用的實體記憶體占用。

• 最小執行個體數配置

​配置彈性伸縮最小執行個體數建議大于等于2，且配置多可用區 VSwitch，防止因底層節點異常導緻執行個體驅逐或可用區無可用執行個體時應用停止工作，保證應用整體高可用。

• 最大執行個體數配置

配置彈性伸縮最大執行個體數時，應考慮可用區 IP 數是否充足，防止無法新增執行個體。可以在控制台 VSwitch 處檢視目前應用可用 IP，若可用IP較少考慮替換或新增 VSwitch。

• 彈性到達最大值

可以通過應用概覽檢視目前開啟彈性伸縮配置的應用，并及時發現目前執行個體數已經到達峰值的應用，進行重新評估其彈性伸縮最大值配置是否合理。若期望最大執行個體數超過産品限制（目前限制單應用50執行個體數，可提工單回報提高上限）​

• 可用區再均衡

彈性伸縮觸發縮容後可能會導緻可用區配置設定不均，可以在執行個體清單中檢視執行個體所屬可用區，若可用區不均衡可以通過重新開機應用操作實作再均衡。​

• 自動恢複彈性配置

當進行應用部署等變更單操作時，SAE 會停止目前應用的彈性伸縮配置避免兩種操作沖突，若期望變更單完成後恢複彈性配置，可以在部署時勾選系統自動恢複。

• 彈性曆史記錄

SAE 彈性生效行為目前可通過事件進行檢視擴縮時間，擴縮動作，以及實時，曆史決策記錄和決策上下文可視化功能，以便衡量彈性伸縮政策的有效性，并在必要時進行調整。​

• 彈性事件通知

結合釘釘，Webhook,短信電話等多種通知管道，便于及時了解彈性觸發狀況