我们编写 的每个服务 应用程序组件都需要一些资源才能正确执行和运行。 准确预测需要多少资源几乎是不可能的,因为有很多运动部件会影响它。 所需的内存、CPU 或网络带宽量可能会随着工作量的变化而使用应用程序生命周期进行更改。 几乎所有的应用程序都有我们必须始终满足的性能要求。 随着工作负载的变化,我们必须能够保持所需的性能水平。 这是 Azure 自动缩放发挥作用的地方,因为 Azure 自动缩放是一种机制,我们可以用它来实现此目的。

 

Autoscaling

在下面的图 1 中,存在资源的应用程序负载和资源的总限制。 当自动缩放未到位时,将 用户 已连接且将要连接到 Web 应用程序的用户可能会面临性能 问题 由于可用资源的限制,它达到了中描述的阈值点 图1.2 并且无法应付交通。 但是,当您查看图 2 时,您可以看到,随着流量和应用程序负载,可用资源同时增加。 这是自动缩放的优势。

 

Azure 自动缩放空闲方案

图1

 

Azure 自动缩放阈值

图 1.2

 

图2

 

Azure 中的计算解决方案

  • 应用程序服务. Azure 应用服务是一种完全托管的 Web 托管服务,用于构建 Web 应用、移动后端和 RESTful API。 从小型网站到全球扩展的 Web 应用程序,Azure 具有符合您需求的定价和性能选项。
  • Azure 云服务。 Azure 云服务是平台服务 (PaaS) 的示例。 与 Azure 应用服务一样,此技术旨在支持可扩展、可靠且运行成本低廉的应用程序。 您可以在使用 Azure 云服务的 VM 上安装自己的软件,也可以远程访问它们。
  • Azure 服务结构。 Azure Service Fabric 是一个分布式系统平台,可轻松打包、部署和管理可扩展且可靠的微服务和容器。 Service Fabric 是用于构建和管理这些在容器中运行的企业级、第 1 层和云级应用程序的下一代平台。
  • Azure 函数。 Azure 函数允许开发人员通过连接到数据源或消息传递解决方案来操作,从而便于处理和响应事件。 开发人员可以利用 Azure 函数构建可由各种应用程序、移动和 IoT 设备访问的基于 HTTP 的 API 终结点。
  • 虚拟机 。 Azure 虚拟机将使我们能够在云中创建和使用虚拟机作为基础架构即服务。 我们可以使用 Azure 或合作伙伴提供的映像,也可以使用自己的映像创建虚拟机。

 

自动缩放的类型

 

垂直自动缩放

垂直缩放意味着我们修改 VM 的大小。 如果我们需要具有更多硬件资源的更大的 VM,我们会进行扩展;另一方面,我们缩小规模,以防我们不需要所有可用的资源,并且我们想要减小 VM 的大小。 在此 VM 中托管的应用程序在这两种情况下保持不变。 这种类型的 扩展效率不是很高,尤其是在云环境中,因为资源消耗没有得到优化。 另一个主要缺点是需要停止虚拟机的大小才能更改。 这会影响我们的应用程序,因为它必须在停止、调整大小和重新启动 VM 时脱机,并且这些操作通常非常耗时。 当然,我们可以保持 VM 不变,但可以预配具有所需大小的新虚拟机,并在新 VM 准备就绪后移动应用程序。 这仍然要求我们的应用程序在移动时处于脱机状态,但移动应用程序的过程 要短得多

垂直缩放

图3

 

垂直缩放应用程序不可用

图 3.1 – 当垂直缩放到位时,应用程序将变得不可用,因为它需要时间重新启动。

 

水平自动缩放

水平缩放意味着我们修改正在运行的 VM 的数量,通过将负载划分到同一 VM 的多个实例中来保持所需的性能。 虚拟机的大小保持不变。 我们只通过向外扩展来增加它们的数量,或者通过扩展来一次减少运行 VM 的数量。 通过使用此方法,我们可以从小型 VM 大小开始,并保持资源消耗尽可能最佳。 此外,我们的应用程序没有停机时间,因为应用程序始终至少有一个实例在运行。 水平缩放需要负载均衡器,以便在运行中的 VM 之间均匀分配负载。 但幸运的是,Azure 开箱即用,我们这边不需要执行任何操作。

 

水平缩放

图 5. 流量增加时缩小。

 

水平缩放流量减少

图 5.1 – 流量减少时缩小。

 

监视和警报

