什么是可伸缩性?

已完成

在企业环境中,增长可能有益。 但如果你没有充分的准备,增长速度过快也可能带来问题。 其中一个问题是影响按照设计无法处理流量暴增情况的应用程序和服务的可靠性增长。

对于客户和用户来说,中断就是中断。 他们不知道也不在意自己无法访问你的站点是因为你的站点代码有 bug,还是代码完全没问题但同时尝试使用站点的其他用户过多。

可伸缩性即适应增加的需求或不断变化的需要的能力。 你的应用程序和服务必须能够处理更大量的工作负载以适应增长。 可缩放的应用程序能够处理随时间逐渐增加的请求,而不会对可用性或性能产生负面影响。

在本单元中,你将了解可伸缩性和可靠性之间的关系、容量计划对于实现可伸缩性的重要性,并简要回顾与缩放相关的一些基本概念和术语。

可伸缩性/可靠性的关系

好消息是,提升应用程序的可伸缩性可能也会提升其可靠性。 例如,如果你的系统自动缩放,那么当单个虚拟机上出现组件故障时,自动缩放服务会另外预配一个实例,以满足最低虚拟机 (VM) 计数要求。 系统变得更加可靠。 在另一个示例中,你使用的是本质上可缩放的更高级服务(例如 Azure 存储)。 如果有存储问题,服务会创建为可靠服务,因此会复制数据。

下面是一个类比:想象一下大楼外常见的缓坡,它是最初是为适应坐轮椅的人而设计的。 它们能够满足这一目的。 但是,用婴儿车或手推车推婴幼儿的父母,或者觉得两层阶梯之间相隔太远或太高的小孩也会使用缓坡。 这种用法是间接的好处。

可靠性通常是可伸缩性的间接收益。 如果将系统设计为可缩放,则它们很可能也会更可靠。

可伸缩性和容量计划

容量计划涉及确定满足当前和未来的需求所需的资源。 进行该计划时,需要分析当前资源使用情况,然后预测将来的增长。

要估计未来的容量需求,应考虑的因素可以有:

  • 预期业务增长
  • 周期性波动(季节性等)
  • 应用程序约束
  • 确定瓶颈和限制因素

还需要设置服务级别目标,以便创建容量管理计划,使其能够在工作负载和环境发生变化时可靠地满足或超越这些目标。

容量计划是一个循序渐进的过程。 在本模块中,你将了解如何明确应用程序组件的资源需求。

概念和术语

你需要先了解与缩放相关的一些基本概念和基础术语,才能充分理解将在本模块中遇到的概念和策略。

  • 纵向扩展:增大组件容量,以便处理增加的工作负载。 这也称为垂直缩放。
  • 横向扩展:添加更多组件或资源以在分布式体系结构中发散负载。 例如,使用在一组前端后具有多个后端的简单体系结构。 随着负载的增加,我们会添加更多后端(和前端)服务器来处理它。 这也称为水平缩放。
  • 手动缩放:需要人工操作才能增加资源量。
  • 自动缩放:系统根据负载自动调整资源量。 准确地说,系统会随负载增加而增加资源量,也会随负载减少而减少资源量。
  • DIY 缩放:自助式缩放,使用这种方式时必须配置自动缩放。
  • 固有缩放能力:有的服务本身设计为可缩放,它们可以在幕后处理这种缩放,不需要你进行任何干预。 从你的角度看,这些服务几乎是可以无限缩放的,因为你不需要对其进行手动预配就可以使用更多资源。

Tailwind Traders 体系结构

在此模块中,我们将使用名为 Tailwind Traders 的虚构硬件公司的示例体系结构。 其电子商务平台如下所示:

Full architecture diagram of applications with frontend, backend and other components.

乍一看,此图表相当复杂,因此我们来总体浏览一下。 网站具有前端。 如果前往 tailwindtraders.com,这就是与你互动的对象。

Full architecture diagram of application with frontend component highlighted.

该前端与一组后端服务通信。 这些后端服务包含常见项目,如优惠券服务、购物车服务、库存服务等。 它们都在 Azure Kubernetes 服务中运行。 在此应用程序中,还运行着其他部件和技术。 你只需要关注前端和在 Kubernetes 上运行的后端服务就行了。

Full architecture diagram of application with backend component highlighted.

单一故障点

现在,你已了解整个体系结构,接下来我们花点时间来审视单一故障点,以及考虑缩放时可以注意的地方。

Full architecture diagram of application with backend components and SQL DB highlighted.

所有这些服务都是单一故障点 - 设计时未考虑复原能力或缩放能力。 如果其中一项服务过载,系统很可能会崩溃,并且没有办法立即解决这一问题。

在本模块的稍后部分,我们将探讨设计这些服务以提高其可伸缩性和可靠性的其他方式。

预配的容量

让我们看看另一个可能很麻烦的问题。 下面是需要我们预配容量的服务/组件:

Full architecture diagram of application with Azure AI services, Cosmos DB, and SQL DB highlighted

例如,对于 Cosmos DB,我们会预配吞吐量。 如果超过这些限制,我们将开始向客户返回错误消息。 对于 Azure AI 服务,我们要选择层,而该层每秒可处理的请求数有上限。 达到任一限制后,客户端都会受到限制。

流量中显著的峰值(如启动新产品)是否会让我们达到这些限制? 目前还不知道。 我们将在本模块的稍后部分查看这个问题。

成本

即使我们的工作方式都是对的,仍然需要为业务增长制定计划。 下面是按使用付费的服务:

Full architecture diagram of application with Azure Logic Apps and Azure Functions highlighted.

在这里,我们使用了 Azure 逻辑应用和 Azure Functions,它们都是无服务器技术的示例。 这些服务会自动缩放,按请求计费。 你的帐单会随着客户群的增长而增长。 应该至少要注意即将到来的活动(例如产品发布会)可能对云支出产生的影响。 我们还将在本模块的稍后部分学习如何理解和预测云支出。

知识检查

1.

使应用程序或服务更易于缩放还可使其具有以下优势:

2.

使应用程序或服务更易于缩放还可使其具有以下优势:

3.

添加更多组件或资源以在分布式体系结构中发散负载,这种操作称为: