弹性伸缩的条件与教训，用户在使用 HPA 时的三个认知误区

一、弹性伸缩的五个条件与六个教训

弹性伸缩是云计算时代给我们带来的一项核心技术红利，但是 IT 的世界中，没有一个系统功能可以不假思索的应用到所有的场景中。 这篇文章，我们将应用企业级分布式应用服务-EDAS 的客户在进行系统架构设计时，在弹性场景下遇到的点滴做了一个系统的梳理，总结为五个条件和六个教训分享给大家。

五个条件

1、启动无需手动干预

是否需要手动干预是弹性伸缩和手动伸缩的本质区别。在传统应用的运维中，一个进程的启动往往需要在机器上手动准备一系列的事情，如：环境搭建，依赖服务的配置梳理，本地环境配置调整等。如果是在云上的应用可能还需要手动调整安全组规则，依赖服务的访问控制等；但这些需要手动执行的动作在自动弹性时都会变得不可行。2、进程本身无状态

确切的说，无状态主要是指业务系统运行时对于数据的依赖程度，数据是在进程执行的过程中产生的，产生的数据会对后来的程序行为产生持续的影响，程序员需要在编码逻辑的时候，就考虑如果系统在一个新环境中重新拉起时，这份数据 是否对于行为会造成不一致的情况？ 推荐做法是数据应该最终以存储系统中为准，让存储计算做到真正的分离。

3、启动的要快，走的要有“尊严”

弹性 ， 尤其是云上的弹性，其中一个特点是会进行得很频繁。 尤其是流量突发型的业务，带着一定的不确定性。 而启动后的系统往往处在一个“冷”的状态，启动之后如何快速的“加热”是弹性有效性的关键。 而在弹性结束之后，往往伴随着一次自动的缩容，由于这个过程也是自动的，所以我们需要能从技术上能做到自动流量摘除的能力，这里的流量不仅仅包括 HTTP/RPC，也包括消息、任务（后台线程池）调度等。

4、磁盘数据可丢失

在应用启动过程，我们的应用程序可能会使用磁盘配置一些启动依赖项之外；在进程运行的过程中，我们也会习惯性使用磁盘打印一些日志，或者记录一些数据。而弹性场景是进程快起快没，没了之后放在磁盘上的数据也都没了，所以我们要做好磁盘数据丢失的准备，可能有人会问日志怎么处理？日志应该通过日志收集组件收走，进行统一的聚合、清洗和查阅。这一点在 12 factor apps 中也做了强调。

5、依赖的服务充分可用

成规模的业务系统，往往不是一个人在战斗。 最典型的架构中，也会使用到一些缓存、数据库等中心服务。 一个业务弹性扩容上来之后，很容易忽略中心依赖服务的可用性。 如果依赖服务出现不可用，对于整个系统可能就是一个雪崩的效应。

六个教训

1、指标值设置不合理

弹性整体分为三个阶段： 指标获取、规则计算、执行伸缩； 指标获取一般通过监控系统或者 PaaS 平台自带的组件获取。 基础监控指标常见的如： CPU/Mem/Load 等。 短期内有一些基础指标数值会存在不稳定的特点，但是时间拉长，正常来看会处在一个“平稳”的状态，我们设置指标的时候，不能以短时间的特征为依据，参考较长时间的某种水位数据才能设置一个合理值。 且指标不宜过多，同时缩容指标要和扩容指标存在明显的数值差。

2、把“延时”当指标

很多时 候我们识别系统可用性的一个很大的判断，就是看系统屏幕是不是在“转圈圈”，即系统很慢。 常理推断，很慢就要扩容了。 所以我们有一些客户直接把系统的平均 RT 当成了扩容指标，但系统的 RT 是多维度的，比如 health check 一般都是很快的，这类 API 出现的频率稍高一点，一下就拉低了平均值。 也有的客户会精确到 API 级别，可是 API 也是根据参数不同逻辑不一样的从而造成 RT 不一样。 总之，根据延时去做弹性策略是很危险的一种做法。

3、指定单一的扩容规格

扩 容规格指 的是资源的规格，比如在云上的场景中，对于同一种 4c8g 的规格，我们可以指定内存型、计算型、网络增强型等。 但是云上是一个大资源池，对于某一种规格，会存在售罄现象；如果我们只指定了单一的规格，就会出现资源无法提供而出现扩容失败的情况。 这里最危险的还不是扩容失败本身，是出现业务故障之后的排查过程会特别漫长。

