CN106487919A - 基于PaaS平台的HTTP请求处理方法、装置及系统 - Google Patents

Abstract

本发明实施例提供基于PaaS平台的HTTP请求处理方法、装置及系统，所述方法包括：通过PaaS平台的前端代理获取应用的HTTP请求；根据所述应用的HTTP请求，获取发送所述应用的HTTP请求对应的应用信息；判断是否预存所述应用的HTTP请求对应的应用信息的禁用规则，获取第一判断结果；根据所述第一判断结果对所述应用的HTTP请求进行处理。上述技术方案具有如下有益效果：可以友好合理的限制应用使用PaaS平台资源。

Description

基于PaaS平台的HTTP请求处理方法、装置及系统

技术领域

本发明涉及PaaS(Platform-as-a-Service，平台即服务)平台技术领域，尤其涉及基于PaaS平台的HTTP(HyperText Markup Language，超文本标记语言)请求处理方法、装置及系统。

背景技术

为了让开发者合理使用PaaS平台资源，在资源限制上分了多个等级，不同的等级有不同的配额，连续两个检测周期使用超过配额的应用，该应用会被禁用一个周期时长。禁用周期内对所有用户的访问都返回一个特定的页面，提示该网站超配额资源不足。

在实现本发明过程中，发明人发现现有技术中至少存在如下问题：PaaS平台资源禁用粒度太粗太暴力，对开发者和用户都不太友好。合理的做法应该是超配多少限制多少，或者可以做一点惩罚，多限制一部分请求。

发明内容

本发明实施例提供一种基于PaaS平台的HTTP请求处理方法、装置及系统，以友好合理的限制应用使用PaaS平台资源。

一方面，本发明实施例提供了一种基于平台即服务PaaS平台的HTTP请求处理方法，所述方法包括：通过PaaS平台的前端代理获取应用的HTTP请求；根据所述应用的HTTP请求，获取发送所述应用的HTTP请求对应的应用信息；判断是否预存所述应用的HTTP请求对应的应用信息的禁用规则，获取第一判断结果；根据所述第一判断结果对所述应用的HTTP请求进行处理。

另一方面，本发明实施例提供了一种基于平台即服务PaaS平台的HTTP请求处理装置，所述装置包括：接收单元，用于通过PaaS平台的前端代理获取应用的HTTP请求；获取单元，用于根据所述应用的HTTP请求，获取发送所述应用的HTTP请求对应的应用信息；判断单元，用于判断是否预存所述应用的HTTP请求对应的应用信息的禁用规则，获取第一判断结果；处理单元，用于根据所述第一判断结果对所述应用的HTTP请求进行处理。

再一方面，本发明实施例提供了一种基于平台即服务PaaS平台的HTTP请求处理系统，所述系统包括多个前端代理构成的前端代理集群和检测系统，每个前端代理包括上述基于平台即服务PaaS平台的HTTP请求处理装置，其中：检测系统，用于实时采集前端代理集群的日志，并在检测周期到达时统计日志中应用的HTTP请求次数；将日志中应用的HTTP请求次数和应用等级对应的请求次数配额比较：如果连续两个检测周期均超配，根据应用等级以及超配的比例，确定拒绝请求的随机拒绝请求比例和规则有效时长设置到前端代理集群的每个前端代理中。

上述技术方案具有如下有益效果：可以友好合理的限制应用使用PaaS平台资源。

附图说明

为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1为本发明实施例一种基于平台即服务PaaS平台的HTTP请求处理方法流程图；

图2为本发明实施例一种基于平台即服务PaaS平台的HTTP请求处理装置结构示意图；

图3为本发明实施例一种基于平台即服务PaaS平台的HTTP请求处理系统架构示意图。

具体实施方式

下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

如图1所示，为本发明实施例一种基于平台即服务PaaS平台的HTTP请求处理方法流程图，所述方法包括：

101、通过PaaS平台的前端代理获取应用的HTTP请求；

102、根据所述应用的HTTP请求，获取发送所述应用的HTTP请求对应的应用信息；

