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

來源 | 阿裡巴巴雲原生公衆号

作者 |炎尋  阿裡雲 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 的場景提煉出了三點主要的選型訴求：

1. 這個水準擴縮容元件提供的應該是簡單穩定的原子化能力，而不能跟某個具體的場景化方案（比如 Serverless）綁定。這同時也是 OAM 模型對“應用特征”的基本規範和要求；
2. 這個水準擴縮容元件的擴容名額應該是插件式的，這樣阿裡雲團隊才能夠友善得擴充出基于定時、消息隊列堆積消息數、應用監控名額甚至 AI 預測結果的“以應用為中心”的彈性政策；
3. 原生支援 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 的下一個時代。