设计弹性伸缩架构

Hello大家好，欢迎来到《AWS解决方案架构师认证 Professional(SAP)中文视频培训课程》，我们今天的课程内容为设计弹性伸缩架构，

我们开始今天的课程内容。

在我们讨论弹性伸缩内容之前，我们先讨论下与之相关的知识点—什么是垂直扩展和水平扩展。

垂直扩展和水平扩展

垂直扩展是指提升单个节点的自身的处理能力，比如通过升级节点的CPU，内存等硬件，这种通过升级原有的服务器或将其更换为更强大的硬件来提升单个节点的处理能力称为垂直扩展；比如对应AWS，就是通过改变或提升实例的类型和大小使其有更强的计算等能力，比如当工作负载增加时，将处理负载的实例从m5.large升级为m5.24xlarge, 这就是垂直扩展。需要注意垂直扩展是有上限的，上限取决于AWS提供的最大实例的大小。

那什么是水平扩展呢？

水平扩展指的是通过增加更多的节点来分散处理工作负载，从而实现节点计算等能力的扩展。对应AWS举例，比如我们之前处理某个工作负载使用了一台m5.large，当这个工作负载增加后，我们不是像垂直扩展去升级硬件，而是通过增加多台m5.large实例处理工作负载的方式就是水平扩展。当然，水平扩展对您的应用的架构设计是有要求的。另外水平扩展理论上是可以无限扩展的，除非将AWS的所有实例都用完了。可以通过不断的添加实例，分散工作负载从而提高处理能力。

那么问题来了，能不能将水平扩展自动化执行呢？当工作负载高的时候自动进行架构的水平扩展，通过添加更多的实例加快处理工作负载；而当工作负载恢复正常水平时在自动进行缩减实例数量以节省成本呢？当然是可以的，这就是我们接下来要讨论的弹性伸缩的内容。

设计使系统的容量可以弹性伸缩

我们先看一个案例，某公司开发了一款线上办公系统并已对外提供服务，左图是这套系统一周中每一天所使用的计算容量。

通过图中可以看到，因为是办公系统，周六和周日大部分公司放假访问量不高，所以使用的计算容量很低；周二和周三访问量最高，大概比周末高出6，7倍。

按照传统做法，可通过两种方式为线上办公系统这些容量变化做好规划。第一种是添加足够多的服务器，以便线上办公系统始终具有足够的容量来满足需求。周三系统的访问量最高，就按照周三的最大容量准备服务器，如果周三的访问量需要10台服务器提供服务，就会部署10台服务器。但是，这种做法的缺点是线上办公系统在某些天并不需要这么多容量。比如周末可能只需要1，2台服务器就可以满足系统需求。剩下的额外容量闲置不用，实际上提高了系统运行的成本。

第二种做法是只准备线上办公系统平均需求所需的容量。比如就准备6台服务器，可以满足一周中的4天的计算容量需求。这种做法成本更低，因为不用购买仅仅偶尔使用到的服务器。然而，这样做的风险是：当对系统的需求超过其可用容量时，比如尤其是周二和周三，可能造成糟糕的客户体验。

前面的两种方式都不是太理想，要么会浪费资源提高运行的成本；要么就是某些高峰时间点可能会给用户造成糟糕的用户体验。

那有没有更好的做法呢？答案是肯定的，通过设计使我们系统的容量可以弹性伸缩。对应AWS EC2，通过使用 Amazon EC2 Auto Scaling，可以仅在需要时才向应用程序添加新实例，并在不再需要这些实例时终止它们，因此只需在使用时为使用的实例付费。

比如对应我们这个案例，通过对Auto Scaling的配置，周三的时候办公系统访问量较大，Auto Scaling就会自动增加新的实例处理负载；而周四的时候系统访问量比周三少了一半，Auto Scaling会自动终止一些实例只保留满足系统需要的实例数量。这样的话我们就有了一个具有成本效益的架构，可在尽量减少支出的同时提供最佳客户体验。

EC2 Auto Scaling可根据业务需求和策略设置扩展选项，比如配置扩展策略在业务需求增长时自动为您增加实例以保证计算能力，在业务需求下降时自动减少实例数量以节约成本。