4、只考虑RPC链路中的应用策略

针对单 个应用往往都很简单的，难的是整个业务场景的梳理。 梳理思路一个简单的办法就是按照应用调用的场景进行，从应用间调用的场景来看，一般来说分为三种： 同步（RPC，中间件如  Spring Cloud）、异步（消息，中间件如  RocketMQ）、任务（分布式调度，中间件如  SchedulerX）。 我们一般会很快整理出第一种情况，但是很容易忽略掉后面两种。 而后面两种出现问题的时候，问题排查诊断又是最为耗时。

5、没有配套相应的可视化策略

弹性伸缩是一个典型的后台任务，在治理一个大集群的后台任务的时候，最好是有一块大屏进行直观的可视化治理。 对于扩容失败的情形，不能静默处理。 如果是核心业务出现扩容失败，可能带来的就是直接的业务故障，但是故障真正发生时，很多时候不会去关心扩容策略是否生效，如果真是因为扩容造成的故障，也很难排查到这个点。

6、事前没做正确评估

虽然 云计算给弹性提供了近乎无尽的资源池，但这也只是解放了用户预备资源的工作，而微服务系统本身复杂，单一组件的容量变化会产生全链路的影响，既解除一处风险之后系统瓶颈点可能会迁移，有些隐形约束也会随着容量变化逐步显现，所以做弹性策略大多数时候不能靠力大砖飞的思想，需要做好全链路的压测、验证，演练到适应于全局的弹性配置； 我们还是建议事前从高可用的多个维度了解各种技术手段，形成多套预案以备使用。

总结

云原生场景下弹性能力更为丰富，可供弹性的指标也更具备业务定制能力。应用 PaaS 平台（如企业级分布式应用服务 EDAS/ Serverless 应用引擎 SAE 等）能结合云厂商在计算、存储、网络上的技术基础能力，能让使用云的成本更低。但是这里对于业务应用会提出一点点挑战（如：无状态/配置代码解耦等等）。从更广的侧面来看，这是云原生时代应用架构面临的挑战。不过应用越来越原生的话，云的技术红利也会离我们越来越近。

二、EDAS 用户在使用 HPA 时常遇到的三个认知误区

云计算带来的优势之一便是弹性能力，云原生场景下 Kubernetes 提供了水平弹性扩容能力（HPA），让应用可以随着实时指标进行扩/缩。

然而 HPA 的实际工作情况可能和我们直观预想的情况是不一样的，这里面存在一些认知误区。本文总结了一下 EDAS 用户在使用 HPA 时常遇到的三个认知误区，具体如下：

误区一：HPA 存在扩容死区

现象：当 Request=Limit 时，期望利用率超过 90%时，无法正常扩容。

原因剖析：HPA 中存在容忍度（默认为 10%），指标变化幅度小于容忍度时，HPA 会忽略本次扩/缩动作。若当期望利用率为 90%时，则实际利用率在 81%-99%之间，都会被 HPA 忽略。

避坑指南：当 Request=Limit 时，避免设置过高的期望利用率，一来避免扩容死区；二来被动扩容有一定的迟滞时间，留下更多的缓冲余量以应对突增流量。

误区二：误解利用率计算方法，HPA 扩容与预期使用量不符

现象：当 Limit > Request 时，配置 50%的利用率，使用量未达到 Limit 的 50%便扩容。

原因剖析：HPA 计算利用率是基于 Request 计算，当 Limit > Request 时，实际利用率是可以超过 100%。

避坑指南：对于较为重要的应用，应当设置 Request=Limit 保证资源的独占。对于可以容忍资源共享的应用，对应的期望利用率也不应设置的过高，在集群资源紧张时，超量使用资源的 Pod 很有可能会被杀死，从而造成服务中断。

误区三：弹性行为总是滞后的，扩缩行为与心理预期不符

现象：指标突增时，HPA 不会立刻扩容，且扩容可能是分多次进行，最终稳定时的实例数也与预期不同。

原因剖析：HPA 的设计架构决定了，HPA 扩/缩容总是滞后的，且扩/缩容收到弹性行为（behavior）与容忍度共同作用。其中弹性行为限制了扩/缩容速率，不会一口气扩/缩到期望实例数。而容忍度会忽略指标的小幅度变化，从而导致在多次扩容的场景下，最终计算的实例数可能与一开始计算出的实例数不同。

避坑指南：了解 HPA 工作原理，配置合理的弹性行为（behavior）。

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。