云计算设计模式（二十三）——Throttling节流模式

控制由应用程序使用，一个单独的租户或整个服务的一个实例的资源的消耗。这种模式可以允许系统继续运行并满足服务水平协议，即使当增加需求的资源放置一个极端载荷。

背景和问题

在云应用负载通常上变化的基础上的活动用户的数量或他们正在执行的活动类型的时间。例如，多个用户可能会在工作时间被激活，否则系统可能被要求在每月结束时执行计算昂贵的分析。也有可能是突然和意外的突发活动。如果系统的处理要求超过了可用的资源的能力，其将遭受性能不佳，甚至会失败。该系统可能必须满足的服务约定的水平，并且这种故障可能是不可接受的。

有许多策略可用于处理可变负载在云中，根据业务目标的应用程序。一种策略是使用自动缩放来在任何给定时间相匹配的供应资源给用户的需要。这具有始终如一地满足用户需求，同时优化运行费用的潜力。然而，尽管自动缩放可能会引发更多的资源配置，这配置是不是瞬间。如果需求快速增长，有可能是一个时间窗口，那里是一个资源赤字。

解决方案

另一种策略来自动缩放是为了让应用程序能够使用的资源最多只有一些软限位，然后油门当他们达到此限制。该系统应监测它是如何使用的资源，使得当使用量超过一些系统定义的阈值时，它可以调节来自一个或多个用户的请求，以使系统继续工作，并满足任何服务级别协议（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，门槛指定资源利用的软限制为止。在这一点上，系统可以开始向外扩展。然而，如果新的资源不成为可用的足够快地再现有的资源可能被耗尽，并且系统可能会失败。为了防止这种情况发生，系统被暂时限制，如前面所述。何时自动缩放已完成和额外资源，限制可以放宽。

问题和注意事项

在决定如何实现这个模式时，您应考虑以下几点：
•节流的应用程序，并使用策略，是一个建筑的决定，影响系统的整体设计。节流应在应用设计之初就被考虑，因为这是不容易的添加它一旦系统已经实施。
•节流必须迅速执行。系统必须能够检测活性增加，并相应地作出反应。该系统还必须能够恢复到原来的状态后快速负载有所缓和。这需要相应的性能数据是不断捕获和监测。
•如果一个服务需要暂时拒绝用户的请求，则它应该返回一个特定的错误代码，以使客户端应用程序理解为拒绝执行某种操作的原因是由于节流。客户端应用程序可以等待一段时间，然后重试该请求。
•节流可作为而系统autoscales一项临时措施。在某些情况下它可能是更好的简单节流，而不是按比例，如果在活动突发是突然的并且预计不会被长寿命，因为结垢可显着增加了运行成本。
•如果节流正在使用的临时措施，而一个系统autoscales，并且如果资源需求迅速增长，系统可能无法继续运作，即使在节流模式中操作时。如果这是不能接受的，考虑维护大容量的储备和配置更积极自动缩放。

何时使用这个模式

使用这种模式：
•为了确保系统持续满足服务水平协议。
•为了防止单一租户独占由应用程序所提供的资源。
•为了处理突发活动。
•为了帮助限制需要保持它运转的最大资源水平的成本优化的系统。

例子

图3示出了如何限制可以在多租户系统来实现。从每个租户组织的用户访问一个云托管的应用程序，他们填写并提交调查。应用程序中包含的仪器，用于监视在其中这些用户提交请求给应用程序的速度。

为了防止用户从一个租户影响应用的所有其他用户的响应性和可用性，限制施加到每秒从任何一个租户的用户可以提交请求的数目。该应用程序块请求超过此限制。

图3 - 在一个多租户应用程序中实现节流

本文翻译自MSDN：http://msdn.microsoft.com/en-us/library/dn589798.aspx