來源|阿里巴巴雲原生公衆號 
做者 |炎尋 阿里雲 EDAS 核心開發工程師Andy Shi 阿里雲技術佈道師git
導讀：在雲原生技術棧逐漸普及以後，如何可以以效率更高、用戶更容易接納的方式落地 Kubernetes 技術體系，讓雲原生的發揮出真正的價值，正在迅速成爲你們津津樂道的一個話題和全新的挑戰。而伴隨着你們對雲原技術的關注點從「怎麼用」逐漸上升到「怎麼用的更好’上來，CNCF 應用交付領域小組（CNCF SIG App Delivery）聯合阿里巴巴雲原生應用平臺團隊推出了《從 0 到 1：打造現代雲原生應用管理平臺》系列文章，旨在幫助讀者更好的落地和實踐雲原生核心技術，打造出屬於本身的、「以應用爲中心」的 Kubernetes 平臺。github
背景與場景
阿里雲企業級分佈式應用服務 EDAS（Enterprise Distributed Application Service）是一個應用全生命週期管理和監控的一站式 PaaS 平臺，同時也是 Open Application Model (OAM) 模型在公有云上的第一個互聯網級商用平臺層實現。今天，EDAS 的應用管理層內核已經徹底基於 KubeVela 開源項目構建於原生的 Kubernetes 集羣之上，以高效、穩定、智能、可擴展的方式服務了成千上萬名雲上應用開發者。在本文中，咱們會以 EDAS 的底層技術實現做爲具體案例，介紹阿里雲在生產環境中設計與落地智能化的應用擴縮容策略中踩到的「坑」、解決方案以及構建以雲原生應用平臺過程當中的最佳實踐。web
阿里雲進行應用擴縮容遇到的挑戰與選型思考
做爲阿里雲面向應用管理與交付領域的核心產品，EDAS 較早就已經完成了從自研虛擬機架構到 Kubernetes 容器集羣的架構總體遷移。固然，同大多數基於 Kubernetes 的 PaaS 相似，在這個階段，EDAS 在應用自動彈性伸縮功能上，是徹底基於 Kubernetes 原生 HPA（Horizontal Pod Autoscaler）提供的 CPU 和 Memory 兩個基礎指標的。可是，隨着用戶量的增長和需求的日漸多樣化，原生基於 HPA 的應用擴縮容策略逐漸暴露出了不少不足之處：數據庫
- 第一，對基於細粒度的應用級負載指標（好比：RT 或者 QPS）進行自動擴縮支持不佳。
做爲一個「 The Platform for Platform」項目，Kubernetes 提供的內置能力主要是圍繞着容器級別的管理和編排來展開的，可是對於以應用和用戶爲核心關注點的產品來講，像 CPU 和 Memory 這樣粒度的擴縮容指標就顯得太粗粒度了。可是一個「尷尬」的局面是，儘管 HPA 提供了必定程度的自定義指標功能，但它的可擴展性總體上仍是不夠靈活，自定義指標的可插拔性也不是很好，尤爲是當咱們但願把指標細化到應用甚至源碼層面的時候，常常會碰到須要修改 HPA 代碼的狀況（而 HPA 代碼又是 Kubernetes 代碼的一部分）。這就迫切的須要咱們在思考如何經過一個擴展性更強的、外部框架來進行細粒度的應用擴縮容策略。架構
- 第二，沒法支持對應用 Scale To Zero的需求。
咱們知道，在 Serverless/FaaS 場景中 Scale To Zero 是一個比較典型的自動伸縮場景，能夠有效的幫助用戶節省閒置資源、下降平臺的使用成本。實際上， 現代微服務應用中，不少用戶託管在雲上的微服務，也都具有 Serverless 應用的一些特徵，好比無狀態、主要根據流量進行響應等等，對於它們來講，Scale To Zero 也是一個很是重要的訴求。可是，Kubernetes 內置的 HPA 並不關注這個場景，是不會提供出這個能力的。而 EDAS 做爲一個全功能通用 PaaS 產品，對 Scale To Zero 的訴求是獨立的、無平臺鎖定的原子性能力，不可能經過引入 OpenFaaS 或者 Knative 這樣的 Serverless 專屬方案來解決全部用戶場景下的問題。框架
- 第三，沒法支持定時擴縮容的需求。
除了 Scale To Zero 以外，定時擴縮容也是 EDAS 的企業級用戶很是迫切須要的一個能力。一樣的，對於這個應用運維能力的訴求，也必須是獨立的原子性能力，而不能爲了一個需求引入一整套其它的平臺級方案進來。less
基於上述問題，阿里雲團隊開始規劃 EDAS 產品自動彈性伸縮能力的新版本。而與此同時，EDAS 產品底層架構自 2020 年初也開始了基於 Open Application Model （OAM）的一系列演進升級，旨在經過引入一個標準化、可插拔的應用定義模型替代 EDAS 原有的 Application CRD，從而既爲使用者提供一個以「應用爲中心」的上層抽象而不是強制用戶學習 Kubernetes 中的底層概念，又利用模型的可擴展性確保 EDAS 可以將雲原生生態中的各類能力一鍵「插入」到產品當中。因此，這個新版自動彈性伸縮組件的設計與實現，也天然而然的同 EDAS 的 OAM 化架構結合在了一塊兒。運維
在這個新的架構中，一個應用的「自動彈性伸縮」策略，是做爲這個應用的「特徵」（Trait）存在的。固然，這裏提到的「應用」這個概念，是 EDAS 在 Kubernetes 之上藉助 OAM 爲用戶暴露出來的一個上層抽象，而且徹底經過用戶側的原語進行描述。因此，這裏的問題就出現了，在 Kubernetes 具體的實現層，這種用戶定義的、面向應用的彈性伸縮策略，又該如何實現或者選型呢？分佈式
結合前面提到的三個具體的挑戰，以及新版 EDAS 基於 OAM 的 Kubernetes 原生化設計，阿里雲團隊決定直接從開源社區中來引入一個水平擴縮容組件來解決上述問題，而且針對 EDAS 的場景提煉出了三點主要的選型訴求：ide
- 這個水平擴縮容組件提供的應該是簡單穩定的原子化能力，而不能跟某個具體的場景化方案（好比 Serverless）綁定。這同時也是 OAM 模型對「應用特徵」的基本規範和要求；
- 這個水平擴縮容組件的擴容指標應該是插件式的，這樣阿里雲團隊纔可以方便得擴展出基於定時、消息隊列堆積消息數、應用監控指標甚至 AI 預測結果的「以應用爲中心」的彈性策略；
- 原生支持 Scale To Zero，而且知足第一條的要求。
而通過在社區中的評估和選型，最後阿里雲團隊選擇了微軟開源 KEDA 項目，它目前已經移交給 CNCF 託管。KEDA 項目能夠原生支持 Scale To Zero，更重要的是，它針對應用級水平擴縮容，解耦了被伸縮對象和伸縮指標，並分別提出了對應的抽象接口（ Scaler + Metrics Adapter 機制），從而即提供了強大的插件機制，又可以爲全部擴縮策略提供一層統一的定義方式。此外，KEDA 的設計和架構比較簡，沒有很複雜的黑科技存在，內置的不少 Scaler 能夠直接使用，很是符合 EDAS 產品的總體訴求。
EDAS 基於 OAM 和 KEDA 的雲原生 PaaS 架構
在技術架構上，阿里雲 EDAS 產品內核是基於 OAM 社區的 KubeVela 開源項目構建的。正是藉助了 OAM 提供的 Kubernetes 原生的擴展機制，在上線像 KEDA 這樣來自雲原生開源社區的能力時，EDAS 產品研發團隊並不須要像傳統 PaaS 團隊那樣進行大量的二次開發甚至修改用戶側 API，而只須要將 KEDA 的 CRD 按照 OAM 規範「註冊」成爲 EDAS 的一個 Autoscale Trait，完成監控數據對接，用戶便可使用到這個新增的水平擴容能力。總體架構能夠用以下所示的示意圖表示清楚：
在具體實現中，EDAS 主要藉助阿里雲的 ARMS 服務提供的細粒度的應用級監控數據，來驅動 KEDA 對工做負載進行快速的水平擴容。而除了在 KEDA 中增長了 ARMS Scaler 外，EDAS 對 KEDA v1 Release 中存在的問題也進行了不少修復或者加強，包括：
- 多個同類型的 Trigger 的指標值會被相加而不是獨立計算致使容量值計算有誤；
- KEDA 在建立 HPA 時，名字若是超長則會被簡單地 Trim 到 63 字符，沒有檢查是否符合 DNS 規則，致使有時報錯；
- Trigger 不能被禁用，這在生產環境下會有穩定性風險；
上述修復，EDAS 團隊已經提交或者正在提交至 KEDA 上游中，其中有一部分已經在 KEDA v2 Release 中獲得了修復。
此外，Kubernetes 中還有一個困擾了你們好久的問題就是自動擴容和灰度發佈在不少時候會發生衝突。針對這個問題， EDAS 藉助 OAM 的模型層語義對這兩個能力進行了互斥處理。
當前工做與將來計劃
在目前工做的基礎上，EDAS 正在與開源社區合做，爲基於 KEDA 的 Autoscaler Trait 增長不少新的能力，這包括：
- Trigger 支持禁用功能；
- 提供 Decider 抽象，可以以擴展的方式，在擴容的過程當中加入更多的決策邏輯；
- 支持 Dry Run 功能；
- 支持容量變動的灰度，回滾，觀測功能；
- 支持 Webhook 通知；
而在將來，EDAS 的主要工做重點會專一於如何在當前的架構上同 EDAS 的 AIOps 能力結合，從而爲整個平臺引入更加智能的彈性體驗，這包括：
1. 更智能的決策機制
- 結合上下游應用狀態綜合決策
- 結合自適應限流綜合決策
- 結合專家系統，根據封網期，大促態的規則綜合決策
- 結合歷史數據分析綜合決策
- 提供容量診斷並自動推薦擴縮策略
2. 更可控的擴縮容過程
- 提供 webhook 在擴縮變動時發送通知
- 提供交互在人工確認後才進行擴縮變動操做
- 提供擴縮變動過程的灰度，回滾，觀測功能
- 提供 Dry Run 功能
3. 更豐富的觸發器體系
- 應用 QoS 觸發器
- 數據庫指標觸發器
- 消息隊列指標觸發
在接下來的發佈中，這些基於 KEDA 的創新與加強，很快就可以爲 EDAS 的用戶帶來更增強大、智能、穩定的應用自動彈性能力與更加友好的使用體驗。
總結
本文主要以 EDAS 的智能彈性伸縮能力爲切入點，介紹了阿里雲企業級應用平臺在經典 PaaS 場景下依託 OAM 和 KubeVela 項目爲底座，支持 KEDA 水平擴縮容組件的過程當中遇到的挑戰和解決辦法。後續，這套基於 KEDA 的應用特徵會集成更普遍的擴縮容指標和更智能的決策機制。
而在同雲原生生態共同演進的同時，阿里雲 EDAS 服務在雲原生應用管理領域的大規模實踐，也爲 OAM 社區帶來了應用版本化、依賴管理、運維特徵交互與批量下發機制等大量生產級加強，以及豐富的最佳實踐和經驗教訓。也正是得益於標準與開放的產品架構，阿里雲 EDAS 服務纔可以迅速的同 KEDA 等雲原生社區「新勢力」打成一片，以標準化、可擴展的方式，快速的爲用戶上線強大的、源自開源社區的各類應用管理能力，真正作到了「以用戶爲中心」來作技術創新與演進，正式邁向雲原生應用 PaaS 的下一個時代。