跳至主要內容

弹性扩展

Znyoung网络云计算

云上架构最重要的且最大的优势就是弹性。谈到弹性伸缩,基本上会想到之前学过的服务器与负载均衡一起使用的黄金搭档组合。弹性伸缩是个很宽泛的概念,一切云中的服务都具有弹性。

弹性伸缩说明

弹性伸缩是一项基础设施自动化的服务。弹性伸缩的主要目的是根据所监控的数据实现资源的动态平衡以达到期望值,为用户所用。弹性伸缩让我们可以根据业务需求和策略自动调整算力,典型的场景就是服务器。在业务突增时,提升服务器的个数,保障算力的平稳运行,在业务低谷期,释放多余算力,节约算力、优化成本。

我们以在线协同办公软件为例,来说明一下自动伸缩的优势。如图 1 是一个在线办公软件的一周使用量的柱状图,横轴为星期数,纵轴为容量数。

img
img

在一周的开始,员工们开始上班,所以周一的服务使用量较周末明显升高,周二、周三持续升高并达到峰值,周五使用率下降,直至周末恢复到低水位水平。

按照传统的做法,解决方案架构师有两种方案,一是以周三最高使用峰值作为基准,一周都添加足够多的服务器来满足员工的需要;二是以一周内的平均容量作为服务器的数量基准。这两种方案都不太完美,接下来,我们分别来看看二者所存在的问题。

如果我们使用方案一,那么这个方案可以很好地满足我们的需求,服务器的数量永远大于等于实际所需算力的数量,服务正常且稳定运行。但这种做法的缺点是浪费了本不该浪费的算力,提高了成本,而且服务的高低分值差别越大,浪费的算力就越多。

img
img

第二种方法是以平均使用量作为服务器的基准,这种方式虽然能减少费用,但提高了服务的风险,如果服务器不足以支撑超出的算力,那么可能会导致服务卡顿甚至失效,直接影响业务。

img
img

既然两种方法都不太科学,那我们可不可以根据实际的用量自动地增减服务器的算力呢?当然可以,弹性伸缩就是解决这个问题的。我们可以利用弹性伸缩,让我们的服务器始终保持略高于真实需求的状态,这样能够在保证算力的前提下,最大限度地节省成本,实现降本增效的效果。

img
img

弹性伸缩的方式

在继续讲解扩展策略前,我们需要提前了解一下扩展的方式。扩展方式分为 Out 和 Up,Out 是向外扩展,也就是扩展机器的数量。Up 是向上,通过提升自身硬件水平来扩展。通常我们所说的扩展一般指水平扩展。在分布式架构中,扩展的正确做法是水平扩展无状态服务,而不是垂直扩展。

  • Scaling Out:横向扩展也叫水平扩展,用更多的节点来支撑更大量的请求。比如说,增加服务器的个数。
  • Scaling Up:纵向扩展也叫垂直扩展。扩展一个点的能力来支撑更大的请求。比如说,升级 CPU 和内存。
img
img

弹性伸缩策略

为了更加适应扩展的需求,弹性伸缩通常会有以下几种策略或更多。

img
img

不同策略的选择是不同的,如果有这么一个场景:一个应用程序在云主机中运行。这些云主机部署在负载均衡器之后的自动伸缩组中运行。当 EC2 实例的 CPU 利用率达到或接近 40% 时,应用程序的性能最好。

问:如果你是解决方案架构师应该使用什么策略来保持组中所有实例达到最佳的性能?

由于服务器在 CPU 使用率达到 40% 的时候性能最佳,所以我们就应该为我们的自动伸缩组设置一个期望的值,比如将期望值设置为 40%,让自动伸缩组根据 CPU 的变化动态调整范围。CPU 高于预期,就增加服务器的量,让负载平均,CPU 低了,就减少服务器的量,让 CPU 升回 40% 的阈值,弹性伸缩服务会尽可能让服务器朝着人为预期的期望值走。

再比如,一家在线旅游公司有一个 App 应用部署在云主机中。公司预计在五一小长假期间会出现比平时高三倍的流量高峰,希望能给用户提供良好的用户体验。解决方案架构师如何满足这一需求?

在这个场景中,流量是可以前期预测的,并且时间上也是可以预测的。那么我们就可以设置自动伸缩的规则,比如五一前一天晚上 6 点,用户可能就下班登录 App 进行次日旅游的计划了。所以我们可以设置一个计划内的定时伸缩计划,计划在五一前后各一天执行计划操作。4 月 30 日开启扩容,设置服务器的数量为先前的四倍,当五月三号的时候,用户大多旅游完回家,那么我们就可以在 4 号的时候,将服务器的数量降至伸缩前的水平,这样就能保证用户良好的体验。

弹性扩展

上述例子所讲解的弹性扩展面较窄,但是是弹性伸缩最经典的例子。如果只拿服务器来指代弹性扩展,可能会有失公允。弹性扩展遍布云计算中的大多数云产品,是云架构方案的核心思想之一。根据云产品的不同,弹性扩展也分为好几种类型,如弹性容量、弹性算力、弹性吞吐量、弹性带宽等。

img
img

弹性扩展的实际时间单位粒度也有不同,可以是月、周、日这种较大颗粒度的扩展,这种扩展一般是已知的、可预测的、呈周期性的静态工作负载。另一种是叫做千载难逢的工作负载,是特殊的、可预测的、周期性静态工作负载,也有基于分钟级甚至秒级的细颗粒度的弹性需求,如容器、Lambda 这类服务,我们归结为不可预测的工作负载。不可预测的工作负载对工程师的要求较高,程序能否在大量突增状态下进行弹性扩展且不影响体验,是判断一个架构优秀与否的必要条件。

img
img
上次编辑于:
贡献者: 麦正阳