[CloudNative] 企业应用上云实践手记-Cloud Native Phase 4 -如何实现云上弹性伸缩和熔断限流

整个端到端CloudNative产品落地，计划分为六个阶段展开：

Cloud Native Phase 1 - 云上微服务开发端到端

Cloud Native Phase 2 - 云上DevOps

Cloud Native Phase 3 - 云原生应用AutoConfig

Cloud Native Phase 4 – 如何实现云上弹性伸缩和熔断限流

Cloud Native Phase 5 - 云上权限管理和网络安全

Cloud Native Phase 6 – 如何申请外网域名和SSL证书

本文为第四章即Cloud Native Phase 4 - 如何实现云上弹性伸缩和熔断限流。

题记：

前面把应用开发到部署的路走完以后，产品交付的坑基本趟平了，终于可以安心看下最有意思的部分：弹性伸缩和熔断限流。之所以把这两个命题放在一起探讨，个人理解，其实是一体的两面，目的当然很明显，都想保护核心业务，但是打法不一样。

这两个点如果非要排个先后，那我个人最感兴趣的就是弹性伸缩了，这部分也是个人对云最期待的地方，无限的资源和灵活的伸缩，一方面可以抗住短期的流量洪峰，另一方面还能节约资源。

往后发展，Serverless化、FaaS化以后，可能都不需要主动干预，即可实现Auto-Scaling，对于系统架构设计来说，那就更简单了，当然那又是另一个话题，我们项目在现阶段有引入FunctionGraph的能力，做一些简单的后端API，确实比较省事，但是架构能力很难体现（代码没法框架化，只能一个个的摞功能），后面会详细看看这块的能力。

下面主要从具体实现上，尝试总结一套标准打法，或者说“最佳”实践，以落地到华为云产品，欢迎指导。

1. 什么是弹性伸缩和熔断限流

关于弹性伸缩和熔断限流，网上有很多解释，笔者想从技术架构的角度，谈谈个人的理解：

共同点：

两者共性，就是都是通过一些措施，来预防波动对系统的影响，以期实现系统的长时间可用（Availability），核心业务不中断

差异：

弹性伸缩，是进攻牌，属于可靠性（Reliability）的范畴。意味着业务不能断，不管流量大小，可以通过资源补充或者释放的方式，不仅支撑业务，还能获得收益最大化，核心还是支撑业务

熔断限流，是防守牌，属于韧性（Resilience）的范畴。意味着苟活，以退为进，丢卒保车，是一种自我保护

无论是弹性伸缩还是熔断限流，都有很多种方式可以实现。从弹性伸缩来看，从ECS主机层、CCE容器层，都可以实现伸缩；从熔断限流来看，从微服务内部、CSE引擎层、API网关层，都可以实现熔断限流。

2. 云上CCE容器实现弹性伸缩

本文所有后端服务，除了用FunctionGraph的部分，其余全部跑在CCE上，因此先探讨CCE如何实现弹性伸缩。

CCE提供了两种方式来实现弹性伸缩：

一种是通过K8s的插件

另一种是借助AOM的监控指标：

CCE容器层的弹性伸缩，又分了两层：

节点伸缩

工作负载伸缩

这两层顾名思义，不解释了。

两者在具体使用时，都是需要的，首先是确保workload启动的时候，资源池里有资源，如果没有，则到资源池里扩节点。两者的实现方式和概念类似，但是依赖不同的插件支撑。

Cluster Autoscaler是Kubernetes提供的集群节点弹性伸缩组件，根据Pod调度状态及资源使用情况对集群的节点进行自动扩容缩容。

简单说，就是提供了一套独立的Pod，来执行一些Scale-up和Scale-down的流程，详情可以参考官方文档：节点伸缩原理。

CCE的节点伸缩，依赖了两套模型，一个是K8s自己支撑的autoscaler插件，另一个是通过监控探针的采集指标（即AOM服务）。

关于autoscaler插件

这部分建议直接看K8s的官方文档：Pod水平自动扩缩（Horizontal Pod Autoscaler）

华为的官方文档里有介绍，“当前该插件使用的是最小浪费策略，即若pod创建需要3核，此时有4核、8核两种规格，优先创建规格为4核的节点”，这一点还是很不错的，可以获得最小的碎片，不会浪费太多资源。

首先要安装autoscaler插件

到插件市场，搜索autoscaler，安装插件

基本信息，要选择集群（要伸缩的集群）

配置一下插件的规格

暂时选择50节点的规格，需要2个pod来跑这个插件，并且开启自动缩容，如果资源使用率低于50%的时候，就开始缩容扫描，然后进行安装

完成插件安装

两个pod已经启动了，状态是运行中，命名空间位于kube-system

插件安装完以后，就可以到弹性伸缩->节点伸缩中，创建节点伸缩策略，顾名思义。

开始创建节点伸缩策略

前提条件是插件状态是运行中

此处需要关联到一个节点池，或者说一个资源池

回到资源管理->节点池管理，创建一个新的资源池

新建节点池

选择0个节点，并启用弹性扩缩容，最大50个节点，最小0个，也就是默认这里没有节点，不伸缩的情况花费是0元。并且选择随机可用区，这样弹性出来的节点会离散分布在不同的AZ里

配置节点伸缩策略

