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

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

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