作者 |炎尋 阿里雲 EDAS 核心開發工程師；Andy Shi 阿里雲技術佈道師
來源 | 阿里巴巴雲原生公衆號
導讀：在雲原生技術棧逐漸普及之後，如何能夠以效率更高、用戶更容易接納的方式落地 Kubernetes 技術體系，讓雲原生的發揮出真正的價值，正在迅速成爲大家津津樂道的一個話題和全新的挑戰。而伴隨着大家對雲原技術的關注點從“怎麼用”逐漸上升到“怎麼用的更好’上來，CNCF 應用交付領域小組（CNCF SIG App Delivery）聯合阿里巴巴雲原生應用平臺團隊推出了《從 0 到 1：打造現代雲原生應用管理平臺》系列文章，旨在幫助讀者更好的落地和實踐雲原生核心技術，打造出屬於自己的、“以應用爲中心”的 Kubernetes 平臺。
背景與場景
阿里雲企業級分佈式應用服務 EDAS（Enterprise Distributed Application Service）是一個應用全生命週期管理和監控的一站式 PaaS 平臺，同時也是 Open Application Model (OAM) 模型在公有云上的第一個互聯網級商用平臺層實現。今天，EDAS 的應用管理層內核已經完全基於 KubeVela 開源項目構建於原生的 Kubernetes 集羣之上，以高效、穩定、智能、可擴展的方式服務了成千上萬名雲上應用開發者。在本文中，我們會以 EDAS 的底層技術實現作爲具體案例，介紹阿里雲在生產環境中設計與落地智能化的應用擴縮容策略中踩到的“坑”、解決方案以及構建以雲原生應用平臺過程中的最佳實踐。
阿里雲進行應用擴縮容遇到的挑戰與選型思考
作爲阿里雲面向應用管理與交付領域的核心產品，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 的企業級用戶非常迫切需要的一個能力。同樣的，對於這個應用運維能力的訴求，也必須是獨立的原子性能力，而不能爲了一個需求引入一整套其它的平臺級方案進來。
基於上述問題，阿里雲團隊開始規劃 EDAS 產品自動彈性伸縮能力的新版本。而與此同時，EDAS 產品底層架構自 2020 年初也開始了基於 Open Application Model （OAM）的一系列演進升級，旨在通過引入一個標準化、可插拔的應用定義模型替代 EDAS 原有的 Application CRD，從而既爲使用者提供一個以“應用爲中心”的上層抽象而不是強制用戶學習 Kubernetes 中的底層概念，又利用模型的可擴展性確保 EDAS 能夠將雲原生生態中的各種能力一鍵“插入”到產品當中。所以，這個新版自動彈性伸縮組件的設計與實現，也自然而然的同 EDAS 的 OAM 化架構結合在了一起。
在這個新的架構中，一個應用的“自動彈性伸縮”策略，是作爲這個應用的“特徵”（Trait）存在的。當然，這裏提到的“應用”這個概念，是 EDAS 在 Kubernetes 之上藉助 OAM 爲用戶暴露出來的一個上層抽象，並且完全通過用戶側的原語進行描述。所以，這裏的問題就出現了，在 Kubernetes 具體的實現層，這種用戶定義的、面向應用的彈性伸縮策略，又該如何實現或者選型呢？
結合前面提到的三個具體的挑戰，以及新版 EDAS 基於 OAM 的 Kubernetes 原生化設計，阿里雲團隊決定直接從開源社區中來引入一個水平擴縮容組件來解決上述問題，並且針對 EDAS 的場景提煉出了三點主要的選型訴求：
- 這個水平擴縮容組件提供的應該是簡單穩定的原子化能力，而不能跟某個具體的場景化方案（比如 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 的下一個時代。