分享人｜競霄
直播位址：
0 基礎晉級 Serverless 高手課 — 雲原生體系下 Serverless 彈性探索與實踐 本篇内容将從四個部分為大家介紹雲原生體系下Serverless彈性探索與實踐。- Serverless時代的來臨
- Serverless彈性探索
- Serverless彈性落地
- Serverless彈性最佳實踐
一、Serverless時代的來臨
Serverless顧名思義是一種無伺服器的架構，是雲計算時代的一種架構模式。Serverless架構能夠讓開發者在架構應用的過程中無需關注計算資源的擷取和運維，進而降低運維成本，縮短上線的時間。
在Serverless架構下，開發者隻需要關注上層的業務邏輯開發，而如Server的資源申請、環境搭建、負載均衡、擴縮容、監控、日志、告警、容災、安全和權限等，都可以交給Serverless平台來關注。
1. Serverless的4大特性
在雲原生架構白皮書中對Serverless的特性有4點概況，分别是：
- 全托管的計算服務，意味着使用者隻需要編寫代碼來建構業務應用，而無需關注同質化的、複雜繁重的、基于伺服器的開發和運維。
- 通用性，是指Serverless支援所有應用的類型。
- 自動的彈性伸縮，即使用者無需為資源進行預先的容量規劃，
- 按量計費，可以将企業的使用成本降低，讓企業無需為閑置的資源付費。
2. Serverless的發展曆史
2012年首次提出Serverless概念作為Serverless發展的起點，到2014年AWS推出Lambda雲産品，這段時間内是Serverless關注度最高的階段，出現了爆發式的增長，對無伺服器的期待和暢想引爆了整個IT行業。
但是Serverless的推廣和生産落地是不容樂觀的，因為Serverless的理念和實操存在Gap，挑戰着人們固有的認知和運維習慣。而阿裡雲堅信Serverless将作為雲原生之後非常确信的發展方向，是以相應的推出了阿裡雲函數計算FC和阿裡雲SAE
Serverless應用引擎兩款雲産品，來覆寫不同的使用者負載類型來使用Serverless技術，并且不斷的推進Serverless理念的普及和發展。
3. Serverless市場概況
基于Forrester Wave FaaS 2021第一季度的調研顯示，阿裡雲Serverless産品能力在整個Serverless市場領域，中國排名第一并且全球領先。另外，信通院2020年中國雲原生使用者調查報告顯示，阿裡雲Serverless使用者占比中國第一，占比比例高達66%，其中35%是阿裡雲函數計算FC的産品占比，而阿裡雲SAE的占比高達31%。同樣通過這個報告顯示，Serverless技術已經被廣泛使用到企業的核心業務應用中，包括“已在核心業務應用”、“已在非核心業務應用”、“已在測試環境應用“三種情況占比30%，另外有11%的企業正在研究和學習環境應用。
二、Serverless彈性探索
彈性能力作為雲的核心能力之一，它所關注的是容量規劃和實際叢集負載之間的沖突。
如下圖對比可見，如果使用左側原來采取的預先規劃資源的方式，會産生規劃資源和實際使用資源不比對的情況，并造成資源浪費或資源不足的情況，進而使企業的成本增加和浪費。而右側極緻彈性能力，是資源使用量與實際需求量幾乎保持一緻，是按需比對的。這樣可以使資源的整體使用率提高，同時避免了資源的浪費，為企業節省了不必要的成本。
彈性能力可以分為可伸縮性和故障容忍性兩個部分。可伸縮性是指底層資源可以按照上層名額變化而具有一定的自适應能力。相當于IaaS可以随着流量的增加而相應的增加，反之亦然。故障容忍性是指通過彈性自愈來保證服務和執行個體處于持續健康的狀态，以保持整體的高可用。
以上兩種彈性能力帶來的價值收益在于降低成本的同時可以提升應用的可用性。一方面，資源使用量貼合應用實際消耗量；另一方面，提升峰值的應用可用性，勁兒靈活适應市場的不斷發展和變化。
1. 彈性探索：IaaS彈性伸縮
IaaS彈性伸縮的代表産品是各個雲廠商的雲産品，如阿裡雲的彈性伸縮ess。它的整體使用是通過配置雲監控，也是阿裡雲的監控服務，通過雲監控的報警規則來出發相應的ecs的增減操作。如當ecs執行個體整體的CPU大于80%的時候，會相應增加ecs執行個體；當小于30%的時候，也會相應減少。同時支援動态增減slb後端伺服器組。這樣可以保證整體架構的穩定性。
Ecs作為IaaS的基本機關，彈性伸縮能力使其能夠伸縮規則自動增減，并提供健康檢查功能實作彈性自愈能力。
使用者的使用流程是：
- 建立伸縮和伸縮配置（彈性伸縮的基本機關為相同應用場景的ecs執行個體的集合及關聯slb和rds）
- 建立伸縮規則（基于定時任務/告警任務實作，具體分為簡單規則、進步規則、目标追蹤規則和預測規則）
- 監控檢視彈性執行情況
2. 彈性探索：kubernetes彈性伸縮（水準）
Kubernetes水準彈性伸縮代表産品是原生的k8s hpa以及所對應的托管雲産品，比如阿裡雲的容積服務。k8s作為面向應用運維的基礎設施和Platform for Platform，提供的内置能力主要是圍繞着容器級别的管理和編排來展開的，而彈性能力聚焦于對底層pod的動态水準伸縮。它的原理是k8s hpa允許pod中監控資料，并将它們與對應的期望值做比較，然後通過内置算法來算出期望的目标實際數，然後再來指導操控對應的工作負載，來改變實際數實作不斷進行彈性伸縮的流程。
使用者的使用流程是：首先建立workload，然後建立hpa（配置名額源和彈性政策），再然後事件檢視彈性執行情況。
3. 彈性探索：應用畫像彈性伸縮
應用畫像彈性伸縮主要是應用于網際網路公司内部，比如阿裡的容量平台。容量平台提供容量預測服務和容量變更決策服務。如下圖所示，它會預先通過odps大資料能力，對這個有應用的監控名額資料和實際資料進行預處理，然後生成應用的畫像資料，這裡畫像分為基準畫像、彈性畫像和大促畫像，再然後通過容量平台進行變更管控、故障熔斷和畫像準入等。具體的容量平台執行vpa的具體操作，然後再指導具體的odps不斷的學習。這樣就形成了一個閉環的操作。
使用者使用流程是：
- 應用接入
- 生成容量畫像（基于曆史資料/經驗，生成大促畫像、彈性畫像和基準畫像）
- Metrics名額修正畫像
- 監控檢視彈性執行情況
通過上面的介紹可以看到，應用畫像彈性伸縮和前兩種的彈性伸縮差别比較大，它是以畫像驅動為主、Matric驅動為輔的一種彈性伸縮能力。它的目标是不斷修正使用者畫像，進而使使用者畫像不斷的來與實際情況吻合。
4. 彈性探索：彈性模式對比
三種彈性産品從彈性伸縮功能模式上抽象來講基本相同，都是由觸發源、彈性決策和觸發動作組成的。
觸發源，一般依賴于外部的監控系統，它可以對節點名額和應用名額進行采集處理；彈性決策一般基于周期性輪詢并算法決策，有部分基于曆史資料分析預測以及使用者的定時政策。觸發動作是對執行個體進行水準擴縮，并提供變更記錄于對外通知。
在此基礎上做場景豐富度、效率、穩定性的競争力，并通過可觀測的能力提升彈性系統的透明度，便于問題排查和指飛彈性優化，同時提升使用者的使用體驗和粘性。
以上是三個彈性産品的相同點，下面來介紹下不同點。
IaaS彈性伸縮作為老牌的彈性伸縮能力，沉澱時間長、功能強大且豐富。但是雲廠商間能力區域同質化，而且與各個雲廠商的IaaS産品強綁定，彈性效率相較容器受限。
Kubernates彈性伸縮，作為開源産品通過社群力量不斷優化疊代，彈性能力和最佳實踐更符合絕大部分開發運維人員的訴求。但是它需要對于彈性行為和api進行高度抽象，可擴充性不強，無法啊支援自定義的需求。
應用畫像彈性伸縮，是阿裡巴巴集團内部的特色産品，可以根據集團應用現場和彈性訴求進行設計，更聚焦于資源池預算成本優化、縮容風險和複雜度等痛點。缺點是不易拷貝擴充，特别對外部中小客戶不适用。
從終态目标來看，可以看出公有雲和網際網路企業的發展方向不同：
網際網路企業往往由于其内部應用具有顯著流量特征，應用啟動以來多、速度慢，且對整體資源池容量水位、庫存财務管理、離線上混部有組織上的諸多訴求，因而更多的是以容量畫像提前彈性擴容為主，基于Metrics計算的容量資料作為實時修正，其目标是容量畫像足夠精準以至于資源使用率達到預期目标。
公有雲廠商服務于外部客戶，提供更為通用且具有普适能力，并通過可拓展性滿足不同使用者的差異化需求。尤其是在Serverless場景，更強調應用應對突發流量的能力，其目标在于無需容量規劃，通過名額監控配合極緻彈性能力實作應用資源的近乎按需使用且整個過程服務可用。
三、Serverless彈性落地
1. Serverless應用引擎簡介
Serverless應用引擎實作了Serverless架構+微服務的完美結合，支援多種微服務架構、多種部署管道（UI、Jenkins/雲效、插件等）、多種部署方式（war、jar、鏡像），核心場景主要面向線上應用：微服務應用、web應用和多語言應用。
Serverless作為雲計算的最佳實踐、雲原生的發展方向和未來的演進趨勢，它的核心價值在于快速互動、智能彈性和更低成本。在這個背景下SAE就應運而生了。
SAE是首款面向應用的Serverless平台，支援Spring Cloud、Dubbo、HSF、web等主流應用開發架構。使用者可以零改動将應用部署到架構上，并且是按需使用按量計費的機制。當下是按照CPU Memory來進行按量計費的，可以充分發揮Serverless的優勢，為使用者節省閑置資源成本。同時體驗上采用了免運維的方式，使用者隻需要聚焦于核心業務邏輯開發上，無需關注如有應用生命周期管理、微服務管理、日志、監控等等運維層面。
下圖是使用者視角的SAE架構圖，通過此圖可以看到，它支援各種應用類型。
SAE後端分為兩層，上層是應用管理層，有應用生命周期管理、多釋出政策、彈性伸縮、應用監控、一鍵啟停和Dragonwell；下層是微服務治理層，包括服務注冊發現、配置管理、負載均衡、優雅下線、限流降級和服務安全等。
底層是平台提供的Kubernetes叢集，SAE給使用者部署的應用實際就是映射到k8s中的對應資源裡。SAE的多組能力是通過系統隔離、資料隔離、網絡隔離和服務隔離等一系列隔離來實作的。為的就是讓多個使用者跑在一個k8s上。
2. 彈性效率：分析
對SAE應用的整個生命周期進行資料化統計和可視化分析，可以看一下下圖最上面的整體應用啟動。也就是pod建立分為幾個流程：
首先是排程，即把某個應用調到某個具體的node上；
然後是init container建立，比如監控元件通過init container進行預拉取，然後再進行部署；
其次是拉取使用者鏡像、建立使用者容器、啟動使用者容器&應用和應用運作。
通過上圖不同流程對應的顔色條的長短，可以看到不同流程環節所用耗時的長短。顯而易見，應用建立耗時集中在三個環節：排程、拉取使用者鏡像和應用冷啟動。
- 排程，目前會執行打通使用者VPC操作，由于該步驟強耦合于排程，本身耗時比較長且存在建立時間長尾逾時、失敗重試等情況，導緻排程鍊路整體耗時比較長。
- 拉取使用者鏡像與解壓鏡像的時長，特别是在大容量鏡像的部署情況下尤為突出。
- 應用冷啟動，由于SAE存在大量單體和微服務的Java應用，Java類型應用往往啟動依賴比較多，加載配置慢，初始化過程長，導緻冷啟動速度達到分鐘級。
以上三個耗時長的環節，是否有可能優化或跳過排程階段、拉取使用者鏡像使用緩存和避免冷啟動流程呢？針對這幾個問題，有如下解答。
3. 彈性效率：原地更新
SAE在初期采用滾動更新政策，即新創pod後銷毀老pod，以這種+1和-1方式進行更新。而原地更新，是隻更新pod中一個或多個容器版本，而不影響整個對象對于容器的更新。對比滾動更新來看，原地更新的pod還是原來的pod不變，隻是将内部某個container的鏡像給換了。
通過原地更新的能力，給SAE帶來了諸多價值，其中最主要的就是避免了能力重建，進而使整個部署耗時從原來整個pod的生命周期，縮短到現在隻需要拉取、建立和啟動使用者容器，彈性效率提升了42%。
同時因為無需排程，是以可以實作預先在Node上緩存鏡像，提高彈性效率；也可以保持IP不變，避免因IP變化導緻依賴元件如注冊中心感覺延遲；最後可以減少重建Pod對排程器、注冊中心和業務上下遊的壓力。
一方面借助阿裡開源OpenKruise原地更新的能力提升應用整體部署效率；另外一方面将雲産品SAE實踐經驗回饋開源，共同打造通用标準的無狀态應用負載的大規模使用實踐。
4. 彈性效率：鏡像預熱
鏡像預熱包括兩種形式，一個是排程前預熱，一個是排程中預熱。排程前預熱SAE會對基礎鏡像進行混村，即每個節點對于基礎鏡像都已完成預拉取，這樣就避免了從遠端拉取。另外對于分批場景，在原地更新能力的基礎上，可以在排程中進行運作。因為原地更新node是不變的，在第一批部署之後，餘下的幾批是在那個節點上就直接在那個節點上拉取鏡像，這樣在部署這個節點的時候可以做到預拉取，進而實作拉取使用者鏡像和排程，這其實是并行的措施，可以通過這個技術将彈性效率提升30%。
5. 彈性效率：鏡像加速
鏡像加速是解壓鏡像。傳統容器運作中需要将全量的計劃進行下載下傳後後再解壓。然而容器啟動中實際上往往隻需要一部分内容，不需要全量拉取，這就導緻容器的啟動耗時比較長。
标準鏡像采用的是tar.gz格式，無法随機讀取。鏡像加速功能實際上是将鏡像自動轉化為一個加速鏡像，即帶自定義索引支援随機讀取的鏡像。然後這樣就可以實作整個鏡像的按需加載和線上解壓了，這樣就大幅度的提升了應用的分發效率。同時借助acr内部倉庫的P2P鏡像分發能力，實作無需從遠端而是通過使用者自己的節點進行啊去鏡像，這就大大提升了整體的效率。
6. 彈性效率：Dragonwell 11
對于Java應用冷啟動慢的痛點，SAE聯合了Dragonwell 11增強了CDS使用加速政策。阿裡巴巴Dragonwell 11是一個Java gdk的開源版本，它對原有的open gdk進行了增強。
首先介紹一下什麼是AppCDS，它的全稱是App Class Data Sharing，即資料共享機制。通過這個技術，可以擷取到應用啟動過程中依賴的Class list，并把它當成一個共享檔案，這樣在下次啟動時候可以通過這個共享檔案來完成。
映射到SAE部署場景，應用啟動初次是需要啟動一遍，然後就會生成對應的緩存檔案，緩存檔案儲存在NAS中，然後在下一批或是重新開機應用的時候就可以用這個緩存檔案了。借助這個方式，整體的冷啟動效率可以提升45%。
7. 彈性效率：自動擴縮
上面介紹了應用的生命周期優化，這裡再介紹下對于彈性元件的自動擴縮進行優化。整個彈性伸縮包括了幾個步驟，首先是彈性名額擷取，其次是彈性決策，最後是執行擴縮操作，即POD建立。
基于此，彈性元件自動擴縮進行了哪些優化呢？
首先是流量透明攔截方案。對于四層名額已經達到了秒級；對于七層名額，借助流量透明攔截方案來實作七層名額的秒級擷取。同時，對于彈性決策，采用了多隊列并發reconcile，實時監控堆積，延時情況來實作整個自動擴縮的可決策。
8. 彈性能力：架構
下面介紹一下SAE整體的彈性能力。
SAE彈性伸縮包括強大的名額矩陣政策配置以及完善的通知告警機制和全方位觀測能力，支援多種資料源，通過資料源提供的監控或應用監控名額，都可以作為彈性伸縮的輸入。
對于彈性元件進行拉取或是預處理之後執行具體的彈性政策。彈性政策也有很多種，比如整體快擴快縮，或是隻擴不縮，自适應伸縮等等。
除了伸縮彈性政策還有自定義的精細彈性配置。自定義驚喜彈性配置是指，可以在整體的上下限最大和最小配置值，以相應名額區間維持穩定狀态。或是直接大于某個區間上限再擴，低于某個區間的下限再縮等等。
采集周期和聚合邏輯，支援定時政策。通過彈性配置政策和自定義的彈性配置，就會觸發具體的彈性行為。在執行動态切流來保證整體的彈性過程中所有執行個體通路狀态都是正确的，以及後面的伸縮通過告警能力能夠把伸縮情況通知到具體的負責人。全方位觀測能力對于整體的決策時間、決策上下文所用記錄等等，都可以實作可監控。
上述的彈性能力，支援多個場景。下圖所列的四個常用場景分别是：定時彈性、名額彈性、符合彈性和自身彈性。
定時彈性：
定時彈性比較适用于應用負載流量周期比較固定的情況，使用者可以預先按時間和日期配置應用。定時彈性多應用于傳統的行業，如證券、醫療、政府或是教育等。
名額彈性：
名額彈性可以配置名額值，然後會使整個應用的名額穩定在使用者配置的名額值規則内，并且預設采用快速方式來保證整體的穩定性。名額彈性适用于徒增流量的情況，多用于網際網路、遊戲或是社交等行業。
混合彈性：
混合彈性是把上述的定時彈性和名額彈性結合，可以配置不同時間、日期等名額規則，可更加靈活應對複雜場景需求。混合彈性多使用者網際網路、教育或是餐飲行業。同時，對于初通流量的場景，
自适應彈性：
SAE針對流量場景進行優化，然後内部有一個流量增長視窗來不斷檢測目前流量激增的情況的，它的激增強烈程度如何，然後可以根據強烈程度執行自适應彈性擴縮，并且在原有算法過多的行為中會增加一定的備援來實作擴縮的效果。
9. 彈性能力：穩定性
穩定性是SAE彈性能力過程中非常重要的一環。它可以保證使用者應用在彈性過程中可以按照預期行為進行擴縮，并且保證整個過程的穩定性。SAE彈性伸縮整體遵循了快擴慢縮的原則，通過多級平滑防抖來保證執行的整體穩定性，同時對于這個名額激增的場景借助自适應能力提前實作擴容。
下圖是整體的四級平滑機制。一級平滑是對名額的擷取周期及每次擷取請求的時間視窗和時間視窗内資料的聚合邏輯，都可以進行精細化的控制。二級平滑可以對名額容忍區間的容忍彈性進行配置，也就是區間内不擴不縮。三級平滑可以對機關時間内的擴縮步長、比例和上下限進行配置。四級平滑是可以對冷卻時間和預熱時間進行配置。
四、Serverless彈性最佳實踐
1. 彈性伸縮準備階段
SAE彈性伸縮可以有效解決剩餘流量波峰波谷到來的自動伸縮。首先建議配置應用的監控檢查和應用生命周期管理，這樣可以保證擴縮工作的過程中整體的應用可能性，確定應用啟動。應用生命周期管理，可以配置上下限，比如執行縮容時，應用可能需要執行一些操作，可以通過生命周期管理的對應的接口配置對應的腳本來執行。為避免因彈性不及時，應用啟動不及時或應用沒有優雅上下線導緻服務調用異常，建議采用指數重置機制進行服務調試。
應用啟動速度優化，在阿裡内部來講，這是平台為使用者提供的一些優化手段。作為使用者也可以對應用進行啟動優化，其中最重要的是對軟體包的優化，比如優化啟動時間，減少因類加載、緩存等外部依賴導緻的應用啟動過長。
2. 彈性伸縮配置階段
彈性伸縮名額配置比較靈活，支援非常多的名額，如CPU、記憶體、IO等等。需要根據整個應用的名額屬性，是CPU敏感還是IO敏感等，進行一個靈活的選擇。然後可以通過技術監控或是應用監控它的曆史名額來預估整體的容量負載情況，來了解應用可以抗住多少請求，或是抗住多少CPU記憶體，以及高負載的情況下，這個應用會有怎樣的異常。
另外，因為應用系統比較複雜，它不是單時間而是多系統寫作的過程。當一個實數擴的時候會影像上下遊，是以建議梳理整個上下遊的相關依賴，并配置相應的彈性規則，來確定整個鍊路都是能夠保證可能性的。在配置彈性工作之後，也可以通過晚上可觀測手段來不斷調試彈性配置。
名額配置這裡有個建議，最大值建議考慮每個可能區對應IP是否有沖突，否則就擴不出來了；最小值建議不要保持單執行個體，建議大于二且配置多個可能區，這樣防止某個可能區域有問題，可以遷移到另外一個可能區或是執行個體。
3. 彈性伸縮過程
在整體彈性伸縮過程中需要注意幾個點，比如彈性伸縮是否達到最大值，這個最大值意味着一方面流量預估可能不準，或是最大值配置有問題，也有可能是應用出現了異常，或可能區分布不均衡。可以通過重新開機來實作可能區的均衡，然後自動回複彈性配置。
4. 彈性伸縮可觀測
彈性伸縮可觀測是對彈性曆史記錄進行觀測，或是對于彈性實踐進行通知。實際上是一種内部報表。
從下圖的内部報表可以看到包括Hpa的配置和整體每一次請求的間隔，還有具體的耗時等等資訊，在彈性伸縮可觀測報表裡都很清楚。
對外，阿裡也在不斷完善這個報表的開發。
上述就是使用者從彈性伸縮的最佳實踐介紹。