來源|阿里巴巴云原生公眾號

作者 |炎尋 阿里云 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 的下一個時代。

總結

以上是生活随笔為你收集整理的阿里云在应用扩缩容下遇到的挑战与选型思考的全部內容，希望文章能夠幫你解決所遇到的問題。

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