在认证考试中，经常会有题干描述的场景为应用系统一周中不同天或者一天的不同时间段业务量会有波动，有访问量波峰也有波谷，如一天的不同时间段，晚上高峰时间段的业务量可能最高，然后凌晨之后业务量可能会减少，问如何设计能够满足业务波峰时的容量并兼顾成本效益，这个时候就要注意很可能是Auto Scaling相关的考点。

当然Auto Scaling不仅适合业务量不断波动的应用程序，同时也适合业务量稳定的应用程序，这一点我们后面会讨论。

AWS爱好者网站的弹性伸缩

我们在看一个案例，AWS爱好者网站，里面有很棒的AWS视频课程和文章，很多同学和职场精英白天上完班，晚上下班回家吃了饭后，都会访问AWS爱好者网站来充电，提升个人的职场竞争力。网站的访问量在白天大家都上班的时候不是特别高，基本上1台实例就够了，CPU使用率大概20%左右；而到了晚上19点，大家都来网站看视频课程，这台实例可能CPU会突增到80%多的使用率，甚至有的时候CPU使用率会到100%，就会导致我的网站访问异常，造成不好的用户体验。（当然我们假设网站的带宽等其他指标都没问题，瓶颈是以为CPU使用率过高造成的）。

我们现在假设要通过EC2 Auto Scaling，实现弹性伸缩，白天运行一个实例提供服务，在晚高峰时，运行3个实例提供服务。

可以通过EC2 Auto Scaling，配置扩展策略，然后通过定义Auto Scaling组平均 CPU 使用率指标实现弹性伸缩。

我们可以定义规则，当Auto Scaling 组的平均 CPU 使用率大于70%时，新启动两台实例处理网站负载；然后在配置一个规则当Auto Scaling 组的平均 CPU 使用率小于25%时，终止2个实例。

这样的话，在白天网站访问量不是很高的时候，只会有1台实例提供网站服务，而到晚上19点后访问量上去后，当CPU使用率大于70%时，Auto Scaling会启动两台新实例处理网站负载，加上之前的1台实例，一共3台实例提供网站服务；而当22点之后，访问量下去之后，如果平均CPU使用率小于25%，Auto Scaling就会终止2台实例，继续保持最小容量1台实例运行。

这样的话，我们通过Auto Scaling服务，在网站访问量高的时候一共3台实例处理负载，提升了网站用户的体验；当访问量降低时，只保留1台实例处理负载，节省了成本。

弹性伸缩配置

我已经创建好了Auto Scaling组，as-test-group为我们已经创建的Auto Scaling组。
我将组的最小容量配置为1，最大容量配置为3 。

最小容量是指确保始终运行一定数量的实例，按照前面我们的案例，我设置的是1就代表无论怎么缩减这个Auto Scaling组始终会保持最少运行1台实例对外提供服务。如果设置为5呢？就代表始终会保持最少运行5台实例。

最大容量是指最大限制允许 Auto Scaling 根据需要向外扩展实例数，以满足增长需求。我们设置的是3，就代表这个Auto Scaling组最多可扩展为3个实例。

然后参照前面我网站的案例，我为这个Auto Scaling组配置了扩展策略，策略的内容当Auto Scaling组的平均 CPU 使用率大于等于 70%时添加2台实例；当Auto Scaling组的平均 CPU 使用率小于 25% 删除2台实例。

这个平均 CPU 使用率大于等于 70%以及小于25%实际上是通过我在cloudwatch中配置的警报，然后将cloudwatch警报与当Auto Scaling组相关联，这样当 CloudWatch 警报处于 ALARM 状态时，Auto Scaling组就会执行相应的添加和删除实例的动作。

我们到cloudwatch控制台看下。

我们在前面Auto Scaling组关联的两个警报实际上是在cloudwatch这里定义的，可以看到警报的条件， CPU 使用率大于等于 70%以及小于等于25%，然后配置Auto Scaling组将其相关联，当对应 CloudWatch 警报处于 ALARM 状态时，Auto Scaling组就会执行相应的添加和删除实例的动作。

关于Auto Scaling的具体配置我们会在后面的课程详细讨论和实操演示，所以学友们先做了解，后面的课程我们会介绍Auto Scaling的重要知识点，对创建和配置Auto Scaling做实操的演示。

好，以上就是我们今天的课程内容。