何为弹性伸缩

弹性伸缩逐渐成为了各大服务器厂商的标准配置，本篇我们来简单的说一下何为弹性伸缩，它又具有怎样的作用。

1.什么是弹性伸缩

弹性伸缩（Auto Scaling）是根据业务需求和策略自动调整计算能力（即实例数量）的服务。简单说就是它会根据服务器的使用情况，自动的新增和缩减服务器实例数。

最简单的例子，就如微博，在没有什么火爆热点的情况下，它的服务器是正常的运行，但是如果突然有一个大新闻爆出来，例如拜登被车创死了，那这天它的用户访问量肯定激增，平时的服务器肯定是无法承受这么大的压力的，就需要进行扩容，也就是多启一些实例然后分流访问。但是哪怕有人24小时不间断的坐在电脑前准备扩容服务器，也难免会反应不及，一旦反应不及时，整个服务器都会崩掉，造成相当大的影响。然后当大家瓜吃完了，又回到平日时，他还得把新增的实例一个个的关掉，避免浪费资源。

而弹性伸缩，就是把这个扩容和缩减服务器实例数的操作智能化、自动化，这样既能节省人力，也比人力做的更靠谱和稳定。

2.如何进行弹性伸缩

虽然怎么实现是各大厂商该考虑的事，但是我们也可以简单的分析一下。

首先我们拥有一个简单的服务，它只需要一台服务器即可部署，我们也一直只是用这一台提供服务。

①扩充服务器

但是某天开始，服务的用户增多了，一台已经满足不了需求了，我们必须新加一台服务器。

这时候我们通过手动的方式，又买了一台服务器，然后手动部署上去。虽然有点麻烦，但是暂时够用了。

②运维平台管理服务器

随着用户的基数增多，我们的服务规模也在提升，这时候通过手动增减服务器数量，实在是太麻烦了，每次更新版本也很麻烦，还要一台一台重新部署。

所以我们接入了某个自动化运维平台，它可以通过更改实例数，自动的帮我们申请机器然后部署代码上去，而我们只需要通过平台的客户端改改配置点一点就能完成这些操作。

虽然比之前方便了许多，但是扩容缩减服务器仍需手动操作。

③定时任务

通过长期的运维统计，我们发现，每周五到周日，服务器都得扩容，从5个实例扩容到10个才能通顺的提供服务。这可能是因为放假了，使用的人变多了。

既然总结出了规律，我们就可以通过某种方式构建一个定时任务，每周五的时候将服务器实例数配置改为10，周一再将其改为5，然后自动通过运维平台执行这个操作。

方式有很多，就不给出了，总之我们现在可以不用每周都手动操作扩容了，算是解脱了。

④报警任务

直到某天，在一个不是周五到周日的日子，服务突然激增了很多访问量，由于太突然了。直接导致了服务崩溃的情况，过了好一会才反应过来，但是由于耽误了时间，一切都有点晚了。

于是我们在想，如果在服务器超负荷的时候，能发出报警，并自动扩容就好了。

总之我们经历了一番操作，将其实现了。通过监控接口访问频率，每当其到达我们预设的警戒线值时，就会自动发出警告邮件，并扩容两个服务器实例。而当其降低到我们预设的安全值时，再自动的缩减两台服务器，保持平稳。这就是一个简单的报警任务，我们还可以将其复杂化，甚至通过响应时间、吞吐量、CPU或内存占用情况去监测，不过那都需要更深入的研究了。

⑤弹性伸缩模块

我们将这一系列的脚本解耦出来，作为一个单独用于服务弹性伸缩的模块，并单独部署在一个服务器上。这样我们就可以将其整合到任何服务上了。

我们还可以对原服务所在的服务器和专门用于弹性伸缩的服务器进行区分，抽出一个概念，叫伸缩组，服务器的扩容和缩减都限制于这个组内，不会影响到最基本的原服务器。我们还可以为伸缩组设置不同的服务器配置。

⑥智能化自动管理

最后我们可以通过大数据等手段更智能化的进行弹性伸缩控制，例如通过机器学习，不断的分析这个服务在什么时刻可能处于访问高峰，什么时刻又会处于低谷，然后自动拉取配置一系列的定时和报警监测任务。

连这些定时或警告任务都智能、动态的配置了，一般情况下就更加不需要我们操心了。这种又叫可预测智能化，它分两种预测方式，一种是前置预测，通过历史数据，提前将服务器扩容好，这样在面对流量高峰时也是游刃有余的。另一种则是后置预测了，当一波流量高峰到来时，智能分析它需要扩容多少台服务器，而不是每次都两台两台的扩，这样就能更加灵活了。

3.结语

由于笔者也没有过多的接触弹性伸缩，所以也没有关于弹性伸缩的深入使用说明，本篇只作为一个对弹性伸缩的入门简单了解，帮助大家快速理解弹性伸缩的概念。