开发者学堂课程【高校精品课-华东师范大学 - Python 数据科学基础与实践：阿里云云计算 ACP 认证（4）】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/1006/detail/15119
阿里云云计算 ACP 认证（4）
以淘宝为例，按频道分为不同的服务器，有30台 ECS 来去处理，比如说是首页的逻辑，30台处理女装的频道，30台处理三星类的频道需要在 SOB 前面建立不同的域名前缀，比如说 3w .开头的目录，转发到首页位置。如果前缀或者后缀，比如说我的路径包含着女装 dress 路径转发到后端，如果有3 c 的路径，将其转发到三式台位置，如此不需要每一台装一模一样的程序了。以上就是关于负载平衡的内容。
一、弹性伸缩 AS
弹性伸缩产生的背景举例如图，某视频公司，有很明显的波峰波谷，春晚或者每周五热门节目来临时，如临大敌，需要按负载自动弹性伸缩这样的一种机制。
场景2是直播公司，无法预估业务的负载情况，需要动态检查的能力，需要根据 CPU 利用率、 Load、带宽利用率，自动弹性收缩。场景3是像游戏公司，学生上课其负载低一些，学生放假负载高一些，反应的特点就是像游戏这样的业务是一天会有多个峰谷效应，业务高的波谷的压力和业务低的时候波谷的压力可能会相差很多倍，所以其需要具备定时扩容和缩容的一些能力。在这样的背景下产生了弹性伸缩的一种服务，这个服务主要的作用是根据业务的需求，或者提出的策略来经济的并且自动的调整弹性资源。
其能提供的资源或者类型有很多种，上图的三种指代常见的类型。
像按负载自动弹性伸缩的或者根据监控进行弹性伸缩的，或者做一些定时的弹性伸缩的都是弹性伸缩覆盖到的一种能力，一些类型。
解决方式是如果你不使用弹性伸缩，以前传统的做法是什么？即土豪做法超配，当我们的业务有峰谷现象的时候，直接按顶格的资源买单。不管业务是如何上升下降，永远都不会到达峰值，因为资源是足够的。在以前这种方式是非常常见的，做 IT 的审批，按年度金额为单位的。资源链在之前就打足打够。这时候你就会发现，这种时候可以解决问题，但是觉大多数的时候计算机资源是在浪费的。另一种做法较为精细，即当你发现业务能力增长的时候，赶紧去弥补资源使得业务增长。所以看到图示是折线的情况，是因为发现资源已经不够，或者说资源马上不够，所以要马上添加资源。资源采买到位以后，让其生效需要一定的滞后时间，在资源到位的时候，在第一个波峰处资源要高于供给的负载，像折线和曲线相交的位置，系统不稳定因为负载高于承受能力。所以这种人工伸缩的方式，也具有不足之处。最好的方式是自动的，即曲线跟资源是伴生关系，以一种刚刚好的姿态，当资源往上升，资源的供给也是刚刚好的抵消掉其需要，往下降的时候也是刚刚收回，这种情况进行动态的调整。所以这是弹性伸缩想要去实现的。
所以弹性伸缩（ AutoScaling ）服务，本身所带来的意义，可以自动调整弹性计算资源 （ECS） ，以满足业务需求的变化。帮助我们以一种更优雅的方式来管理其资源。它的应用场景包括：弹性扩张，弹性收缩，弹性自愈，其中扩张跟收缩较容易理解，即压力上升自动加资源，压力下降自动回收资源，根据是什么样的方式去增加或减少指标？自我设置，自愈跟 SOB 健康检查是有关系的，可以想象，之前是3台 ECS 进行提供服务，现在有一台 ECS 出错，即使是有两台 ECS 并且可以检测到这台故障的 ECS 将其屏蔽掉用户无影响，但是同样需要注意这台 ECS 出错摘除之后，它的压力瞬间转移到另外两台 ECS 上。在这种情况之下，另外的两台 ECS 也可能撑不了多久，如果说平均水位比较高的情况下，机器出错没有及时的补充资源，可能剩下的正常机器也撑不住多久，所以弹性伸缩有一种健康模式，可以跟 SOB 相结合，发现其中有一台机器出错，会立马找一台新机器替换弥补，这就是弹性自愈的意思。
AutoScaling 的工作原理实际上是模拟的一种 web 应用，通过 ECS 提供处理业务，将架构大概分为几个结构： SLB 负责把用户的请求中转，转发给伸缩组订好的 ECS ，中间层是一个伸缩组，另外一个 ECS 都在伸缩组中，负责受理这些实例。
最下层是 RDS 负载存储 ECS 业务数据，弹性伸缩整个工作组的过程如此。第一步监听 ECS 的健康情况，设定时的或者健康检查的，可以设自定义任务的，图中是云监控的动态模式去监听 ECS 的性能，比如说像健康的情况，如果是健康情况，那就是走健康检查的任务。如果是监控性能走动态模式，大概有这么几类。
定时任务的模式其实是指定时间像之间举例学生的事例，定时的伸或者缩，自定义一个规则就可以。自定义任务主要是去手动的或者接入 API ，我们自己手动去制作的。健康检查主要是跟 SOB 的健康检查相结合，如果发现这个集群当中的某个 BCS 处于不健康的状态，那么将其移出去进行补充。
云监控的动态模式，主要是监控这些 ECS 的各项指标，比如 CPU ，整个组中的 CPU 的平均值大于百分之八十，我们需要往下走类似的大概有这么几种情况，往下走会触发一种伸缩规则，达到伸缩规则就会去执行，程序创建一个伸缩活动，而一个伸缩活动它主要会包含：首先 ECS 指导伸缩规则，需要增加多少台 ECS ，或者减少多少台 ECS ，或者增加到多少台 ECS ，减少到多少台 ECS 。第二个需要有一个伸缩配置，应该创建怎样的 ECS ？这个 ECS 基于哪个镜像，启动键的，依次发现 ECS 是什么样的规格？有了以上这些条件， ECS 才能够被正确的创建出来，伸缩的规则当中还需要创建，如果说ECS 有关联到 RDS SOB ，需要去写创建出来的 ESC 自动的加入到 SOB 后端，自动加入到 RDS 后端。
加入到白名单中，这些规则都需要设置一下，当 ECS 补充添加之后，要使得负载恢复到之前的水平是需要一定的时间的，假设一分钟两分钟之后，负载平衡恢复， ECS 加入之后，自身的业务需要被受理，整体是有一定的时间延迟的，所以我们需要一个冷却时间，在冷却时间内不能创建两台，加进去还没有正式开始工作，以 CPU 来看，五秒十秒检查一次，此时的 ECS 并没有真正的产生效果，这是再创建两台 ECS 其实不符合科学。
冷却时间只针对云监控的动态模式下，其他的并不受其影响。对于该图的弹性伸缩有比较多的概念，伸缩组，伸缩规则，伸缩配置等等。这种是比较容易出题目，需要多留意。
这里将弹性伸缩的主要功能列举一下：伸缩组，伸缩配置，伸缩规则，触发任务，伸缩活动，这些概念基本都了解过。伸缩组就是具有相同应用场景的 ECS 的集合定义组内 ECS 实例数的最大值、最小值及其相关联的 SLB 和 RDS ，伸缩配置是指用于弹性伸缩的 ECS 的配置几盒机 G ，什么操作，什么网络，什么光盘，什么镜像等等，还可以指定弹性容器实力 ECI ,伸缩规则是具体的扩展或收缩操作，是加几点或是减几点，加到几个或者减到几个，例如加入或移出 N 个 ECS 实例，触发任务指的是定时任务报警任务，伸缩活动指的是伸缩规则成功触发后，就回产生一条伸缩活动。
配置流程如图所示，第一个创建伸缩组，写伸缩组的最小值最大值，关联的 SOB 等等，均在第一步进行配置，第二步创建伸缩配置， ECS 的实际规格，使用的哪个镜像等等。
然后将伸缩组启用，来创建伸缩规则，比如说加两台 ECS 这是一种伸缩规则，比如说还有定时的伸缩要求，12点触发一次一张，或者 CPU 大于百分之八十的时候触发一个规则，这就是 AutoScaling 的配置流程。
最佳实践就是多种模式组合使用，这种模式并不是排他的是组合使用的。针对 k8s 弹性伸缩并不是针对 ECS 级别的，并不是针对容器的级别，实际上弹性伸缩跟 k8s 组件应该是良好的互补，对 HPA 水平节点伸缩的数量， pod 的数量是存在上限的，你的 worknote 有几个，最终创建的 pod 有几个，HPA 在怎么调用，物理的池子只有这么多，底层 ECS 数量有限，在 k8s 当中有个好处就是当worknote 为20台，其平均负载高于百分之八十，那么这时候再去补充比如说5台， worknote 会被动态扩展，可以跟容器服 as 这层兼容到 outspaek 中去负责，业务水平的弹性扩展是 HPA 这样的控制器负责，就可以更好的实现业务的弹缩。
