导读：随着云原生技术栈持续普及，如何以更高效率、让用户更容易接受的方式落地 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 产品自动弹性伸缩能力的新版本。与此同时，自 2020 年初起，EDAS 底层架构也启动了基于 Open Application Model（OAM）的一系列演进升级，目标是通过引入标准化、可插拔的应用定义模型来替代 EDAS 原有的 Application CRD。一方面，这能够为用户提供“以应用为中心”的上层抽象，避免强制用户直接理解 Kubernetes 的底层概念；另一方面，也能够借助模型本身的扩展性，让 EDAS 以“一键接入”的方式快速融合云原生生态中的各类能力。因此，这一新版自动弹性伸缩组件的设计与实现，也自然而然地与 EDAS 的 OAM 化架构深度结合。

在这套新架构中，应用的“自动弹性伸缩”策略以该应用的“特征”（Trait）形式存在。这里所说的“应用”，是 EDAS 借助 OAM 在 Kubernetes 之上向用户提供的一层上层抽象，并且完全通过面向用户的原语进行描述。由此，一个新的问题随之出现：在 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 社区的 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 时，如果名称过长，会被简单截断到 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 的下一阶段。