选择刚建好的节点池，然后创建一个规则，这里支持两种，基于CPU/内存，和基于时间，这样可以用来处理突发流量波动和周期性流量波动，比如打卡、促销之类的。

最终，得到了一个空的节点伸缩策略

走到这里就会发现，很多参数其实并没有配置，比如每次扩缩容的间隔（保护时间）等，这些是全部在autoscaler插件里配置的

注意： 节点伸缩会触发ECS资源购买，这也简化了整体伸缩的复杂度，也就是不需要感知到支撑ECS弹性伸缩的AS服务

目前CCE的工作负载伸缩功能提供了两种模式，第一种是默认的，也就是K8s配套的，另一种是华为自研的增强版，具体参考官方文档

创建工作负载伸缩策略，两种模式的插件一不一样，暂时选择默认的Pod水平伸缩，即Horizontal Pod Autoscaling（HPA）

HPA是基于指标阈值进行伸缩的，常见的指标主要是 CPU、内存，当然也可以通过自定义指标，例如QPS、连接数等进行伸缩。但是存在一个问题：基于指标的伸缩存在一定的时延，这个时延主要包含：采集时延(分钟级) + 判断时延(分钟级) + 伸缩时延(分钟级)。这个分钟级的时延，可能会导致应用CPU飚高，相应时间变慢。为了解决这个问题，CCE提供了定时策略，对于一些有周期性变化的应用，提前扩容资源，而业务低谷时，定时回收资源。

参考官方帮助：工作负载伸缩原理

首先，进入弹性伸缩->工作负载伸缩，创建HPA策略

安装metrics-server组件的过程很简单，简单配置多实例一下即可

期间状态会是安装中，大约几分钟就OK

插件安装完以后，就进入下一步，策略配置页面，这里的参数介绍，可以参考前面的：[2.2.1 参考：HPA工作原理]

首先写了一个很简单的压测API，主要逻辑就是起一个线程死循环，API入参传入线程数，传导压力到容器内部，持续120秒。

利用APIG执行压力测试接口，传入并发线程数5

可以看到CPU有一个明显的波峰，可以达到100%的CPU利用率，超过前面HPA策略设置的阈值180%。

回到CCE的工作负载页面，可以看到已经增加了一个Pod

在工作负载的事件标签页里，也会记录一个ReplicaSet创建成功的动作

在工作负载的伸缩标签页里，也会看到HPA策略的SuccessfulRescale事件，重新计算了New size: 2; reason: cpu resource utilization (percentage of request) above target

第二次加压以后，弹性出来了4台机器，刚好用来验证压力回落以后，是否能够成功缩容

这里会发现，每隔6分钟，系统检测一次，识别到资源低于阈值，缩容1台服务器

ECS主机实现弹性伸缩，主要靠AS弹性伸缩服务，能监控CPU、内存、磁盘、入网流量等指标，然后自动的弹性伸缩，整体机制和前面节点伸缩差不多。

3. 云上实现熔断限流

因为本文是基于SpringCloud体系搭建的微服务框架，所以优先看了spring-cloud-huawei这套框架提供了Governance功能（ServiceComb-Governance的适配版），能够实现基于动态配置的流量特征治理。

下面这段基本上讲清楚了原理：

治理过程可以从两个不同的角度进行描述。

从管理流程上，可以分为流量标记和设置治理规则两个步骤。系统架构师将请求流量根据特征打上标记，用于区分一个或者一组代表具体业务含义的流量，然后对这些流量设置治理规则。

从处理过程上，可以分为下发配置和应用治理规则两个步骤。可以通过配置文件、配置中心、环境变量等常见的配置管理手段下发配置。微服务SDK负责读取配置，解析治理规则，实现治理效果。

简单说，就是先做流量标记，也就是所谓的染色，然后根据染色，配置一些规则确定何时限流，何时熔断等。然后再给个管理入口，进行配置下发，动态生效起来。

首先要引入一个依赖spring-cloud-starter-huawei-governance

2. application.yaml文件中增加如下配置，意思就是对前缀为/demo的API进行染色，限流为1个QPS

3.用工具测试一下，限流生效

CSE的服务治理只适用于Java Chassis、Go Chassis开发框架，由于程序是基于SpringCloud开发的，所以暂时不能使用该功能，只能通过服务内置的ServiceComb-Governance进行处理。

PS：参考官方文档：服务治理

API网关针对所有已发布的API，提供了一种流控措施，可以通过创建API流控策略，绑定API，进行生效。

首先在APIG服务中，进入流量控制页面，创建新的流控策略

这里分两种流控模式，基础流控和共享流控，一个是针对单个API消耗计数，另一个是所有绑定的共同消耗计数。

PS：详情可以参考官方文档：创建流控策略并绑定到API

然后绑定前面创建的测试API

通过Insomnia敲了20次回车以后，响应变成429 Too Many Requests，符合预期。

总结

华为云针对微服务，提供了一套相对完整的体系，能够支撑应用在流量洪峰面前，保护自己核心业务，整套体系无论是弹性伸缩还是熔断限流，都有多层的实现方式，可以从高到低，从边界最前沿到服务深处，逐层防护。

总结起来，可以通过：

CCE容器的节点伸缩和工作负载伸缩两种能力，进行容器级别的弹性伸缩

APIG层面流量控制，配合微服务内部的动态流量治理，进行微服务级别的服务治理

API Kubernetes 弹性伸缩 AS

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