作者：关耳山石

整个端到端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），核心业务不中断
• 差异：

1. 弹性伸缩，是进攻牌，属于可靠性（Reliability）的范畴。意味着业务不能断，不管流量大小，可以通过资源补充或者释放的方式，不仅支撑业务，还能获得收益最大化，核心还是支撑业务
2. 熔断限流，是防守牌，属于韧性（Resilience）的范畴。意味着苟活，以退为进，丢卒保车，是一种自我保护

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

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

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

2.1 CCE如何实现弹性伸缩

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

• 一种是通过K8s的插件
• 另一种是借助AOM的监控指标：
  
  

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

• 节点伸缩
• 工作负载伸缩
  这两层顾名思义，不解释了。

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

2.2 CCE容器弹性伸缩——节点伸缩

2.2.1什么是Cluster Autoscaler

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

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

2.2.2 安装CCE节点伸缩插件

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

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

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

• 首先要安装autoscaler插件
  到插件市场，搜索autoscaler，安装插件

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

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

• 完成插件安装
  两个pod已经启动了，状态是运行中，命名空间位于kube-system

2.2.3 配置CCE节点伸缩策略

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

• 开始创建节点伸缩策略
  前提条件是插件状态是运行中

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

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

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

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

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

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

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

2.3 CCE容器工作负载伸缩

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

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

2.3.1 什么是HPA？

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

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

2.3.2 安装CCE工作负载伸缩插件

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

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

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

2.3.3 配置CCE工作负载伸缩策略

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

2.4 CCE容器层弹性伸缩效果验证

2.4.1 准备验证脚本

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

2.4.2 执行压力测试

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

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

2.4.3 验证弹性扩容结果

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

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

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

2.4.4 验证弹性缩容结果

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

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

2.5 ECS主机层弹性伸缩

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

3. 云上实现熔断限流

3.1 微服务内部熔断限流

3.1.1 如何实现微服务治理

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

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

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

• 从管理流程上，可以分为流量标记和设置治理规则两个步骤。系统架构师将请求流量根据特征打上标记，用于区分一个或者一组代表具体业务含义的流量，然后对这些流量设置治理规则。
• 从处理过程上，可以分为下发配置和应用治理规则两个步骤。可以通过配置文件、配置中心、环境变量等常见的配置管理手段下发配置。微服务SDK负责读取配置，解析治理规则，实现治理效果。

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

3.1.2 DEMO：验证微服务治理功能

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

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

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

3.2 CSE引擎层熔断限流

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

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

3.3 API网关层熔断限流

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

3.3.1 创建API

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

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

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

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

3.3.2 DEMO：验证APIG流控功能

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

总结

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

总结起来，可以通过：

• CCE容器的节点伸缩和工作负载伸缩两种能力，进行容器级别的弹性伸缩
• APIG层面流量控制，配合微服务内部的动态流量治理，进行微服务级别的服务治理