富通云腾CloudoorSphere 在7月发布了4.2新版本，较4.1版本最大的改进是增加了AutoScaling自动伸缩服务。

AutoScaling是一个比较重要的服务组件功能，它比较巧妙地实现了云的弹性。在应用忙时扩展计算能力，在应用闲时收缩计算能力，很好地体现了云计算按需供给、按量计费的宗旨。

我们先看几个关键概念

    ■  cooldown冷却时间

冷却时间是个i刚启动的ECCV2实例一个预热的事件，防止新EC2刚启动但是还未向外提供服务之前激活新的扩展活动，从而避免过多启动新机器。

    ■ Min最小实例数

最小实例数是指当前AS组中任何时候必须保持的最小的实例个数，一旦当前实例数不足，AS服务会自动启动新的实例。

    ■ Max最大实例数

最大实例数是指当前AS组中最多可以启动的实例数，一旦达到最大实例数，实例增加策略触发的实例扩展活动将不再有效。

    ■ Desired预期实例数

预期实例数是指当前AS组当前需要 的实例数，AS服务根据预期实例数与当前实例数的对比进行相应的扩展活动。

AutoScaling服务会去实时检测AS组里面实例的数量与desired数量，如果不相同，则会启动或者关闭实例来使得实际数量等于desired数量。不管是动态扩展、手动扩展还是定时扩展，其实都只是更改 desired 数量，不同的只是这是通过策略驱动去修改还是手工去改。

AutoScaling支持四种扩展方法：始终保持当前实例等级、手动扩展、按计划扩展、按需求进行扩展；

    ■  始终保持当前实例等级：实际上保持EC2 的数量不变，在出现健康EC2是进行替换；

    ■  手动扩展：在现有运行的Auto Scaling 的组中，手动添加EC2，并加入到组中；

    ■  按计划扩展：主要是设定时间点，在固定的时间执行EC2 的扩展，或者启动一个新的Auto Scaling组，无论当时机器负荷情况如何；

    ■  按需求进行扩展：此策略是Auto Scaling官方推荐策略，也是最自动话的扩展策略，此策略主要依托触发机制使用，当监控到达设定报警线后，会根据既定的要求，自动增加EC2 到已有的Auto Scaling 中，或者重新启动一个新的Auto Scaling 组；

在收缩策略上的方法，也是跟扩展策略的方法一一对应，除了按需收缩策略外，其他都是不需要兼顾EC2 当前的运行状态，所以，在选择取消那个在线的EC2时比较简单，而按需收缩策略上则需要判断怎么去终止EC2 ，这样才更贴合用户的场景需要。

Auto Scaling 为此，提供了5种终止策略方案，具体如下：

    ■  OldestInstance。Auto Scaling 终止组中最旧的实例。当Auto Scaling 组中的实例升级为新的EC2 实例类型，可以逐渐将较旧类型的实例替换为较新类型的实例时，此选项十分有用。

    ■ NewestInstance。Auto Scaling 终止组中最新的实例。如果要测试新的启动配置但不想在生产中保留它时，此策略非常有用。

    ■ OldestLaunchConfiguration。Auto Scaling 终止采用最旧启动配置的实例。如果要更新某个组并且逐步淘汰先前配置中的实例时，此策略非常有用。

    ■ ClosestToNextInstanceHour。Auto Scaling 终止最接近下个计费小时的实例。此策略最大程度使用实例并管理成本。

    ■ Default。Auto Scaling 使用默认终止策略。如果有多个扩展策略与该组关联，此策略非常有用。

利用弹性伸缩（auto-scaling）减少服务器成本，几乎适合所有集群式部署的网站/APP。设置也非常简单。

业务场景：

如果您的业务满足以下条件，花5分钟配置这个方案，可节省20%-30%成本：

     ■ 网站使用集群的方式，且集群超过1台以上的服务器；

     ■ 网站有较长时间的空闲。大部分网站的高峰时间不超过 8 个小时，剩下的 16 个小时的时间，完全可以把闲置的服务器作缩容处理。

以某休闲类网站为例，该网站 20：00-24：00 是访问高峰时段。

在CS私有云上，我们修改配置架构如图所示：

按照上述架构进行改造，原方案需要两台 4核4G 的 CVM，而现在，改成一台 4核4G 的 CVM + 每天4个小时临时CVM，能节省30%左右的计算资源。