有许多方法可以监视 Azure 上是否向服务添加了其他资源,其中一些资源相当复杂,例如服务的缩放边栏选项卡(本例中为虚拟机缩放集,图 6)。 这是管理员首选的方法,但所有者和参与者不会首选此方法。 用户要能够查看,我们需要登录到 Azure 门户,这对于用户来说可能非常耗时。

虚拟机规模集

图6

 

警报

您可以选择在自动横向扩展和横向扩展时通知用户(应用服务)。

 

Azure 自动缩放警报

图7

 

默认情况下,应用程序见解用于应用服务,它为我们提供了有关服务器响应时间、请求等的见解。

 

应用程序洞察

图 8. 应用程序见解,显示应用服务接收的请求的平均服务器响应时间。

 

这是如何在应用服务中配置自动缩放。 首先,转到横向扩展配置 > 添加 > 缩放条件 > 选择适当的指标,如 CPU、RAM、请求等。 > 保存并完成。

 

配置自动缩放

图9. 在应用服务计划中配置自动缩放条件

 

使用 Azure 自动缩放时,无需担心如何实现负载均衡器、 流量管理器等。 Azure 管理所有内容。

注意: 独立 VM 需要额外的配置。 但是,虚拟机缩放集在自动缩放时不需要执行任何管理操作。 自动创建负载均衡器。

Azure 应用服务具有由 Azure 处理的盲自动缩放方法,您看不到资源中单独使用的服务。 相反,它消除了任何管理开销。 用户感觉很少或没有性能问题,记住自动缩放已实现。 Azure 处理大部分自动缩放部分,除了指定自动缩放条件外,用户还没有太多的工作可做。 一切都处理得很顺利。

自动缩放运行历史记录

 

在图 10 中,有一个 VMSS(虚拟机规模集),当您提到的条件被证明是真的时,它会自动缩放。

 

带负载均衡器的虚拟机规模集

图10. 虚拟机规模集与负载均衡器。

 

 

测试 Azure 自动缩放

测试是 Web 应用程序不可分割的一部分。 如果没有测试,我们无法确定Web服务器是否可以处理流量,为此,我们执行测试。 压力测试, 负载测试是测试的几个示例。 若要纯粹在 Azure 上处理它,请在 Azure 门户中注册 DevOps 组织,创建一个项目,然后你将重定向到以下 页面

 

Azure DevOps 仪表板

图 11. 用于测试的 DevOps 仪表板

 

Azure DevOps 测试计划

图 12. 您可以添加用于测试目的的 URL,并查看用于测试的服务的指标。

 

按实例显示的平均 CPU 百分比

图 13. VM 上测试的应用程序的 CPU 图。

 

示例结果获取 API

图 14. GET API 的示例结果 ,其中包含响应时间、用户负载、每秒请求数等详细信息。

 

使用 LoadView 验证 Azure 自动缩放是否正常工作

正如我们现在知道的,当达到 CPU、RAM 和 IO 的数量时,将发生自动缩放。 在图 15 中,当您针对某个 URL 或终结点运行测试时,此图包含在 LoadView 提供的报告中。 第一个图根据我们的负载测试策略访问站点的用户数量保持不变,因此在点之后,平均响应时间会大大增加。

LoadView 没有自动缩放的平均响应时间

图 15. 平均响应时间(不自动缩放)

 

然而,通过自动缩放,则具有优势。 在图 16 中,当用户增加时,托管 Web 应用程序的实例会根据条件进行扩展,因此自动缩放完成后,平均响应时间不会受到影响。 当用户不再连接时,为处理不可预知的负载而创建的实例将终止,并且只有初始计数保持不变。

 

LoadView 自动缩放的平均响应时间

图 16. 带自动缩放的平均响应时间

 

在图 17 中, LoadView 提供的负载测试提供了一种在会话不断增加时借助会话测试应用程序的方法,这有助于正确测试以及应用程序是否自动缩放。

LoadView 累积会话

图 17. 累积会话数

 

测试 Azure 自动缩放:结论

实现 Microsoft Azure 自动缩放时,不必担心如何实现负载均衡器、流量管理器等。 Azure 管理所有内容,并确保运行的资源量正确,以处理测试的应用程序的负载。 但是,使用 LoadView 等解决方案可确保自动缩放运行正确,并且您的用户在添加资源时不会遇到任何性能下降。

亲自尝试 LoadView,并收到了多达 5 次免费负载测试以启动