知道弹性伸缩开始公测，马上申请了公测资格，开始体验传说中的弹性伸缩。在此之前，笔者都是靠手动完成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