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的技術架構如圖所示，上層runtime分為網關路由，應用生命週期管理與商業化，鏡像構建，定時任務，集群代理等多個模塊。底層infra為多租Kubernetes，使用神龍裸金屬安全容器、VK對接ECI兩種方式提供集群計算資源。用戶在SAE中運行的應用會映射到Kubernetes中相應的資源。其中多租能力是藉助系統隔離、數據隔離、服務隔離和網絡隔離實現租戶間的隔離。
彈性的競爭力主要在於場景豐富度，效率，穩定性的競爭力，先講一下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 的最佳選擇。
