作者：競霄

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 作為云計算的最佳實踐、云原生發展的方向和未來演進趨勢，其核心價值在于快速交付、智能彈性、更低成本。

在時代背景下，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 的最佳選擇。

總結

以上是生活随笔為你收集整理的云原生体系下 Serverless 弹性探索与实践的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。