103、判断是否预存所述应用的HTTP请求对应的应用信息的禁用规则，获取第一判断结果；

104、根据所述第一判断结果对所述应用的HTTP请求进行处理。

优选地，所述根据所述第一判断结果对所述应用的HTTP请求进行处理，包括：若第一判断结果为没有预存所述应用的HTTP请求对应的应用信息的禁用规则，则直接放行所述应用的HTTP请求；若第一判断结果为预存有所述应用的HTTP请求对应的应用信息的禁用规则，则对所述应用的HTTP请求次数进行累加；进一步判断所述应用的HTTP请求次数是否达到随机拒绝请求比例，获取第二判断结果；根据所述第二判断结果对所述应用的HTTP请求进行处理。

优选地，所述根据所述第二判断结果对所述应用的HTTP请求进行处理，包括：若第二判断结果为所述应用的HTTP请求次数达到随机拒绝请求比例，则进一步判断所述应用的HTTP请求是否有放行请求对应的cookie：如果没有放行请求对应的cookie，则拒绝所述应用的HTTP请求；如果有放行请求对应的cookie，则在所述cookie的规则有效时长内放行所述应用的HTTP请求，在所述cookie的规则有效时长外拒绝所述应用的HTTP请求；其中，相同的cookie表示一个完整的页面或会话，所述规则有效时长为预设的时间周期；若第二判断结果为所述应用的HTTP请求次数没有达到随机拒绝请求比例，则直接放行所述应用的HTTP请求。

优选地，所述方法还包括：利用检测系统实时采集前端代理集群的日志，并在检测周期到达时统计日志中应用的HTTP请求次数；将日志中应用的HTTP请求次数和应用等级对应的请求次数配额比较：如果连续两个检测周期均超配，根据应用等级以及超配的比例，确定拒绝请求的随机拒绝请求比例和规则有效时长设置到前端代理集群的每个前端代理中。

优选地，所述随机拒绝请求比例通过如下公式确定：

其中，R表示随机拒绝请求比例，a表示日志中应用的HTTP请求次数，b表示应用等级对应的请求次数配额，C表示设定的应用等级系数，取值-1到+1之间。

对应于上述方法实施例，如图2所示，为本发明实施例一种基于平台即服务PaaS平台的HTTP请求处理装置结构示意图，所述装置包括：

接收单元21，用于通过PaaS平台的前端代理获取应用的HTTP请求；

获取单元22，用于根据所述应用的HTTP请求，获取发送所述应用的HTTP请求对应的应用信息；

判断单元23，用于判断是否预存所述应用的HTTP请求对应的应用信息的禁用规则，获取第一判断结果；

处理单元24，用于根据所述第一判断结果对所述应用的HTTP请求进行处理。

优选地，所述处理单元24，具体用于若第一判断结果为没有预存所述应用的HTTP请求对应的应用信息的禁用规则，则直接放行所述应用的HTTP请求；若第一判断结果为预存有所述应用的HTTP请求对应的应用信息的禁用规则，则对所述应用的HTTP请求次数进行累加；进一步判断所述应用的HTTP请求次数是否达到随机拒绝请求比例，获取第二判断结果；根据所述第二判断结果对所述应用的HTTP请求进行处理。

优选地，所述处理单元24，具体用于若第二判断结果为所述应用的HTTP请求次数达到随机拒绝请求比例，则进一步判断所述应用的HTTP请求是否有放行请求对应的cookie：如果没有放行请求对应的cookie，则拒绝所述应用的HTTP请求；如果有放行请求对应的cookie，则在所述cookie的规则有效时长内放行所述应用的HTTP请求，在所述cookie的规则有效时长外拒绝所述应用的HTTP请求；其中，相同的cookie表示一个完整的页面或会话，所述规则有效时长为预设的时间周期；若第二判断结果为所述应用的HTTP请求次数没有达到随机拒绝请求比例，则直接放行所述应用的HTTP请求。

