Azure设计模式之资源限制

资源限制模式

对应用程序实例、租户或服务使用的资源消耗进行控制。 这样，即使需求增加了资源的负载，系统也可以继续运行以满足服务可用性。

问题背景
云应用程序的负载通常会根据活动用户量或其执行的活动的类型随时间而变。例如，在运营时间内可能有更多用户处于活动状态，而系统在每个月末可能需要执行昂贵的计算成本分析。还可能会突然出现意外的活动量激增的情况。如果系统的处理要求超出了可用资源的容量，则系统性能将降低甚至会失败。如果系统必须满足所约定的服务可用性，则这样的故障是不可接受的。


有许多办法可用于处理云环境中的负载，具体取决于应用程序的业务目标。其中一个策略是使用自动缩放机制随时将资源分配与用户需求进行匹配。以满足用户需求，同时降低运营成本。不过，虽然自动缩放可能导致资源的预配，但此预配未必是实时的。如果需求增长快速，则可能有一段时间内出现资源不足。


解决方案
自动缩放的一种替代策略是仅允许应用程序是对资源的使用进行限制，当达到阈值时会对资源进行限制。系统应当监视资源的使用情况，以便在使用量超出阈值时可以限制用户请求。这将使系统保持正常工作并满足所实施的服务级别协议(SLA)。有关监视资源使用情况的详细信息，请参阅检测和遥测指南。（https://msdn.microsoft.com/library/dn589775.aspx）


系统可以实现多个限制策略，包括：
如果用户在指定时间内访问系统API的频率超过了每秒n次，则拒绝来自该用户的请求。这要求系统对运行应用程序的每个租户或用户使用的资源进行计量。有关详细信息，请参阅ServiceMeteringGuidance（服务计量指南）。https://msdn.microsoft.com/library/dn589796.aspx


禁用非基本服务功能或将其降级，以便基本服务可以有充足的资源运行。例如，应用程序对视频输出流进行处理时，则可切换到较低的分辨率。


使用负载调节来均衡活动量分配（在基于队列的负载均衡中有更详细地介绍-https://docs.microsoft.com/en-us/azure/architecture/patterns/queue-based-load-leveling）。在多租户环境中，该方法会降低每个租户的性能。如果系统必须支持混合使用不同SLA的租户，重要租户的工作可以立即执行。其他租户的请求可以推迟，并在负载得到缓解时再进行处理。可以使用优先队列模式来实现。（https://docs.microsoft.com/en-us/azure/architecture/patterns/priority-queue）


推迟以优先级应用程序或租户的身份执行的操作。可暂停或对这些操作进行限制，但是要有一个异常来通知租户系统正忙请稍后重试。下图显示了一个面积图，其中显示了使用三项功能的应用程序在一段时间内的资源使用情况（包括内存、CPU、带宽和其他因素）。一项功能是一个功能区域，例如，执行一组特定任务的组件、执行复杂计算的代码段，或者提供内存缓存等服务。这些功能的标签为A、B 和C。



表示某项功能线的正下方区域表示应用程序在调用此功能时所占用的资源。例如，表示功能A的线条下方的区域显示了使用功能A的应用程序使用的资源，功能A和功能B的线条之间的区域表示调用功能B的应用程序使用的资源。将每个功能的区域合起来表示系统的资源使用总量。


上图阐述了延迟操作的效果。在时间T1之前，分配给使用这些功能的应用程序的资源达到了阈值（资源使用量限制）。此时，这些应用程序面临可用资源耗尽的危险。在系统中，功能B没有功能A或功能C重要，因此已暂时将其禁用并释放其使用的资源。在时间T1和T2之间，使用功能A和功能C的应用程序正常运行。最终，这两项功能的资源使用量降低，到时间T2时已有足够的资源使功能B重新运行。还可以组合使用自动缩放和限制方法来维持应用程序的响应能力并满足SLA。如果预计需求会保持在高位，则在系统横向扩展期间，限制是一种临时方案。可以还原系统功能。下图显示了一个面积图，其中显示了在系统中运行的所有应用程序在一段时间内使用的总资源，并展示了可以如何将限制与自动缩放组合使用。


系统在时间T1时达到了资源使用量阈值。此时，系统可以开始横向扩展。不过，如果没有可用资源，则可能会耗尽现有资源，系统可能会不可用。为防止发生此情况，会暂时对系统进行限制，如上文所述。当自动缩放已完成并且附加的资源可用时，可以放宽限制。

问题和注意事项
在决定如何实现此模式时，应考虑以下几点：
限制应用程序和要使用的策略是一个全局决策，它会影响系统的整体设计。 在应用程序设计过程中应尽早考虑加入限制策略，因为在系统部署后不容易添加这项功能。
限制必须快速执行。系统必须能够检测活动量的增加并相应地作出反应。在负载减轻后，系统还必须能够快速恢复其原始状态。这需要持续监视性能数据。
如果某个服务需要暂时拒绝用户请求，则它应当返回一个特定的错误代码，以便客户端应用程序能够了解拒绝执行操作的原因是由于受到了限制。客户端应用程序可以等待一段时间，然后重新请求。
在系统进行自动缩放期间，可以使用限制作为临时措施。在某些情况下，如果活动量激增是突发性的并且预计不会持续太长时间，则仅进行限制而不进行缩放可能更好，因为缩放可能会增加运行成本。
如果在系统进行自动缩放期间使用限制作为临时措施，并且资源需求的增长非常快速，则—即使在受限制模式下运行，系统也可能无法正常工作。 如果这是不可接受的，考虑预留更多的资源并配置更积极的自动缩放机制。

何时使用此模式
在以下情况可以使用该模式：
需要确保系统继续满足服务可用性协议。
防止单租户独占太多应用程序提供的资源。
处理活动量突发的情况。
通过限制使系统系统最大化的使用资源，优化运营成本。

例子
最后一幅图显示了如何在多租户系统中实现资源限制。每个租户公司中的用户访问云托管应用程序，并填写并提交调查表。应用程序包含了检测机制，用以监视这些用户向应用程序提交请求的速率。


为了防止一个租户中的用户影响到应用程序对所有用户的响应能力和可用性，可对租户用户每秒可以提交的请求数进行限制。应用程序会阻止超出了这个限制的所有请求。


相关阅读
实现此模式时，以下模式也可能相关：

检测和遥测指南（https://docs.microsoft.com/en-us/azure/architecture/best-practices/monitoring）。 在进行限制的同时收集关于服务使用程度的信息。本文介绍了如何生成和捕获自定义监视信息。

服务计量指南（https://msdn.microsoft.com/library/dn589796.aspx）。 这篇文章介绍了如何统计服务的使用量以便了解它们的使用情况。这些信息可用于决定如何对服务进行限制。


自动缩放指南（https://docs.microsoft.com/en-us/azure/architecture/best-practices/auto-scaling）。 可将限制用作系统自动缩放期间的临时措施，或者使用它来完成系统自动缩放的需求。这里包含了关于自动缩放策略的信息。

基于队列的负载均衡模式

（https://docs.microsoft.com/en-us/azure/architecture/patterns/queue-based-load-leveling）。基于队列的负载均衡是用于实现资源限制的常用方式。队列可充当缓冲区，用来控制将应用程序请求发送到服务的速率。

优先队列模式（https://docs.microsoft.com/en-us/azure/architecture/patterns/priority-queue）。 系统可使用优先队列作为限制策略的一部分来保证关键或重要应用程序的高性能，同时适度降低不太重要的应用程序的性能。