云计算设计模式(二十三)——Throttling节流模式

云计算设计模式(二十三)——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门槛指定资源利用软限制为止。在这一点上,系统能够開始向外扩展然而,假设新的资源不成为可用的足够快地现有的资源可能被耗尽。而且系统可能会失败。为了防止这样的情况发生。系统被暂时限制,如前面所述。何时自己主动缩放已完毕额外资源限制能够放宽

问题和注意事项


在决定怎样实现这个模式时,您应考虑以下几点:
节流的应用程序,并使用策略是一个建筑的决定,影响系统的总体设计节流在应用设计之初考虑,由于是不easy的加入它一旦系统已经实施


节流必须迅速执行。系统必须能够检測活性添加,并对应地作出反应。

该系统必须能够恢复到原来的状态后高速负载有所缓和。

这须要对应的性能数据是不断捕获监測。
•假设一个服务须要暂时拒绝用户的请求则它应该返回一个特定的错误代码。以使client应用程序理解拒绝执行某种操作原因是由于节流。

client应用程序能够等待一段时间,然后重试该请求。
节流可作为系统autoscales一项暂时措施

在某些情况下可能是更好的简单节流,而不是按比例假设活动突发是突然的而且估计不会长寿命,由于结垢可显着添加了执行成本
•假设节流正在使用的暂时措施。而一个系统autoscales。而且假设资源需求迅速增长。系统可能无法继续运作即使在节流模式中操作假设这是不能接受的考虑维护容量储备和配置更积极自己主动缩放

何时使用这个模式


使用这样的模式
为了确保系统持续满足服务水平协议


为了防止单一租户独占由应用程序所提供的资源


为了处理突发活动


为了帮助限制须要保持运转的最大资源水平的成本优化的系统。

样例


图3示出了怎样限制能够多租户系统来实现。

从每一个租户组织用户訪问一个云托管的应用程序。他们填写并提交调查

应用程序中包括的仪器,用于监视当中这些用户提交请求给应用程序的速度

为了防止用户一个租户影响应用的全部其它用户的响应性和可用性,限制施加到每秒不论什么一个租户用户能够提交请求的数目

应用程序块请求超过此限制

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

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

 

原文地址:https://www.cnblogs.com/cxchanpin/p/6774369.html