来源|阿里巴巴云原生公众号

作者 |炎寻阿里云 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 的下一个时代。

阿里云在应用扩缩容下遇到的挑战与选型思考相关推荐

从“人肉扩缩容”到云原生容量，90 后程序员的进化
很难想象,1992年出生的郑洋飞已经是云原生性能容量团队Leader.2018年双十一稳定性总负责人,2020年双11的副队长.连续6年双十一,不仅是他带领团队的练兵场,更能从中看到蚂蚁集团技术演进的 ...
恒源云(Gpushare)_【存储优化】/hy-tmp可以扩/缩容啦
继[会员体系].[活动专区]上线后,为了进一步优化数据存储体验,特升级了[Tmp(/hy-tmp)]的使用规则,其他免费存储方式包括[OSS存储].[共享存储 (/hy-nas )],其免费额度及收费 ...
Fluid 0.5 版本发布：开启数据集缓存在线弹性扩缩容之路
作者 | 顾荣南京大学PASALab, Fluid项目co-founder 来源 | 阿里巴巴云原生公众号导读:为了解决大数据.AI 等数据密集型应用在云原生场景下,面临的异构数据源访问复杂.存 ...
Knative 基本功能深入剖析：Knative Serving 自动扩缩容 Autoscaler
Knative Serving 默认情况下,提供了开箱即用的快速.基于请求的自动扩缩容功能 - Knative Pod Autoscaler(KPA).下面带你体验如何在 Knative 中玩转 Au ...
Fluid 0.6 版本发布：数据感知的Pod调度与数据集自动弹性扩缩容
简介:Fluid 是 CNCF 基金会旗下云原生环境中数据密集型应用的高效支撑平台,由南京大学.阿里云云原生团队以及 Alluxio 开源社区联合发起.项目自开源发布以来吸引了众多相关方向领域专家和工 ...
Fluid 0.5 版本：开启数据集缓存在线弹性扩缩容之路
简介:为了解决大数据.AI 等数据密集型应用在云原生场景下,面临的异构数据源访问复杂.存算分离 I/O 速度慢.场景感知弱调度低效等痛点问题,南京大学PASALab.阿里巴巴.Alluxio 在 20 ...
Knative 驾驭篇：带你 '纵横驰骋' Knative 自动扩缩容实现
Knative 中提供了自动扩缩容灵活的实现机制,本文从三横两纵的维度带你深入了解 KPA 自动扩缩容的实现机制.让你轻松驾驭 Knative 自动扩缩容. 注:本文基于最新 Knative v0 ...
Serverless Knative Serving弹性扩缩容实践整理
文章目录 (一)基础 (1)认识 (2)Knative Serving对象模型 (3)knative-serving (4)Knative的扩缩容流程原理 (二)弹性扩缩容实践 (1)自动扩缩容类型选 ...
Flink checkpoint操作流程详解与报错调试方法汇总，增量checkpoint原理及版本更新变化，作业恢复和扩缩容原理与优化
这里写目录标题 flink checkpint出错类型 flink 重启策略 Checkpint 流程简介增量Checkpoint实现原理 MemoryStateBackend 原理 FsState ...

阿里云在应用扩缩容下遇到的挑战与选型思考