控制由应用程序使用，一个单独的租户或整个服务的一个实例的资源的消耗。这样的模式能够同意系统继续执行并满足服务水平协议。即使当添加需求的资源放置一个极端载荷。
背景和问题
在云应用负载通常上变化的基础上的活动用户的数量或他们正在执行的活动类型的时间。
比如。多个用户可能会在工作时间被激活，否则系统可能被要求在每月结束时执行计算昂贵的分析。也有可能是突然和意外的突发活动。假设系统的处理要求超过了可用的资源的能力，其将遭受性能不佳，甚至会失败。
该系统可能必须满足的服务约定的水平，而且这样的故障可能是不可接受的。
有很多策略可用于处理可变负载在云中，依据业务目标的应用程序。一种策略是使用自己主动缩放来在不论什么给定时间相匹配的供应资源给用户的须要。这具有始终如一地满足用户需求。同一时候优化执行费用的潜力。然而，虽然自己主动缩放可能会引发很多其它的资源配置。这配置是不是瞬间。假设需求高速增长，有可能是一个时间窗体，那里是一个资源赤字。
解决方式
还有一种策略来自己主动缩放是为了让应用程序能够使用的资源最多仅仅有一些软限位，然后油门当他们达到此限制。
该系统应监測它是怎样使用的资源。使得当使用量超过一些系统定义的阈值时，它能够调节来自一个或多个用户的请求。以使系统继续工作，并满足不论什么服务级别协议（SLA），该已到位。有关监控资源使用情况的具体信息。请參阅仪器和遥測指导。
该系统能够实现多种限制策略。当中包括：
•从谁已经訪问系统API超过每秒n次超过给定时间内的个人用户拒绝请求。这就要求系统米利用资源用于执行应用程序的每一个租户或用户。欲了解很多其它信息。请參阅服务计量指引。
•禁用或有辱人格的选择不必要的服务的功能，以便必要的服务能够提供足够的资源执行畅通。
比如，假设应用程序是视频流输出，它能够切换到一个较低的分辨率。
•使用负载均衡来平滑活动量（这样的方法是覆盖在由基于队列的负载均衡模式的很多其它细节）。
在多租户环境中，这样的方法将降低为每一个租户的性能。
假设系统必须支持的住户有不同的SLA的组合，为高价值租户的工作可能会被马上执行。请求其它住户能够忍住，以及时处理积压有所缓解。
优先级队列模式，能够用来帮助实现此方法。
•代表低优先级的应用程序或租户被推迟执行的操作。这些操作能够暂停或削减。异常生成的通知。该系统正忙。该操作应该稍后重试房客。
图1示出一个区域图进行资源利用率（存储器。CPU，带宽，以及其它因素的组合）对时间对于正在使用的三个特征的应用程序。
一个特征是功能性的区域。比如。执行特定的任务集，一个代码段。执行一个复杂的计算，或者。提供了一个服务。比如在内存中缓存的元素的组分。这些特征被标记为A，B和C.
图1 - 对时间的曲线图的资源利用率代表三个用户执行的应用程序
注意：
马上行功能下的区域表示应用程序中使用时，调用此功能的资源。比如，以下的线为特色的一个区域显示使用的是正在使用的功能A的应用资源。并为特征A和特征B线之间的区域被使用的应用程序调用功能B.汇总的指示资源对于每一个特征区域显示了系统的总的资源利用率。
在图1中的曲线示出了延迟操作的效果。
仅仅是之前的时间T1。分配给使用这些功能的全部应用程序的总资源达到一个阈值（资源利用的软限制）。在这一点上。应用程序是在用尽可用的资源的危急。在这个系统中。特征B比特点A或特征Ç不太重要，所以它是暂时禁用，而且它被使用的资源被释放。之间的时间T1，T2，使用功能A和功能C中的应用程序继续执行正常。最后。资源利用这两个功能减退的点时。在时间T2时，有足够的容量，以再次启用功能B中。
该自己主动缩放和调节方法也能够结合，以帮助保持应用程序响应和SLA之内。假设需求估计将保持高位，节流能够提供一个暂时的解决方式。同一时候在系统扩展了。
在这一点上。该系统的全部功能能够恢复。
图2示出了总体的资源利用通过在与时间的系统中执行的全部应用程序的区域图，并示出了怎样限制可与自己主动缩放组合。
图2 - 图表显示自己主动缩放与节流相结合的效应
在时间T1，门槛指定资源利用的软限制为止。在这一点上，系统能够開始向外扩展。然而，假设新的资源不成为可用的足够快地再现有的资源可能被耗尽。而且系统可能会失败。为了防止这样的情况发生。系统被暂时限制，如前面所述。何时自己主动缩放已完毕和额外资源，限制能够放宽。
问题和注意事项
在决定怎样实现这个模式时，您应考虑以下几点：
•节流的应用程序，并使用策略。是一个建筑的决定，影响系统的总体设计。节流应在应用设计之初就被考虑，由于这是不easy的加入它一旦系统已经实施。
•节流必须迅速执行。系统必须能够检測活性添加，并对应地作出反应。
该系统还必须能够恢复到原来的状态后高速负载有所缓和。
这须要对应的性能数据是不断捕获和监測。
•假设一个服务须要暂时拒绝用户的请求，则它应该返回一个特定的错误代码。以使client应用程序理解为拒绝执行某种操作的原因是由于节流。
client应用程序能够等待一段时间，然后重试该请求。
•节流可作为而系统autoscales一项暂时措施。
在某些情况下它可能是更好的简单节流，而不是按比例，假设在活动突发是突然的而且估计不会被长寿命，由于结垢可显着添加了执行成本。
•假设节流正在使用的暂时措施。而一个系统autoscales。而且假设资源需求迅速增长。系统可能无法继续运作，即使在节流模式中操作时。假设这是不能接受的，考虑维护大容量的储备和配置更积极自己主动缩放。
何时使用这个模式
使用这样的模式：
•为了确保系统持续满足服务水平协议。
•为了防止单一租户独占由应用程序所提供的资源。
•为了处理突发活动。
•为了帮助限制须要保持它运转的最大资源水平的成本优化的系统。
样例
图3示出了怎样限制能够在多租户系统来实现。
从每一个租户组织的用户訪问一个云托管的应用程序。他们填写并提交调查。
应用程序中包括的仪器，用于监视在当中这些用户提交请求给应用程序的速度。
为了防止用户从一个租户影响应用的全部其它用户的响应性和可用性，限制施加到每秒从不论什么一个租户的用户能够提交请求的数目。
该应用程序块请求超过此限制。
图3 - 在一个多租户应用程序中实现节流
