本文旨在通过介绍弹性伸缩技术以及弹性伸缩系统这款中间件产品，让开发同学了解到运维自动化给我们带来的便捷与保障。
从业务生命周期而言，正处上升期的应用，访问量可能每月甚至每周成指数倍数地增长，当你在为业务快速发展、脱颖而出而畅想自high：哥写得一手牛逼代码即将要支撑起阿里未来五年的腾飞了！！啪，程序运行FGC，啪，调用方超时，啪，触发限流~也许这已经是最近第N次的报警，也许这是最近第N次调用方打电话过来投诉，也许这是最近第N次的扩容……还能不能好好玩耍，专心把代码撸到极致？！业务下降期的应用或许已经不再投入开发，你是否曾想过线上其实早已不需要那么多的机器资源了，如果折算成RMB，这每天到底是有多少张毛爷爷从口袋白白飞走？不能再任性了，快让应用弹起来，让有限的计算资源服务到优质的业务上吧！
一、弹性伸缩的原理
弹性伸缩（Auto Scaling）是根据不同的业务需求与策略，自动调整应用的弹性计算资源，最终达到优化资源组合的服务能力。通过 自动伸缩 和 计划伸缩 这两种工作模式，应用便能在无运维人员介入的情况下实现自动调整计算资源，当访问量上涨时增加计算能力，而当访问量下降时减小计算能力，既保障了系统的稳定性与高可用性，又节约了计算资源成本。
弹性伸缩在业界有两个方向，一个是垂直化的扩展（Scale up），一个水平化的扩展（Scale out）。从业务发展的角度来看应该是水平扩展的能力，这要求业务都是无状态的，通过负载均衡技术将访问请求分配到集群每一台机器上，不管是增加还是减少机器，业务的连续性都不应受到影响。
二、基于弹性伸缩的系统运维架构图
在此模型中，展示层为用户交互，接受和呈现信息，主要表现为：
弹性伸缩监控大盘：用于全局监控接入弹性平台应用的运行状态，以及配置应用的弹性伸缩规则；
应用成本分析展示：用于呈现应用使用的资源成本，包括计算资源、存储资源、网络与带宽资源、CDN资源等；
虚拟计费（待定）：通过虚拟货币形式来衡量应用运行的费用开销情况。
逻辑层为运维自动化的核心，主要表现为：
弹性伸缩系统：应用弹性伸缩、虚拟化计算资源调度的智能规则引擎；
自动化部署：新应用上线、集群扩容和缩容的自动化工具；
计算资源分配：虚拟化计算资源的创建与回收的虚拟化基础设施。
资源层为计算、存储、网络、CDN等基础设施资源。
三、计算资源弹性伸缩模型
四、弹性伸缩策略
观察模式
模拟弹性伸缩的过程，弹性伸缩系统将会通过旺旺和邮件通知应用负责人以及运维人员什么时候要扩容或缩容、涉及的机器数，但是不会真正触发扩容和缩容的这个动作，此外，还可以在人工确认的情况下，手动触发扩容和缩容。简而言之，观察模式可以理解为应用接入弹性伸缩系统的一重保障。
自动伸缩
根据日常负载情况，计算应用所需的计算资源，以此达到降低成本、提升稳定性的目的。
1. 伸缩范围
最大实例数: 接入弹性前，集群的机器总数
（说明：当前应用有充足机器容量）
最小实例数: max(前七天qps峰值) / 单机QPS极限值 * 60%
（说明：最小实例数，前期阶段不会直接探底，会留有一部分余量）
2. 伸缩规则
扩容条件:
（1）集群水位超过40%
（2）每个CPU的等待队列长度大于0.5 或 cpu_avg超过50% 或 rt升高百分比超过300%
持续时间超过2分钟
缩容条件:
（1）集群水位低于13%
（2）每个CPU的等待队列长度小于0.2 与 cpu_avg小于15%
持续时间超过5分钟
3. 期望水位: 35%
备注：
集群水位 = 集群QPS / （单机QPS极限值 * 机器数）
单机QPS极限能力: csp单机压测值
计划伸缩
计划伸缩也称作定时伸缩，应用场景主要是根据计划提前做好各个系统的容量准备，以便承受可预见的瞬间访问高峰。举个例子，运营同学A准备今天要一次广告投放引流，一大波流量正在逼近！！假如A将预计引流PV总量事前告知弹性伸缩系统，提前将应用容量准备好，多少的流量过来都妥妥的了，真是深藏功与名~
全链路伸缩
复用自动化备战平台功能，根据预计交易创建笔数以及机房流量分配进行系统容量准备。
机器下线规则
- 首先计算出应用缩容的机器数量；
- 通过CMDB获取到下线机器列表，同时调用发布系统接口将beta机器加入到下线排除机器列表，如果有特殊需要排除的机器，需要在弹性伸缩系统上手动添加；
- 分批下线机器，以尽可能减小对业务访问造成抖动。
