因为有客服一直在全面的测试阿里云产品，在做压测过程中经常需要动态的调整ECS云主机的数量以确保能够给RDS提供合适的负载压力。在此之前，笔者都是靠手动完成ECS数量的增加或者删除的。现在，就让我们先用为爽吧！

第一步，当然是要开通ESS服务，请移步

http://www.aliyun.com/product/ess

开通很顺利，可以进入ESS控制台了

在此先把云郎已开通的需要叠加ESS服务的资源给大家介绍下：

一个SLB实例，将HTTP请求按照会话保持的方式分发到后台ECS服务器。

两台ECS实例，安装了wordpress。

一个RDS实例，为多个wordpress应用服务器提供共享数据库服务。

在整个测试系统的部署位置如下图红色虚线内所示。

红色虚线外的资源为压力生成系统，主要分布在北京、杭州和深圳的阿里云数据中心。

再来观察一下当前系统的负载情况，通过云监控了解ECS在加压之前的负载情况。两天ECS的CPU使用率都在50%左右。

第 二步，创建属于自己的第一个的ESS伸缩组。名字就叫wordpress-elastic吧！选择SLB和RDS。伸缩组（Scaling Group）是具有相同应用场景的 ECS 实例的集合。伸缩组定义了组内 ECS 实例数的最大值、最小值及其相关联的 SLB 实例和 RDS 实例等属性。

紧接着按照提示创建伸缩配置。

小提示，为了能够顺利执行这一步，请提前创建好自定义镜像。我的自定义镜像中已经提前安装了经过定过定制化的wordpress，以确保和线上的wordpress01和wordpress02的应用服务器版本和配置的一致性。

好了，确定一下ESS服务的状态吧。Wordpress-elatic伸缩组已启动，没有任何ECS伸缩活动。

第三步，加压给现有ECS。

事先录制好的测试脚本SLB02如下

压力系统将HTTP请求发向SLB

测试场景如下：

一切就绪，开压吧！

期待的结果：

现有ECS服务器wordpress01和wordpress02的负载超过85，按照ESS伸缩策略，将会最少加入2台新的ECS服务实例。

新加入的两台ECS应该被自动配置到实现定义的SLB后台服务器列表中。

新加入的两台ECS服务器实例在SLB负载分担下开始接受新的请求，wordpress01和wordpress02的负载开始下降。

第四步，观察自动伸缩结果

压力测试开始后，随着压力增大，我们看看发生了什么：

“Add “2” ECS ins…”

观察结果：

新扩展的两台ECS实例已经自动增加到了SLB的后端服务器列表：

结束语:

在短短的一个小时内，云郎已经借助阿里云的优势，快速体验了ESS弹性伸缩服务的自动伸缩功能，成功进行测试RDS数据库的应用侧容量扩容。

其实ESS除了自动配置SLB、自动扩容，还有自动收缩、定时伸缩、固定数量模式、自动配置RDS等其它功能。咋们也就来个“且听下回分解吧”。我们再来回顾下整个过程中系统架构在没有任何人工参与的情况下，发生了什么变化：

不变的是：

原有架构整体保持一致，负载均衡、应用服务器、数据库服务器位置均无任何变化。

变的是：

ECS数量由2个实例变成4个实例，应用服务器处理能力增加一倍。

一切按期望发生，事情够科学！，正所谓：

“ESS妙计安天下，扩了ECS又配SLB。弹性伸缩把忧解，按需调整有智慧“