如图3所示，为本发明实施例一种基于平台即服务PaaS平台的HTTP请求处理系统架构示意图，所述系统包括多个前端代理30(前端代理1、前端代理2、前端代理3、……、前端代理n，其中n为正整数)构成的前端代理集群和检测系统31，每个前端代理30包括上述基于平台即服务PaaS平台的HTTP请求处理装置，其中：

检测系统31，用于实时采集前端代理集群的日志，并在检测周期到达时统计日志中应用的HTTP请求次数；将日志中应用的HTTP请求次数和应用等级对应的请求次数配额比较：如果连续两个检测周期均超配，根据应用等级以及超配的比例，确定拒绝请求的随机拒绝请求比例和规则有效时长设置到前端代理集群的每个前端代理中。

优选地，所述随机拒绝请求比例通过如下公式确定：

其中，R表示随机拒绝请求比例，a表示日志中应用的HTTP请求次数，b表示应用等级对应的请求次数配额，C表示设定的应用等级系数，取值-1到+1之间。

对于PaaS平台，如果不了解平台上各应用的具体业务逻辑，根本没办法根据业务做限制，但是也不能暴力的随机拒绝一部分请求，如果拒绝的请求正好是一个完成Page(页面)的CSS(Cascading Style Sheets，层叠样式表，又称串样式列表、级联样式表、串接样式表、层叠样式表、阶层式样式表，一种用来为结构化文档(如HTML文档或XML(ExtensibleMarkup Language，可扩展标记语言)应用)添加样式(字体、间距和颜色等)的计算机语言，由W3C(World Wide Web Consortium，万维网联盟)定义和维护。(见：https://zh.wikipedia.org/wiki/层叠样式表))，整个页面就乱了，做这个改善就没有意义了。因此要拒绝只能拒绝一个完整的Page请求。也就是做会话级别的限制或Page级别的限制。但是，做会话级别的限制或Page级别的限制是困难的。正常情况下很难区分一个请求是不是一个完整Page的子请求或者是属于一个会话的。

整个系统架构如图3所示，在所有前端代理集群处把日志采集到检测系统31按应用汇总分析，如果检查出有应用超配，把超配后禁用规则设置到前端代理集群中的每个前端代理30中，前端代理30根据禁用规则随机的拒绝一些用户的请求。拒绝请求的时候保证不拒绝一个完整Page的子请求。禁用规则过期后前端代理集群自动删除。

检测系统31实时的采集前端代理集群的日志，按应用实时分析汇总各指标(比如：流量、请求数等)。分析的结果和应用等级的配额比较，如果连续两个检测周期都超配，根据应用的等级以及超配的比例，计算一个拒绝请求的比例和规则有效时长设置到前端代理集群中的每个前端代理30中。目前计算规则很简单：

所述随机拒绝请求比例通过如下公式确定：

其中，R表示随机拒绝请求比例，a表示日志中应用的HTTP请求次数，b表示应用等级对应的请求次数配额，C表示设定的应用等级系数，取值-1到+1之间。

规则有效时长是定好了的一个周期。

前端代理集群，有请求到达先根据该请求分析是否有对应应用的禁用规则，如果没有就直接放行，如果有禁用规则就要累加次数检测该HTTP请求是否达到随机拒绝请求比例，具体实现是：如果有禁用规则，那么就在代理程序开辟一块共享内存设置个键值key-val对，每次累加对应key的val.total_count，判断val.limit_count/val.total_count是否没有达到随机拒绝请求比例：如果达到则val.limit_count+＝1，还要检测该请求是否有放行请求对应的cookie(cookie的值是根据应用的key和有效时间戳期限计算一个可逆的值)，如果没有对应的cookie，就拒绝请求。如果有(说明该请求是一个完成Page的子请求)，则在所述cookie的有效时长内放行所述应用的HTTP请求，在所述cookie的有效时长外拒绝所述应用的HTTP请求。如果该请求没有达到随机拒绝请求比例，为该HTTP请求头设置一个有效时长为规则有效时长的cookie放行，相同的cookie用来表示一个完整的Page或会话。

如果该请求没有达到随机拒绝请求比例，则直接放行所述应用的HTTP请求。但是该HTTP请求的cookie是有有效时长的，比如max－age＝10s，那么浏览器会设置该cookie的失效时间是当前时间+10s，失效就会清理掉。每次更新就会更新这个失效时间。也就是说10s之内发起一个请求的话，这个cookie会一直存在，而不会被浏览器删掉。但是cookie的值也是有个有效期限的，也就是说同一个应用不同的规则周期的cookie的值是不同的，服务端会判断这个cookie的值是否正确。也就是上个周期的规则的cookie不会影响下一个周期的规则限制。

上述技术方案具有如下有益效果：可以友好合理的限制应用使用PaaS平台资源。通过服务端保存client ip(客户端ip)也可以达到相同的目的，但是超配的应用请求量势必很多，那么服务端要保存对应多条目的信息。在检索上和存储上势必会消耗服务端资源。并且前端代理是所有应用请求的入口，太重的任务会影响其他应用的请求。因此HTTP请求设置cookie是个合理有效的解决方案。

应该明白，公开的过程中的步骤的特定顺序或层次是示例性方法的实例。基于设计偏好，应该理解，过程中的步骤的特定顺序或层次可以在不脱离本公开的保护范围的情况下得到重新安排。所附的方法权利要求以示例性的顺序给出了各种步骤的要素，并且不是要限于所述的特定顺序或层次。

在上述的详细描述中，各种特征一起组合在单个的实施方案中，以简化本公开。不应该将这种公开方法解释为反映了这样的意图，即，所要求保护的主题的实施方案需要比清楚地在每个权利要求中所陈述的特征更多的特征。相反，如所附的权利要求书所反映的那样，本发明处于比所公开的单个实施方案的全部特征少的状态。因此，所附的权利要求书特此清楚地被并入详细描述中，其中每项权利要求独自作为本发明单独的优选实施方案。

为使本领域内的任何技术人员能够实现或者使用本发明，上面对所公开实施例进行了描述。对于本领域技术人员来说；这些实施例的各种修改方式都是显而易见的，并且本文定义的一般原理也可以在不脱离本公开的精神和保护范围的基础上适用于其它实施例。因此，本公开并不限于本文给出的实施例，而是与本申请公开的原理和新颖性特征的最广范围相一致。

上文的描述包括一个或多个实施例的举例。当然，为了描述上述实施例而描述部件或方法的所有可能的结合是不可能的，但是本领域普通技术人员应该认识到，各个实施例可以做进一步的组合和排列。因此，本文中描述的实施例旨在涵盖落入所附权利要求书的保护范围内的所有这样的改变、修改和变型。此外，就说明书或权利要求书中使用的术语“包含”，该词的涵盖方式类似于术语“包括”，就如同“包括，”在权利要求中用作衔接词所解释的那样。此外，使用在权利要求书的说明书中的任何一个术语“或者”是要表示“非排它性的或者”。

本领域技术人员还可以了解到本发明实施例列出的各种说明性逻辑块(illustrative logical block)，单元，和步骤可以通过电子硬件、电脑软件，或两者的结合进行实现。为清楚展示硬件和软件的可替换性(interchangeability)，上述的各种说明性部件(illustrative components)，单元和步骤已经通用地描述了它们的功能。这样的功能是通过硬件还是软件来实现取决于特定的应用和整个系统的设计要求。本领域技术人员可以对于每种特定的应用，可以使用各种方法实现所述的功能，但这种实现不应被理解为超出本发明实施例保护的范围。

本发明实施例中所描述的各种说明性的逻辑块，或单元都可以通过通用处理器，数字信号处理器，专用集成电路(ASIC)，现场可编程门阵列或其它可编程逻辑装置，离散门或晶体管逻辑，离散硬件部件，或上述任何组合的设计来实现或操作所描述的功能。通用处理器可以为微处理器，可选地，该通用处理器也可以为任何传统的处理器、控制器、微控制器或状态机。处理器也可以通过计算装置的组合来实现，例如数字信号处理器和微处理器，多个微处理器，一个或多个微处理器联合一个数字信号处理器核，或任何其它类似的配置来实现。

本发明实施例中所描述的方法或算法的步骤可以直接嵌入硬件、处理器执行的软件模块、或者这两者的结合。软件模块可以存储于RAM存储器、闪存、ROM存储器、EPROM存储器、EEPROM存储器、寄存器、硬盘、可移动磁盘、CD-ROM或本领域中其它任意形式的存储媒介中。示例性地，存储媒介可以与处理器连接，以使得处理器可以从存储媒介中读取信息，并可以向存储媒介存写信息。可选地，存储媒介还可以集成到处理器中。处理器和存储媒介可以设置于ASIC中，ASIC可以设置于用户终端中。可选地，处理器和存储媒介也可以设置于用户终端中的不同的部件中。

在一个或多个示例性的设计中，本发明实施例所描述的上述功能可以在硬件、软件、固件或这三者的任意组合来实现。如果在软件中实现，这些功能可以存储与电脑可读的媒介上，或以一个或多个指令或代码形式传输于电脑可读的媒介上。电脑可读媒介包括电脑存储媒介和便于使得让电脑程序从一个地方转移到其它地方的通信媒介。存储媒介可以是任何通用或特殊电脑可以接入访问的可用媒体。例如，这样的电脑可读媒体可以包括但不限于RAM、ROM、EEPROM、CD-ROM或其它光盘存储、磁盘存储或其它磁性存储装置，或其它任何可以用于承载或存储以指令或数据结构和其它可被通用或特殊电脑、或通用或特殊处理器读取形式的程序代码的媒介。此外，任何连接都可以被适当地定义为电脑可读媒介，例如，如果软件是从一个网站站点、服务器或其它远程资源通过一个同轴电缆、光纤电缆、双绞线、数字用户线(DSL)或以例如红外、无线和微波等无线方式传输的也被包含在所定义的电脑可读媒介中。所述的碟片(disk)和磁盘(disc)包括压缩磁盘、镭射盘、光盘、DVD、软盘和蓝光光盘，磁盘通常以磁性复制数据，而碟片通常以激光进行光学复制数据。上述的组合也可以包含在电脑可读媒介中。

以上所述的具体实施方式，对本发明的目的、技术方案和有益效果进行了进一步详细说明，所应理解的是，以上所述仅为本发明的具体实施方式而已，并不用于限定本发明的保护范围，凡在本发明的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims (10)

1.一种基于平台即服务PaaS平台的HTTP请求处理方法，其特征在于，所述方法包括：

通过PaaS平台的前端代理获取应用的HTTP请求；

根据所述应用的HTTP请求，获取发送所述应用的HTTP请求对应的应用信息；

判断是否预存所述应用的HTTP请求对应的应用信息的禁用规则，获取第一判断结果；

根据所述第一判断结果对所述应用的HTTP请求进行处理。

2.如权利要求1所述基于平台即服务PaaS平台的HTTP请求处理方法，其特征在于，所述根据所述第一判断结果对所述应用的HTTP请求进行处理，包括：

若第一判断结果为没有预存所述应用的HTTP请求对应的应用信息的禁用规则，则直接放行所述应用的HTTP请求；

若第一判断结果为预存有所述应用的HTTP请求对应的应用信息的禁用规则，则对所述应用的HTTP请求次数进行累加；进一步判断所述应用的HTTP请求次数是否达到随机拒绝请求比例，获取第二判断结果；根据所述第二判断结果对所述应用的HTTP请求进行处理。

3.如权利要求2所述基于平台即服务PaaS平台的HTTP请求处理方法，其特征在于，所述根据所述第二判断结果对所述应用的HTTP请求进行处理，包括：

若第二判断结果为所述应用的HTTP请求次数达到随机拒绝请求比例，则进一步判断所述应用的HTTP请求是否有放行请求对应的cookie：如果没有放行请求对应的cookie，则拒绝所述应用的HTTP请求；如果有放行请求对应的cookie，则在所述cookie的规则有效时长内放行所述应用的HTTP请求，在所述cookie的规则有效时长外拒绝所述应用的HTTP请求；其中，相同的cookie表示一个完整的页面或会话，所述规则有效时长为预设的时间周期；

若第二判断结果为所述应用的HTTP请求次数没有达到随机拒绝请求比例，则直接放行所述应用的HTTP请求。

4.如权利要求1所述基于平台即服务PaaS平台的HTTP请求处理方法，其特征在于，所述方法还包括：

利用检测系统实时采集前端代理集群的日志，并在检测周期到达时统计日志中应用的HTTP请求次数；

将日志中应用的HTTP请求次数和应用等级对应的请求次数配额比较：如果连续两个检测周期均超配，根据应用等级以及超配的比例，确定拒绝请求的随机拒绝请求比例和规则有效时长设置到前端代理集群的每个前端代理中。

5.如权利要求4所述基于平台即服务PaaS平台的HTTP请求处理方法，其特征在于，所述随机拒绝请求比例通过如下公式确定：

$R=1-\frac{a-b}{b}c$

其中，R表示随机拒绝请求比例，a表示日志中应用的HTTP请求次数，b表示应用等级对应的请求次数配额，C表示设定的应用等级系数，取值-1到+1之间。

6.一种基于平台即服务PaaS平台的HTTP请求处理装置，其特征在于，所述装置包括：

接收单元，用于通过PaaS平台的前端代理获取应用的HTTP请求；

获取单元，用于根据所述应用的HTTP请求，获取发送所述应用的HTTP请求对应的应用信息；

判断单元，用于判断是否预存所述应用的HTTP请求对应的应用信息的禁用规则，获取第一判断结果；

处理单元，用于根据所述第一判断结果对所述应用的HTTP请求进行处理。

7.如权利要求6所述基于平台即服务PaaS平台的HTTP请求处理装置，其特征在于，

所述处理单元，具体用于若第一判断结果为没有预存所述应用的HTTP请求对应的应用信息的禁用规则，则直接放行所述应用的HTTP请求；若第一判断结果为预存有所述应用的HTTP请求对应的应用信息的禁用规则，则对所述应用的HTTP请求次数进行累加；进一步判断所述应用的HTTP请求次数是否达到随机拒绝请求比例，获取第二判断结果；根据所述第二判断结果对所述应用的HTTP请求进行处理。

8.如权利要求7所述基于平台即服务PaaS平台的HTTP请求处理装置，其特征在于，

所述处理单元，具体用于若第二判断结果为所述应用的HTTP请求次数达到随机拒绝请求比例，则进一步判断所述应用的HTTP请求是否有放行请求对应的cookie：如果没有放行请求对应的cookie，则拒绝所述应用的HTTP请求；如果有放行请求对应的cookie，则在所述cookie的规则有效时长内放行所述应用的HTTP请求，在所述cookie的规则有效时长外拒绝所述应用的HTTP请求；其中，相同的cookie表示一个完整的页面或会话，所述规则有效时长为预设的时间周期；若第二判断结果为所述应用的HTTP请求次数没有达到随机拒绝请求比例，则直接放行所述应用的HTTP请求。

9.一种基于平台即服务PaaS平台的HTTP请求处理系统，其特征在于，所述系统包括多个前端代理构成的前端代理集群和检测系统，每个前端代理包括权利要求6-8中任一项所述基于平台即服务PaaS平台的HTTP请求处理装置，其中：

检测系统，用于实时采集前端代理集群的日志，并在检测周期到达时统计日志中应用的HTTP请求次数；将日志中应用的HTTP请求次数和应用等级对应的请求次数配额比较：如果连续两个检测周期均超配，根据应用等级以及超配的比例，确定拒绝请求的随机拒绝请求比例和规则有效时长设置到前端代理集群的每个前端代理中。

10.如权利要求9所述基于平台即服务PaaS平台的HTTP请求处理系统，其特征在于，所述随机拒绝请求比例通过如下公式确定：

$R=1-\frac{a-b}{b}c,$

其中，R表示随机拒绝请求比例，a表示日志中应用的HTTP请求次数，b表示应用等级对应的请求次数配额，C表示设定的应用等级系数，取值-1到+1之间。