Serverless 時代的來臨

Serverless 顧名思義，是一種“無伺服器”架構，因為遮蔽了伺服器的各種運維複雜度，讓開發人員可以將更多精力用於業

務邏輯設計與實現。在 Serverless 架構下，開發者只需要關注於上層應用邏輯的開發，而諸如資源申請，環境搭建，負載均

衡，擴縮容等等伺服器相關的複雜操作都由平臺來進行維護。在雲原生架構白皮書中，對Serverless 的特性有以下概括：

- 全託管的計算服務，客戶只需要編寫程式碼構建應用，無需關注同質化的、負擔繁重的基於伺服器等基礎設施的開發、運維、

   安全、高可用等工作；

- 通用性，能夠支撐雲上所有重要型別的應用；

- 自動的彈性伸縮，讓使用者無需為資源使用提前進行容量規劃；

- 按量計費，讓企業使用成本得有效降低，無需為閒置資源付費。

回顧整個 Serverless 的發展歷程，我們可以看到從 2012 年首次提出 Serverless 概念為起點，人們對 Serverless 的關注度出現了爆發式的增長，對無伺服器的期待和暢想逐漸引爆整個行業，serverless的推廣和生產落地的過程卻不容樂觀，Serverless 理念與實操生產的過程中存在 Gap，挑戰著人們固有的使用體驗和習慣。阿里雲堅信 Serverless 將作為雲原生之後確定性的發展方向，相繼推出了FC,SAE 等多款雲產品來覆蓋不同領域，不同型別的應用負載來使用 Serverless 技術，並且不斷在推進整個 Serverless 理念的普及與發展。

就當前 Serverless 整個市場格局而言，阿里雲已經做到了 Serverless 產品能力中國第一，全球領先，阿里雲 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,簡訊電話等多種通知渠道，便於及時瞭解彈性觸發狀況

最後分享一個採用 SAE 彈性伸縮功能的客戶案例，在 2020 新冠疫情期間，某線上教育客戶業務流量暴漲 7-8 倍，硬體成

本和業務穩定性面臨巨大風險。如果此時採用傳統的 ECS 架構，客戶就需要在非常短的時間內做基礎設施的架構升級，這

對使用者的成本及精力都是非常大的挑戰。但如果採用 SAE，使用者 0 改造成本即可享受 Serverless 帶來的技術紅利，結合SAE

的多場景彈性策略配置，彈性自適應和實時可觀測能力，保障了使用者應用在高峰期的業務 SLA，並且透過極致彈性效率，節

省硬體成本達到 35%。

綜上，彈性發展方向上，尤其是在 Serverless 場景，更強調應對突發流量的能力，其目標在於無需容量規劃，透過指標監控

配合極致彈效能力實現應用資源的近乎按需使用且整個過程服務可用。SAE 透過對彈性元件和應用全生命週期的不斷最佳化以達到秒級彈性，並在彈效能力，場景豐富度，穩定性上具備核心競爭力，是傳統應用 0 改造上 Serverless的最佳選擇。