微信代理网站模板,网站建设的六个步骤,php网站建设考试,seo按天计费软件作者 | 三未
前言
弹性伸缩是一种为了满足业务需求、保证服务质量、平衡服务成本的重要应用管理策略。弹性伸缩让应用的部署规模能够根据实时的业务量产生动态调整#xff0c;在业务高峰期扩大部署规模#xff0c;保证服务不被业务冲垮#xff1b;在业务低谷期缩减部署规模…
作者 | 三未
前言
弹性伸缩是一种为了满足业务需求、保证服务质量、平衡服务成本的重要应用管理策略。弹性伸缩让应用的部署规模能够根据实时的业务量产生动态调整在业务高峰期扩大部署规模保证服务不被业务冲垮在业务低谷期缩减部署规模避免资源浪费。
由于大部分云资源是按需取用按量计费模式相比使用 IDC使用云的用户从弹性伸缩获得的成本优势是非常明显的弹性伸缩也是大多数云上用户的选择。而关于如何用好弹性伸缩一直是用户非常关心的问题本文尝试围绕这个话题给出一些相关的思考和优化实践。
有两种实现弹性伸缩方法一种是“垂直弹性”即“Scale Up”另一种是“水平弹性”也就是“Scale Out”。
1. 垂直弹性伸缩
垂直弹性伸缩一般是指通过升降服务器的规格来实现的弹性伸缩。这种伸缩方式对应用本身几乎没有约束可以被大部分应用或组件使用它的问题主要在两个方面
动态调整服务器的规格而不影响上层部署的应用对基础设施要求比较高对于许多云厂商而言是个难题并不能实现业务完全无感的动态变配垂直弹性无法突破单台物理设备的规格限制面向巨量的突发业务增长垂直弹性的应对能力是有上限的。
2. 水平弹性伸缩
而水平弹性伸缩恰恰相反它依靠增减服务器的数量来实现弹性伸缩对基础设施的要求不高水平弹性除了可以解决容量上限的问题多副本部署还能带来更高的可靠性因为被广泛的使用在生产系统中很多时候水平弹性也成了弹性伸缩的代名词所以我们后文的讲述的主要也是水平弹性。
微服务与弹性伸缩
水平弹性虽然存在诸多优势但它对于应用本身的要求相比垂直弹性是更高的开发者在使用前需要要考虑好以下的问题
多副本部署要求应用本身无状态化如何抽离应用中的状态信息并保持配置同步弹性伸缩导致应用实例本身是不稳定的如何保证应用实例之间能实现可靠的相互调用
这些恰好也是微服务架构要解决的问题而 SpringCloud 作为广泛使用的微服务框架自然不例外拿问题对号入座的来看
其一通过 SpringCloud开发者可以将原先单体应用中无状态的部分拆解出来以服务的形式来组织业务逻辑无状态的服务本身是可以进行水平伸缩的另外 SpringCloud 提供了很易用的集中式配置管理能力确保了配置信息可以被高效的分发和同步其二SpringCloud 的服务注册和发现机制使得服务可以动态的增加或移除实例通过熔断等服务治理机制可以进一步提升远程调用的可靠性。
换个角度看催生微服务的驱动力之一就是开发者希望利用云的弹性伸缩能力来实现运营成本和服务质量的平衡因此微服务从设计上就考虑到了要利用弹性伸缩的能力它们之间是本来就是相辅相成紧密相关的。
原生的弹性伸缩
应用架构支持只是使用弹性伸缩的必要条件之一想用好弹性伸缩另外还有两个关键点需要考虑在什么时机触发弹性伸缩以及弹性伸缩产生出来的应用如何部署即规则触发和实例调度。
在云原生的体系中K8s 控制了应用的生命周期管理在弹性规则触发与实例调度方面K8s 也提供了相关的能力足够完成应用弹性伸缩的整个过程。
K8s 中无状态应用通常以 Deployment 的形式进行部署弹性伸缩过程由 Horizontal Pod AutoscalerHPA来进行控制开发者设定 CPU 或内存的目标使用率与 Deployment 的副本数区间由 HPA 负责定时从监控数据中计算并设定目标的副本数至于实例的调度过程则交由 K8s 的 Scheduler 来控制。
参考https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/ 如何优化弹性伸缩
看起来借助 K8s 的 HPA 机制就可以很轻易的给微服务应用提供弹性伸缩能力但这样真的就足够了吗没有那么简单在弹性伸缩上目前 SpringCloud 和 K8s 的默认机制仍然存在诸多不足如果缺少完备而健壮的方案将其直接用于生产系统其实是很容易踩坑的。怎么做才能保证弹性伸缩精准到位过程如丝般顺滑这是我们写作本文提供最佳实践的意义。
EDAS 作为一站式的分布式应用管理平台对于弹性伸缩这样涉及应用监、管、控全方位的场景在对弹性伸缩的支持上做了系统的设计打磨出许多功能点目的是为用户使用弹性伸缩的“减负”使其能真正落地到用户生产系统中。
顺着刚提到的两个关键点规则触发与实例调度我们来看 EDAS 在优化弹性伸缩方面是如何思考与实现的。
1. 规则触发
常用的弹性伸缩规则是基于监控数据来进行触发的K8s 也自带了基于 CPU 和内存监控来触发弹性伸缩的功能。但仅有这两种指标并不够相比基础监控数据应用指标数据对于业务量的反馈更为直接和敏感可以说是适合弹性伸缩参考的“黄金指标”。
但由于 K8s 无法获取到应用的监控信息这些信息只能通过自定义扩展 API 的方式来实现对于用户来说需要理解 K8s 的扩展机制有一定的学习成本而且基于监控数据的规则无法实现实例数从 0 到 1 的扩容这也不利于实现极致的成本控制。
1KEDA
针对这些痛点开源社区发展了很多项目其中最为典型的是 KEDAKubernetes Event-driven Autoscaling通过事件流来辅助 K8s 进行弹性伸缩架构如下 KEDA 项目地址https://keda.sh/
KEDA 可以被方便地安装到任意的 K8s 集群它的 ControllerOperator提供了将应用从 0 副本扩缩的能力KEDA 也提供了监控指标服务通过不同的 Scaler 来对接各种开源与供应商的监控指标并将这些指标提供给 HPA 控制器来完成多副本的弹性伸缩。
2EDAS 的应用弹性策略
KEDA 的功能很强大但对于一般用户而言使用的门槛比较高为了解决这一问题EDAS 结合 ARMS 提供的应用监控能力在保留 KEDA 核心功能同时对其做了增强使得弹性的规则配置更为易用。
EDAS 的弹性伸缩既支持 K8s 原生的 HPA 规则的配置能力 还能使用应用黄金指标如服务每秒请求量QPS和平均响应时间RT 此外EDAS 不仅支持指标弹性还支持定时弹性通过为不同时段设置合理的副本数区间定时弹性能最大程度的保证用户体验 2. 实例调度
弹性伸缩的规则触发将产生实例调度的请求但如何将这些请求分配到节点并在节点部署应用实例调度是必经的流程也是 K8s 的核心能力。对于弹性伸缩这一场景由于涉及大量新实例创建和旧实例的替换实例调度的动作非常频繁首先选择合适的调度策略就非常重要。
1调度策略
K8s 提供了丰富配置项供开发者设定调度策略比如节点选择节点亲和污点和容忍等。但如何搭配所需的调度规则并没有放之四海而皆准的做法需要根据业务实际情况来进行制定这里列举一些设置调度规则时常见的考虑
弹性伸缩发生时系统往往处于比较繁忙状态尽可能将新增实例发布到不同节点可以有效避免集群压力分布不均带来的服务质量受损或资源浪费将节点分开并均衡部署到多个可用区能有效提升系统的可用性对于具有密切关联性的应用实例可以考虑部署到同样的节点或可用区可以减少调用开销提升稳定性。
对于第 3 点仅靠调整调度规则还不够还要依赖微服务治理的能力使得关联实例能完成就近的服务路由这也是 EDAS 正在解决的问题之一而对同应用分节点或者可用区部署 EDAS 已经提供了直接的支持用户只需要部署时勾选即可 弹性伸缩时另一个常见的问题是集群节点资源被用尽因为 K8s 不会主动扩展节点此时即使弹性伸缩产生了准确的调度请求K8s 也无法分配出新的应用实例。考虑到这种可能性这要求用户预留一部分节点资源以应对弹性的需求但由于资源池的存在导致用户付出的成本并非是完全的按用量计费这又与弹性伸缩的初衷相悖我们不禁会想怎么做能让节点资源既能物尽其用又能取之不竭
2Cluster AutoScaler
社区的 Cluster AutoScaler 项目提供了集群节点的自动扩缩一定程度上解决了资源的按需申请问题各容器服务提供商也提供了对应的 Cluster AutoScaler 实现阿里云也不例外在 ACK 的管控台可以直接配置集群的自动伸缩 但 Cluster AutoScaler 也有其不足的地方比如
首先Cluster AutoScaler 是在产生了无法满足的实例调度请求之后才开始介入的而购买新实例的时间比较长可能在分钟级远大于 Pod 的启动时间这等于降低了弹性伸缩的灵敏度增加了服务受损的风险其次在缩容时由于应用实例是随机释放的因此会产生一些遗留的应用实例分散在不同节点上变成碎片Cluster AutoScaler 在缩容节点前会尝试迁移这些实例需要消耗时间甚至引发稳定性问题也不利于成本控制。
3Serverless Kubernetes
问题的根本还是出在调度上K8s 需要匹配实例与节点在这个过程中有太多的复杂度需要用户去考虑和处理。那是否消除掉 K8s 集群的节点去掉调度的过程就是通往极致的弹性的方向答案是肯定的而且阿里云的 Serverless Kubernetes 服务ASK在这个方向上提供了一条现成的途径。
使用 ASK 服务用户不用关心节点资源是否充足应用实例秒级调度按量计费完美的契合了弹性伸缩的需求 EDAS 也支持了 ASK 集群的接管用户可以直接在 EDAS 创建 Serverless 应用就能得到“彻底”的弹性伸缩能力 结语
本文介绍了微服务应用在云原生体系下的弹性伸缩的并尝试从弹性伸缩的两个关键点来探讨优化的方向和做法以及 EDAS 是如何看待并解决这些问题的。
弹性伸缩包含了应用生命周期的整个过程这过程中就涉及到多项应用管理能力的联动举个例子如应用实例缩容时如何进行节点的无损下线这在弹性伸缩过程中就是非常重要的功能类似的场景非常多受限于篇幅本文不做展开。
对于 EDAS 来说弹性伸缩就是一场综合的能力测验只有在每个环节都做到位才能更好的用户业务保驾护航。而我们也相信 EDAS 通过与云原生技术和云产品的全面融合能带给用户更佳的体验助用户“躺着”用好弹性伸缩享受到云的福利。 原文链接 本文为阿里云原创内容未经允许不得转载。
