AutoScaling技术要点
一、优点与限制
1.1、优点
l 实现资源的自我补充和减少机制；
l 支持多种触发机制；
l 按需调用实例，提高单个实例的利用率，减少费用；
l 支持多种扩展方法，提高场景及需求匹配度；
l 可以实现一个组多策略的使用方法；
l 高可用，组合灵活；
1.2、限制
|
资源 |
默认限制 |
|
启动配置 |
100 |
|
Auto Scaling组 |
20 |
|
每个Auto Scaling 组的生命周期钩子 |
50 |
|
每个Auto Scaling 组的负载均衡器 |
50 |
|
每个扩展策略的步进调整 |
20 |
当然，这些限制可以通过提交AWS的技术申请放开，但提升的幅度不会很大。
二、AutoScaling的策略
2.1、扩展策略
AutoScaling支持四种扩展方法：始终保持当前实例等级、手动扩展、按计划扩展、按需求进行扩展；
始终保持当前实例等级：实际上保持EC2 的数量不变，在出现健康EC2是进行替换；
手动扩展：在现有运行的Auto Scaling 的组中，手动添加EC2，并加入到组中；
按计划扩展：主要是设定时间点，在固定的时间执行EC2 的扩展，或者启动一个新的Auto Scaling组，无论当时机器负荷情况如何；
按需求进行扩展：此策略是Auto Scaling官方推荐策略，也是最自动话的扩展策略，此策略主要依托触发机制使用，当监控到达设定报警线后，会根据既定的要求，自动增加EC2 到已有的Auto Scaling 中，或者重新启动一个新的Auto Scaling 组；
注意：一个Auto Scaling组在任何给定时间可附有多个扩展策略。
2.2、收缩策略
在收缩策略上的方法，也是跟扩展策略的方法一一对应，除了按需收缩策略外，其他都是不需要兼顾EC2 当前的运行状态，所以，在选择取消那个在线的EC2时比较简单，而按需收缩策略上则需要判断怎么去终止EC2 ，这样才更贴合用户的场景需要。
Auto Scaling 为此，提供了5种终止策略方案，具体如下：
• OldestInstance。Auto Scaling 终止组中最旧的实例。当Auto Scaling 组中的实例升级为新的EC2 实例类型，可以逐渐将较旧类型的实例替换为较新类型的实例时，此选项十分有用。
• NewestInstance。Auto Scaling 终止组中最新的实例。如果要测试新的启动配置但不想在生产中保留它时，此策略非常有用。
• OldestLaunchConfiguration。Auto Scaling 终止采用最旧启动配置的实例。如果要更新某个组并且逐步淘汰先前配置中的实例时，此策略非常有用。
• ClosestToNextInstanceHour。Auto Scaling 终止最接近下个计费小时的实例。此策略最大程度使用实例并管理成本。
• Default。Auto Scaling 使用默认终止策略。如果有多个扩展策略与该组关联，此策略非常有用。
此默认终止策略可帮助确保网络架构均匀分布到多个可用区。当使用默认终止策略时，按如下方式选择要终止的实例：
1. Auto Scaling 确定在多个可用区中是否有实例。如果是，它会选择有最多实例并且至少一个实例不受缩减保护的可用区。如果有多个可用区有此数目的实例，则Auto Scaling 选择使用最旧启动配置的实例所在的可用区。
2. Auto Scaling 确定所选可用区中的哪些不受保护的实例使用最旧启动配置。如果有一个此类实例，它会终止该实例。
3. 如果有多个实例使用最旧启动配置，则AutoScaling 确定哪些不受保护的实例最接近下个计费小时。（这有助于最大程度使用EC2 实例，同时最大程度减少对Amazon EC2 用量的计费时数。）如果有一个此类实例，Auto Scaling 会终止该实例。
4. 如果有多个不受保护的实例最接近下个计费小时，则Auto Scaling 随机选择其中一个实例。
流程图说明：
终止策略跟扩展策略上有点不一样的地方是：终止策略可以多个应用到一个Auto Scaling 组上。
三、AutoScaling 的实施
从上面的介绍可以看到，在AutoScaling的部署中，会可以有多种不同的搭配，基于不同的情况下，触发/启动一个新的Auto Scaling组，很多时候还可以多个组去形成一个系统集群。
3.1、策略的选择
Auto Scaling从本质上就是要确保集群的高可用性，所以在策略选择上，也不能以单一的方式作为集群接点的伸缩支撑，需要使用多种策略结合的方式结合，让Auto Scaling更显健壮；
3.2、基础对象的选择
Auto Scaling部署中，很多时候为了提高EC2 的应用率，都会在Auto Scaling按需扩展的策略，这种策略有一个短板，就是需要外部警报的触发（手动也可以），根据设定的条件进行收缩，所以监控什么对象产生警报，这就很关键了。
例如：现在有一个ELB+ 2个EC2 运行了一个Web 应用平台，如果我们设定监测其中一个EC2 的CPU利用率高于80% 或内存使用率高于90%时触发一个Auto Scaling组，增加EC2 来减轻现有EC2 的压力。这种做法是一个很正常的做法，但是很多时候我们会忽略一个事情，当被监控的EC2 宕机了，这样Auto Scaling组就无法触发了。
所以在这种情况下，我们可能把监控的对象放在ELB上更可靠些，当然，还是将ELB+ 2个EC2做成一个Auto Scaling组，并设置为“始终保持当前实例等级”，在基于此Auto Scaling组上建立监控和警报触发，这样会有更大的可靠性；
3.3、多AutoScaling组形成的集群
如3.2 例子上所说，多个AutoScaling 组建的系统集群具有更高的可靠性，同时也会拥有更大的可扩展性（毕竟一个Auto Scaling组只能最多包含20个EC2）。而不同组别之间可以基于不同的EC2 类别进行组件，互补双互之间的不足；
3.4、AutoScaling组接点EC2的安全性
在Auto Scaling中包含多EC2，这些EC2在系统使用的过程中不停地经行更替，所以对Auto Scaling组的配置必须要有一个谨慎的安全意识，同时其使用的安全组也不能经常进行修改；