专利名称：流量控制方法和流量控制装置的制作方法
技术领域：
本发明涉及信息处理领域，更具体地，本发明涉及流量控制方法和流量控制装置。
背景技术：
各种系统例如通信系统应当在支持不同类型的请求所带来的巨大的流量的同时，保持稳定和健康状态。在某些特定时段，例如在圣诞节或在元旦，用户流量会急剧增加，从而可能会影响系统的稳定性，甚至导致系统瘫痪，无法正常提供服务。因此，需要进行流量控制，以使系统保持稳定。然而，如果不合适地进行了流量控制，会使系统的资源得不到充分的利用，从而产 生了浪费。因此，需要有效、实用和灵活的流量控制方案，其中有效是指能使系统尽可能地保持稳定，实用是指能使系统的资源得到尽可能充分地利用，灵活是指能尽可能地根据具体情况进行流量控制的定制。
发明内容
根据本发明的第一方面，提出了一种流量控制方法，包括步骤收集系统的关键性能指标；以及根据收集的系统的关键性能指标确定是否对进入系统的请求进行限制，当收集的某个系统的关键性能指标差于第一阈值一段时间时，确定对进入系统的请求进行限制。根据本发明的第二方面，提出了一种流量控制装置，包括收集器，用于收集系统的关键性能指标；以及确定器，用于根据收集的系统的关键性能指标确定是否对进入系统的请求进行限制，当收集的某个系统的关键性能指标差于第一阈值一段时间时，确定对进入系统的请求进行限制。根据本发明，能有效、实用以及灵活地向通信系统提供流量控制。
通过以下结合附图的说明，并且随着对本发明的更全面了解，本发明的其他目的和效果将变得更加清楚和易于理解，其中图I示意性地示出了根据本发明的一个实施方式的流量控制方法的流程图；图2示意性地示出了根据本发明的一个实施方式的流量控制装置的框图；图3示意性地示出了本发明可以在其中实现的通信系统。在所有的上述附图中，相同的标号表示具有相同、相似或相应的特征或功能。
具体实施例方式本发明的基本思想是根据系统的关键性能指标KPI确定是否对进入系统的请求进行限制。KPI是反映系统的健康状况的最直观的指标，它既包括关于系统硬件资源方面的指标，例如CPU利用率、内存利用率、硬盘读/写利用率等等，也包括在软件逻辑概念上定义的指标，例如队列长度、可用池大小等等。基于不间断地收集系统的关键性能指标，能够合理地确定是否对进入系统的请求进行限制，即，使系统的资源得到尽可能充分地利用，同时保持系统的稳定。图I示意性地示出了根据本发明的一个实施方式的流量控制方法的流程图。如图I所示，该方法100包括步骤S110，收集系统的关键性能指标；以及步骤S120，根据收集的系统的关键性能指标确定是否对进入系统的请求进行限制，当收集的某个系统的关键性能指标差于第一阈值一段时间时，确定对进入系统的请求进行限制。相应地，图2示意性地示出了根据本发明的一个实施方式的流量控制装置的框图。 如图2所示，该流量控制装置200包括收集器210，用于收集系统的关键性能指标；以及确定器220，用于根据收集的系统的关键性能指标确定是否对进入系统的请求进行限制，当收集的某个系统的关键性能指标差于第一阈值一段时间时，确定对进入系统的请求进行限制。例如，收集的某个系统的关键性能指标可以是平均CPU利用率，第一阈值可以是80%，在平均CPU利用率优于第一阈值的情况下，即平均CPU利用率小于或等于80%的情况下，系统还能稳定工作，不需要对进入系统的请求进行限制。在平均CPU利用率差于第一阈值的情况下，即平均CPU利用率大于80 %的情况下，说明系统的负载过于严重，系统可能会不稳定，因此在确定步骤S120和确定器220，当平均(PU利用率大于80%持续5分钟时，确定对进入系统的请求进行限制。其中，对请求进行限制包括在请求进入系统的入口点位置，随机地拒绝一定比例的请求，即向一些请求返回失败响应，而不把这些请求传递到系统内部进行处理。例如，拒绝率可以是20%，也就是说，平均10个进入系统的请求中有2个请求被拒绝。这一策略可以使得用户的体验比较良好，因为只有少数的用户的请求被拒绝，而大多数的用户的请求得到服务。其中，在确定步骤S120和确定器220，对于从不同接口进入系统的请求，可以利用收集的不同的系统关键性能指标确定是否对从相应接口进入系统的请求进行限制。例如，对于通过Open IVR(开放交互语音应答)接口进入系统的请求，可以采用(PU利用率这一系统的KPI，如果平均CPU利用率> 80%持续了 5分钟，那么可以确定对通过Open IVR接口进入系统的请求进行限制，例如以20%的拒绝率拒绝通过Open IVR接口进入系统的请求。对于通过SMS (短消息服务)接口进入系统的请求，可以采用队列长度这一系统的KPI，如果平均队列长度> 20持续了 5分钟，那么可以确定对通过SMS接口进入系统的请求进行限制，例如以50%的拒绝率拒绝通过SMS接口进入系统的请求。这一策略考虑了通过不同接口进入系统的请求可能会对不同的系统的KPI产生影响的这一事实。例如，通过Open IVR接口进入系统的请求主要消耗系统的CPU资源，因此主要对系统的平均CPU利用率这个KPI产生影响，而通过SMS接口进入系统的请求主要消耗系统的队列资源，因此主要对系统的平均队列长度这个KPI产生影响。其中，在确定步骤S120和确定器220，对于从不同接口进入系统的请求，可以利用收集的相同的系统关键性能指标，但是利用不同的阈值，来确定是否对从相应接口进入系统的请求进行限制。例如，对于通过Open IVR(公开交互语音应答)接口进入系统的请求，可以利用平均CPU利用率这个KPI，以及80%这个阈值，来确定是否对通过Open IVR接口进入系统的请求进行限制。如果平均CPU利用率>80%持续了 5分钟，那么可以确定对通过Open IVR接口进入系统的请求进行限制，例如以10%的拒绝率拒绝通过Open IVR接口进入系统的请求。对于通过SMS (短消息服务)接口进入系统的请求，可以利用平均CPU利用率这个KPI,以及70%这个阈值，来确定是否对通过SMS接口进入系统的请求进行限制。如果平均(PU利用率> 70%持续了 5分钟，那么可以确定对通过SMS接口进入系统的请求进行限制，例如以50%的拒绝率拒绝通过SMS接口进入系统的请求。 这一策略可以使得对从不同接口进入系统的请求，进行区别的处理，从而可以先限制低优先级的请求，而以有限的可用系统资源，服务更多的高优先级的请求。只有在只限制低优先级的请求还不能使系统的负载下降的情况下，才开始限制高优先级的请求。也就是说，对于低优先级的通过SMS接口进入系统的请求，当平均CPU利用率大于70%持续5分钟就被限制，而对于高优先级的通过Open IVR接口进入系统的请求，当平均CPU利用率大于80%持续5分钟才会被限制。其中，在确定步骤S120和确定器220，对于不同的系统，可以利用收集的不同的系统关键性能指标确定是否对进入系统的请求进行限制。如果系统需要进行密集的浮点计算(例如该系统是一个预付费记账系统)，由于浮点计算比较消耗CPU资源，因此，可以利用该系统的平均CPU利用率这一系统的关键性能指标来确定是否对进入该系统的请求进行限制。例如，第一阈值可以设置为80%，即如果平均CPU利用率〉80%持续了 5分钟，那么可以确定对进入该系统的请求进行限制。对于有些系统，虽然在硬件方面，例如在CPU/内存/硬盘读写利用率方面，系统并没有表现出负载已经很严重、不能服务更多的进入请求，但是在软件逻辑方面，系统却表现出负载已经很严重，不能服务更多的进入请求。例如在执行队列中具有很大数量的等待请求，或者有大量的请求在等待JDBC连接。因此，可以利用该系统的平均执行队列长度或平均等待JDBC连接数目的系统关键性能指标来确定是否对进入该系统的请求进行限制。例如，第一阈值可以设置为20，S卩如果平均执行队列长度>20持续了 5分钟，那么可以确定对进入该系统的请求进行限制。或者，第一阈值可以设置为30，即如果平均等待JDBC连接数量> 30持续了 5分钟，那么可以确定对进入该系统的请求进行限制。这一策略考虑到系统的差异，对于不同的系统，利用收集的不同的系统关键性能指标确定是否对进入系统的请求进行限制。其中，在确定步骤S120和确定器220，当对进入系统的请求进行限制后，收集的系统的关键性能指标优于第二阈值一段时间的情况下，确定停止对进入系统的请求进行限制，其中相对于第一阈值，第二阈值表明的系统的负载更轻。例如，当对进入系统的请求进行限制后，平均CPU利用率这一关键性能指标可能表明系统的负载变轻，这说明之前的对进入系统的请求的限制发生作用，系统的稳定性得以保持，因此，为了使系统的资源得到尽可能充分地利用，应该停止对进入系统的请求进行限制。然而，为了避免频繁地在对进入系统的请求进行限制和停止对进入系统的请求进行限制之间切换，用于决定停止对进入系统的请求进行限制的第二阈值，应该比用于决定对进入系统的请求进行限制的第一阈值，表明的系统的负载更轻。例如，如果第一阈值为80%，那么第二阈值可以为 60%，也就是说，当平均CPU利用率小于60%持续了 5分钟，那么确定停止对进入系统的请求进行限制。其中，在确定步骤S120和确定器220，当对进入系统的请求进行限制后，收集的系统关键性能指标差于第三阈值一段时间的情况下，可以确定对进入系统的请求进行进一步的限制，其中相对于第一阈值，第三阈值表明的系统的负载更重。例如，当对进入系统的请求进行限制后，平均CPU利用率这一关键性能指标可能表明系统的负载不仅没有变轻，反而变得更加严重，这说明之前的对进入系统的请求的限制并不足够，需要对进入系统的请求进行进一步的限制，以使系统的负载下降，从而保持系统的稳定性。例如，如果第一阈值为80%，那么第三阈值可以为90%，即如果平均CPU利用率>90%持续了 5分钟，那么可以确定对进入该系统的请求进行进一步的限制，使得对进入系统的请求的拒绝率达到50%。当然，本领域的技术人员可以理解，如果当对进入系统的请求进行进一步地限制后，平均CPU利用率这一关键性能指标表明系统的负载还不仅没有变轻，反而变得更加严重，这说明之前的对进入系统的请求的进一步限制并不足够，可以对进入系统的请求进行再进一步的限制，以使系统的负载下降，从而保持系统的稳定性。例如，如果平均CPU利用率>95%持续了 5分钟，那么可以确定对进入该系统的请求进行再进一步的限制，使得对进入系统请求的拒绝率达到100%，即暂时停止该系统接受进入的请求，以使系统保持稳定。图3示意性地示出了本发明可以在其中实现的系统。图3所示的系统300是一个个性化回铃音PRBT系统的内容管理系统CMS。其中，PRBT系统允许PRBT业务的使用者根据自己的需要，对不同的来电号码、在不同的时间段设置不同的回铃音。PRBT系统可以包括PRBT-CDS (铃音播放系统)和PRBT-CMS这两部分。PRBT-CDS负责接收呼叫，并且向主叫方播放个性化回铃音，而PRBT-CMS则负责管理PRBT使用者的用户数据和铃音文件。如图3所示的PRBT-CMS 300提供如下的4种接口，供用户与其交互Web 接口 322 ;Open API 接口 324 ;Open IVR 接口 326 ;以及SMS 接口 328。
来自这些接口的请求首先到达PRBT-CMS 300的Web服务器330，然后由Web服务器330传送到Weblogic服务器实例332-1、332-2、· . .、332_N中的一个。其中各个Weblogic服务器实例连接到数据库DB服务器334。考虑到所有进入PRBT-CMS 300的请求都通过Web服务器330传送到Weblogic
服务器实例332-1、332-2.....332-N中的一个，因此，Web服务器330是所有请求进入
PRBT-CMS 300的入口点，所以，应当在Web服务器330处确定是否对进入PRBT-CMS 300的请求进行限制。换句话说，上述的确定器220应当实现在Web服务器330处。另外，Web服务器 330、Weblogic 服务器实例 332_1、332_2、· · ·、332_N 和 DB 服务器334是被所有接口共享的资源，所以应该收集关于它们的KPI。
在如图3所示的例子中，假定Weblogic服务器实例332_1、332_2、· · ·、332_N是PRBT-CMS 300的主要处理设备，因此PRBT-CMS 300的KPI只与Weblogic服务器实例有关。并且在如图3所示的例子中，Weblogic服务器实例332-N为一个管理实例，用于管理其他的Weblogic服务器实例332-1，332-2，…。因此，上述的收集器210实现在Weblogic服务器管理实例332-N处。收集器210不断地收集关于PRBT-CMS 300的KPI。例如，收集器210通过在Weblogic服务器JMXCJava管理扩展)接口中提供的Mbean (管理Bean)类和方法，来不断地收集关于Weblogic服务器实例的KPI。确定器220也不断地查询收集器210收集的KPI，当发现KPI匹配于要对进入系统的请求进行限制的阈值时，则开始拒绝一定比例的请求。由收集器210收集的KPI包括但不局限于如下条目l)Weblogic服务器的健康状态即一个Weblogic服务器实例的当前生命周期状态；2)N个Weblogic服务器实例中活跃服务器实例的数目可以通过向每个Weblogic服务器实例发送CMS Open API的查询请求，来识别相应的Weblogic服务器实例是否活跃，如果一个Weblogic服务器实例返回成功的结果，那么该Weblogic服务器实例被认为是活跃的；3)为每个Weblogic服务器实例配置的执行队列中等待请求的数目其定义了在优先级队列中处于等待状态的用户请求的数目。优先级队列通常包括来自内部子系统和外部用户的请求，值PendingUserRequestCount则是所有的外部用户请求的数目；4)每个Weblogic服务器实例的每个监听端口上建立的套接字的数目可以使用OpenSocketsCurrentCount来获得由Weblogic服务器实例当前打开的套接字的数目；5)所有处理器平均负载每个Weblogic服务器实例中的CPU利用率。一般地，从运营商的角度来看，来自Web接口 322、0pen IVR接口 326、SMS接口 328的请求是来自最终用户的请求，而来自Open API接口 324的请求是来自第三方系统的请求，为了使最终用户对PRBT服务的体验保持良好，来自Web接口 322、Open IVR接口 326、SMS接口 328的请求的优先级应该比来自Open API接口 324的请求的优先级要高。因此，运营商可以配置不对来自Web接口 322、0pen IVR接口 326、SMS接口 328的请求进行限制，而只对来自Open API接口 324的请求进行限制。另外，在该例子中，根据每个Weblogic服务器实例的每个监听端口上建立的套接字的数目这个KPI确定是否对进入系统的请求进行限制，第一阈值为100，第二阈值为40。
即如果监听端口上建立的套接字的数目的最大值大于100持续了 40秒，那么对来自Open API接口 324的请求进行限制，拒绝这些请求的50%，即拒绝率为50%。在对来自Open API接口 324的请求进行限制后，如果监听端口上建立的套接字的数目的最大值小于40持续了 40秒，那么停止对来自Open API接口 324的请求进行限制。应当注意，为了使本发明更容易理解，上面的描述省略了对于本领域的技术人员来说是公知的、并且对于本发明的实现可能是必需的更具体的一些技术细节。本领域的技术人员还应当理解，本发明不限于上面所描述的步骤，本发明也包括对上面所描述的步骤进行的组合、顺序变换等。本发明的最终范围由所附的权利要求限定。因此，选择并描述实施方式是为了更好地解释本发明的原理及其实际应用，并使本领域普通技术人员明白，在不脱离本发明实质的前提下，所有修改和变更均落入由权利要求所限定的本发明的保护范围之内。
另外，本领域的技术人员可以理解，上面描述的各种方法的步骤可以通过编程的计算机来实现。这里，有些实施方式旨在覆盖程序存储装置，其为机器或计算机可读，并编码有机器可执行或计算机可执行指令程序，其中所述指令执行上述方法的一些或所有步骤。该程序存储装置可以是例如磁存储媒体例如磁盘和磁带、硬盘驱动器、或光学可读数字数据存储媒体。实施方式也旨在覆盖编程为执行上述方法的所述步骤的计算机。
权利要求
1.一种流量控制方法，包括步骤 收集系统的关键性能指标；以及 根据收集的系统的关键性能指标确定是否对进入系统的请求进行限制，当收集的某个系统的关键性能指标差于第一阈值一段时间时，确定对进入系统的请求进行限制。
2.根据权利要求I所述的方法， 其中对于从不同接口进入系统的请求，利用收集的不同的系统的关键性能指标确定是否对从相应接口进入系统的请求进行限制。
3.根据权利要求I所述的方法， 其中对于从不同接口进入系统的请求，利用收集的相同的系统的关键性能指标，但是利用不同的阈值，来确定是否对从相应接口进入系统的请求进行限制。
4.根据权利要求I所述的方法， 其中对于不同的系统，利用收集的不同的系统的关键性能指标确定是否对进入系统的请求进行限制。
5.根据权利要求I所述的方法， 其中当对进入系统的请求进行限制后，所述收集的某个系统的关键性能指标优于第二阈值一段时间的情况下，确定停止对进入系统的请求进行限制，其中相对于第一阈值，第二阈值表明的系统的负载更轻。
6.根据权利要求I所述的方法， 其中当对进入系统的请求进行限制后，所述收集的某个系统的关键性能指标差于第三阈值一段时间的情况下，确定对进入系统的请求进行进一步的限制，其中相对于第一阈值，第三阈值表明的系统的负载更重。
7.根据权利要求I所述的方法， 其中对请求进行限制包括随机地拒绝一定比例的请求。
8.一种流量控制装置，包括 收集器，用于收集系统的关键性能指标；以及 确定器，用于根据收集的系统的关键性能指标确定是否对进入系统的请求进行限制，当收集的某个系统的关键性能指标差于第一阈值一段时间时，确定对进入系统的请求进行限制。
9.根据权利要求8所述的装置， 其中确定器对于从不同接口进入系统的请求，利用收集的不同的系统的关键性能指标确定是否对从相应接口进入系统的请求进行限制。
10.根据权利要求8所述的装置， 其中确定器对于从不同接口进入系统的请求，利用收集的相同的系统的关键性能指标，但是利用不同的阈值，来确定是否对从相应接口进入系统的请求进行限制。
11.根据权利要求8所述的装置， 其中确定器对于不同的系统，利用收集的不同的系统的关键性能指标确定是否对进入系统的请求进行限制。
12.根据权利要求8所述的装置， 其中当对进入系统的请求进行限制后，所述收集的某个系统的关键性能指标优于第二阈值一段时间的情况下，确定器确定停止对进入系统的请求进行限制，其中相对于第一阈值,第二阈值表明的系统的负载更轻。
13.根据权利要求8所述的装置， 其中当对进入系统的请求进行限制后，所述收集的某个系统的关键性能指标差于第三阈值一段时间的情况下，确定器确定对进入系统的请求进行进一步的限制，其中相对于第一阈值，第三阈值表明的系统的负载更重。
14.根据权利要求8所述的装置， 其中对请求进行限制包括随机地拒绝一定比例的请求。
全文摘要
本发明公开了一种流量控制方法和流量控制装置。该流量控制方法包括步骤收集系统的关键性能指标；以及根据收集的系统的关键性能指标确定是否对进入系统的请求进行限制，当收集的某个系统的关键性能指标差于第一阈值一段时间时，确定对进入系统的请求进行限制。根据本发明，能有效、实用以及灵活地向系统提供流量控制。
文档编号H04L12/56GK102811157SQ201110146568
公开日2012年12月5日 申请日期2011年6月1日 优先权日2011年6月1日
发明者罗海滨, 邱威, 崔健 申请人:阿尔卡特朗讯公司