**來源 | **[**阿里巴巴雲原生公眾號**](http://mp.weixin.qq.com/s?__biz=MzUzNzYxNjAzMg==&mid=2247496814&idx=1&sn=d71fd0ad8d655488d3c82a7dd2c9b30c&chksm=fae6ffa1cd9176b71d0a5fd47c1cf949e6e2a942ab6da4af26e3b9c6288da370ce147c0701c6&token=1578756645&lang=zh_CN#rd)
![頭圖.png](https://ucc.alicdn.com/pic/developer-ecology/a80cbf5b7408408d822e91e0c9c27498.png)
作者 |炎尋  阿里雲 EDAS 核心開發工程師Andy Shi  阿里雲技術佈道師

> **導讀**：在雲原生技術棧逐漸普及之後，如何能夠以效率更高、使用者更容易接納的方式落地 Kubernetes 技術體系，讓雲原生的發揮出真正的價值，正在迅速成為大家津津樂道的一個話題和全新的挑戰。而伴隨著大家對雲原技術的關注點從“怎麼用”逐漸上升到“怎麼用的更好’上來，CNCF 應用交付領域小組（CNCF SIG App Delivery）聯合阿里巴巴雲原生應用平臺團隊推出了《從 0 到 1：打造現代雲原生應用管理平臺》系列文章，旨在幫助讀者更好的落地和實踐雲原生核心技術，打造出屬於自己的、“以應用為中心”的 Kubernetes 平臺。

# 背景與場景

阿里雲企業級分散式應用服務 EDAS（Enterprise Distributed Application Service）是一個應用全生命週期管理和監控的一站式 PaaS 平臺，同時也是 [Open Application Model (OAM)](https://github.com/oam-dev/spec/) 模型在公有云上的第一個網際網路級商用平臺層實現。今天，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 具體的實現層，這種使用者定義的、面向應用的彈性伸縮策略，又該如何實現或者選型呢？

![1.png](https://ucc.alicdn.com/pic/developer-ecology/ef23a12ee7d24af28a2842439a581c94.png)

結合前面提到的三個具體的挑戰，以及新版 EDAS 基於 OAM 的 Kubernetes 原生化設計，阿里雲團隊決定直接從開源社群中來引入一個水平擴縮容元件來解決上述問題，並且針對 EDAS 的場景提煉出了三點主要的選型訴求：

1. 這個水平擴縮容元件提供的應該是簡單穩定的原子化能力，而不能跟某個具體的場景化方案（比如 Serverless）繫結。這同時也是 OAM 模型對“應用特徵”的基本規範和要求；
1. 這個水平擴縮容元件的擴容指標應該是外掛式的，這樣阿里雲團隊才能夠方便得擴充套件出基於定時、訊息佇列堆積訊息數、應用監控指標甚至 AI 預測結果的“以應用為中心”的彈性策略；
1. 原生支援 Scale To Zero，並且滿足第一條的要求。

而經過在社群中的評估和選型，最後阿里雲團隊選擇了微軟開源 [KEDA 專案](https://keda.sh/)，它目前已經移交給 CNCF 託管。KEDA 專案可以原生支援 Scale To Zero，更重要的是，它針對應用級水平擴縮容，解耦了被伸縮物件和伸縮指標，並分別提出了對應的抽象介面（ Scaler + Metrics Adapter 機制），從而即提供了強大的外掛機制，又能夠為所有擴縮策略提供一層統一的定義方式。此外，KEDA 的設計和架構比較簡，沒有很複雜的黑科技存在，內建的很多 Scaler 可以直接使用，非常符合 EDAS 產品的整體訴求。

# EDAS 基於 OAM 和 KEDA 的雲原生 PaaS 架構

在技術架構上，阿里雲 EDAS 產品核心是基於 OAM 社群的 [KubeVela 開源專案](https://github.com/oam-dev/kubevela/)構建的。正是藉助了 OAM 提供的 Kubernetes 原生的擴充套件機制，在上線像 KEDA 這樣來自雲原生開源社群的能力時，EDAS 產品研發團隊並不需要像傳統 PaaS 團隊那樣進行大量的二次開發甚至修改使用者側 API，而只需要將 KEDA 的 CRD 按照 OAM 規範“註冊”成為 EDAS 的一個 Autoscale Trait，完成監控資料對接，使用者即可使用到這個新增的水平擴容能力。整體架構可以用如下所示的示意圖表示清楚：

![2.png](https://ucc.alicdn.com/pic/developer-ecology/3cd8b34850374234a65b114db5bd81cd.png)
在具體實現中，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 的下一個時代。

阿里雲在應用擴縮容下遇到的挑戰與選型思考

相關文章