知道弹性伸缩开始公测，马上申请了公测资格，开始体验传说中的弹性伸缩。在此之前，笔者都是靠手动完成ECS数量的增加或者删除的。现在，就让我们先用为爽吧！
第一步，当然是要开通弹性伸缩服务。
在此先把我已开通的需要叠加弹性伸缩服务的资源给大家介绍下：
一个SLB实例，将HTTP请求按照会话保持的方式分发到后台ECS服务器。
两台ECS实例，安装了wordpress。
一个RDS实例，为多个wordpress应用服务器提供共享数据库服务。
在整个测试系统的部署位置如下图红色虚线内所示。
红色虚线外的资源为压力生成系统，主要分布在北京、杭州和深圳的阿里云数据中心。
再来观察一下当前系统的负载情况，通过云监控了解ECS在加压之前的负载情况。两天ECS的CPU使用率都在50%左右。
第二步，创建属于自己的第一个弹性伸缩组。名字就叫wordpress-elastic吧！选择SLB和RDS。伸缩组（Scaling Group）是具有相同应用场景的 ECS 实例的集合。伸缩组定义了组内 ECS 实例数的最大值、最小值及其相关联的 SLB 实例和 RDS 实例等属性。
紧接着按照提示创建伸缩配置
为了能够顺利执行这一步，请提前创建好自定义镜像。我的自定义镜像中已经提前安装了经过定制化的wordpress，以确保和线上的wordpress01和wordpress02的应用服务器版本和配置的一致性。
好了，确定一下弹性伸缩服务的状态吧。Wordpress-elatic伸缩组已启动，没有任何ECS伸缩活动。
第三步，加压给现有ECS。
事先录制好的测试脚本SLB02如下
压力系统将HTTP请求发向SLB
观察结果：
新扩展的两台ECS实例已经自动增加到了SLB的后端服务器列表：
结束语：
在短短的一个小时内，我已经借助阿里云的优势，快速体验了弹性伸缩服务的自动伸缩功能，成功进行测试RDS数据库的应用侧容量扩容。我们再来回顾下整个过程中系统架构在没有任何人工参与的情况下，发生了什么变化。
不变的是：
原有架构整体保持一致，负载均衡、应用服务器、数据库服务器位置均无任何变化。
变的是：
ECS数量由2个实例变成4个实例，应用服务器处理能力增加一倍。
以上就是我使用弹性伸缩服务的一点小经验了，希望能对大家有所帮助。
如果您想详细了解弹性伸缩服务相关体验，请访问：
https://bbs.aliyun.com/read/179518.html