一种处理业务请求的方法及装置与流程

本发明涉及计算机
技术领域：
，尤其涉及一种处理业务请求的方法及装置。
背景技术：
：随着计算机技术和互联网的蓬勃发展及广泛应用，计算机和互联网已经融入了人们生活的方方面面。然而，在繁荣的背后却隐藏着信息安全的风险，常常有恶意用户通过网络对包括服务器在内的计算机设备进行攻击，则可能导致服务器无法正常工作，甚至导致信息泄露，造成信息安全方面的威胁，而一般的攻击方式是恶意用户向服务器发送包含攻击信息的业务请求。目前，一般通过应用防火墙对用户上传的业务请求进行筛选和过滤，以尽量避免包含攻击信息的业务请求传送至服务器而导致对服务器的攻击，从而保证网络和信息安全。应用防火墙中一般设置有风险规则库，风险规则库中包括多种风险规则，应用防火墙可以将接收到的每个业务请求与风险规则库中的风险规则进行匹配比较，进而可以将认为是危险的应用请求直接丢弃。在对业务请求进行筛选的过程中，应用防火墙只是简单地将业务请求划分为安全或者危险，在确定为危险时则直接将对应的业务请求丢弃，然而，由于风险规则库的限制，应用防火墙可能将安全的业务请求误判为是危险的业务请求，而导致业务请求的误丢弃，或者也可能将危险的业务请求误判为是安全的业务请求而导致安全隐患，也就是说，现有技术中的应用防火墙只能对业务请求进行安全或危险的简单划分，判定方式比较单一，在对业务请求的安全性进行判定时存在误判的可能，进而可能导致业务请求的误丢或者可能导致安全问题的产生。技术实现要素：本发明实施例提供一种处理业务请求的方法及装置，用于解决应用防火墙对业务请求的安全性的判断方式比较单一，进而导致对业务请求的安全性存在误判的技术问题。一方面，提供一种处理业务请求的方法，所述方法包括：应用防火墙接收与业务请求对应的业务请求信息；所述应用防火墙根据所述业务请求信息，确定用于表征所述业务请求的风险等级的风险等级信息；所述应用防火墙根据所述风险等级，从与所述应用防火墙连接的M个业务服务器中确定第一业务服务器；其中，所述第一业务服务器为配置用于接收预定风险等级集的业务服务器，M为正整数；所述应用防火墙将所述业务请求信息发送给所述第一业务服务器。可选的，所述应用防火墙根据所述业务请求信息，确定用于表征所述业务请求的风险等级的风险等级信息，包括：所述应用防火墙解析所述业务请求信息，获得解析结果；所述应用防火墙将所述解析结果与风险规则库进行风险规则匹配，获得风险匹配结果；所述应用防火墙根据所述风险匹配结果，确定所述风险等级信息。可选的，所述方法还包括：所述应用防火墙对所述风险规则库进行更新，获得更新后的风险规则库。可选的，所述应用防火墙根据所述风险等级，从与所述应用防火墙连接的M个业务服务器中确定第一业务服务器，包括：所述应用防火墙根据所述风险等级，从所述M个业务服务器中确定配置用于接收所述预定风险等级集的N个业务服务器，N为小于等于M的正整数；所述应用防火墙从所述N个业务服务器中确定满足预定条件的业务服务器为所述第一业务服务器。可选的，所述应用防火墙从所述N个业务服务器中确定满足预定条件的业务服务器为所述第一业务服务器，包括：所述应用防火墙确定所述N个业务服务器物理上距离所述业务请求的发送端最近的业务服务器为所述第一业务服务器；或，所述应用防火墙确定所述N个业务服务器中当前传输流量最少的业务服务器为所述第一业务服务器。另一方面，提供一种处理业务请求的装置，所述装置包括：接收单元，用于接收与业务请求对应的业务请求信息；风险等级确定单元，用于根据所述业务请求信息，确定用于表征所述业务请求的风险等级的风险等级信息；业务服务器确定单元，用于根据所述风险等级，从与所述装置连接的M个业务服务器中确定第一业务服务器；其中，所述第一业务服务器为配置用于接收预定风险等级集的业务服务器，M为正整数；发送单元，用于将所述业务请求信息发送给所述第一业务服务器。可选的，所述装置还包括装置还包括风险规则库；所述风险等级确定单元用于：解析所述业务请求信息，获得解析结果；将所述解析结果与风险规则库的风险规则匹配，生成风险匹配结果；根据所述风险匹配结果，确定所述风险等级信息。可选的，所述装置还包括：风险规则库更新单元，用于更新所述风险规则库，获得更新后的风险规则库。可选的，所述业务服务器确定单元用于：根据所述风险等级，从所述M个业务服务器中确定配置用于接收所述预定风险等级集的N个业务服务器，N为小于等于M的正整数；所述业务服务器确定单元从所述N个业务服务器中确定满足预定条件的业务服务器为所述第一业务服务器。从所述N个业务服务器中确定满足预定条件的业务服务器为所述第一业务服务器。可选的，所述业务服务器确定单元用于：确定所述N个业务服务器中物理上距离所述业务请求的发送端最近的业务服务器为所述第一业务服务器；或，确定所述N个业务服务器中当前传输流量最少的业务服务器为所述第一业务服务器。本发明实施例中，在接收到与业务请求对应的业务请求信息时，应用防火墙可以根据业务请求信息确定出与该业务请求对应的风险等级，也就是说，应用防火墙可以对业务请求进行风险等级的划分，例如划分为优质业务请求、良好业务请求、1级风险业务请求或2级风险业务请求等等，而并非是简单地将业务请求判定为是安全的还是危险的，相当于是说，通过更大力度和更细致的风险评估方式，使得对业务请求信息的风险评估更加的精细和客观，进而可以提高对业务请求的安全性进行评估的准确性；进一步地，应用防火墙将确定了风险等级的业务请求直接分发给相应的业务服务器再由业务服务器对业务请求进行处理，例如由业务服务器对业务请求进行丢弃、转发或者响应的处理，而无需由应用防火墙自身进行处理，这样可以避免由于应用防火墙对业务请求的安全性误判而导致的误丢或者安全问题的出现。同时，由于是先从M个业务服务器中确定出配置用于接收与该业务请求的风险等级相同的业务请求的第一业务服务器，进而再将业务请求分发给第一业务服务器进行处理，相当于是将每个业务请求分发到用于存储对应的风险等级的业务请求的业务服务器，这样可以便于业务服务器对同一风险等级的多个业务请求进行统一处理，并且针对性也较强，可以提高处理效率。此外，由于应用防火墙是按照风险等级将业务请求分发给对应的业务服务器，这样可以使得配置用于接收不同预定风险等级集的多个业务服务器能够对不同的风险等级的业务请求灵活、并行地进行处理，既保证了风险的防范，也达到了高效利用业务服务器资源的目的。附图说明为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据提供的附图获得其他的附图。图1为本发明实施例提供的处理业务请求的方法的流程图；图2为本发明实施例提供的确定业务请求的风险等级的流程图；图3为本发明实施例中风险规则库更新的示意图；图4A为本发明实施例中应用防火墙与多个业务服务器连接的示意图；图4B为本发明实施例中应用防火墙从M个业务服务器中确定N个业务服务器的示意图；图5为本发明实施例提供的装置的结构框图。具体实施方式为使本发明的目的、技术方案和优点更加清楚明白，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。在不冲突的情况下，本发明中的实施例及实施例中的特征可以相互任意组合。并且，虽然在流程图中示出了逻辑顺序，但是在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤。另外，本文中术语“和/或”，仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。另外，本文中字符“/”，在不做特别说明的情况下，一般表示前后关联对象是一种“或”的关系。为了更好的理解上述技术方案，下面将结合说明书附图以及具体的实施方式对上述技术方案进行详细的说明。请参考图1，发明实施例提供一种处理业务请求的方法，该方法可以应用于应用防火墙，即该方法中各步骤的执行主体可以是应用防火墙，具体来说，该方法可以应用于浏览器/服务器构架，客户端/服务器构架，或其它可行的构架模式。该方法的流程描述如下。步骤101：接收与业务请求对应的业务请求信息。其中，业务请求例如可以是通讯请求、交易请求、支付请求、或者其它的业务请求，例如用户需要通过支付宝进行付款时，则可以向支付宝对应的业务服务器发起支付请求，等等。步骤102：根据业务请求信息，确定用于表征业务请求的风险等级的风险等级信息。其中，业务请求信息可以是传输控制协议/因特网互联协议(TransmissionControlProtocol/InternetProtocol，TCP/IP)参考模型中应用层的信息，也可以是TCP/IP参考模型中传输层的信息，也可以是TCP/IP参考模型中网络层的信息，或其它能够被解析的协议层中的信息。在该步骤中对步骤101中接收到的业务请求信息进行处理，进而可以确定出业务请求的风险等级，其中，业务请求的风险等级可以用于表明业务请求存在风险的可能性，当存在风险的可能性越大时，表明对应的业务请求越不安全。在具体实施过程中，可以设置多个风险等级，当设置的风险等级的级别越多时，那么对于业务请求的划分也就可以更加精细，例如设置5个风险等级，那么应用防火墙则可以按照具体的风险等级划分方式将所接收到的业务请求划分为5个风险等级，即可以将接收到的所有的业务请求按照风险等级的不同而划分为5类。其中，风险等级信息可以通过多种能够表示风险等级的方式进行标识，例如阿拉伯数字、罗马数字、字母等字符，或预先设定的代码、字段等等。例如表1所示，那么可以将20％存在风险的业务请求划分到风险等级2的一类业务请求中，以及可以将43％存在风险的业务请求划分到风险等级3的这一类业务请求中，等等。表1存在风险的可能性风险等级[0，10％)风险等级1[10％-30％)风险等级2[30％-60％)风险等级3[60％-80％)风险等级4[60％-100％]风险等级5例如可以依据用于发送业务请求的网际协议(InternetProtocol，IP)地址对业务请求进行风险等级的划分，或者，可以依据业务请求的发起时间对业务请求的风险等级进行划分，或者当业务请求为交易请求时，还可以依据所请求的交易金额对交易请求的风险等级进行划分，等等，在具体实施过程中，可以依据业务请求类型的不同设置不同的风险等级划分方式，或者可以对风险规则进行匹配的匹配结果设置不同的风险等级划分方式，或者还可以有其它的方式对业务请求的风险等级进行划分，本发明实施例不做限制。可选的，请参见图2，本发明实施例提供一种确定业务请求的风险等级的方式，具体包括以下步骤：步骤201：解析业务请求信息，获得解析结果；步骤202：将解析结果与风险规则库进行风险规则匹配，获得风险匹配结果；步骤203：根据风险匹配结果，确定风险等级信息。其中，在步骤201中解析的内容可以是业务请求信息的所有内容，也可以根据实际需要对解析内容的范围进行预先设定，例如，解析的内容包含但不限于域名，IP地址，用户名，密码，业务规则，等等，在对业务请求信息进行解析之后可以获得针对业务请求信息的解析结果。其中，业务规则可以是指所述业务请求所对应的规则，例如当业务请求为交易请求时，业务规则可以为交易金额、交易数量、交易方式等等，再例如当业务请求为数据访问请求时，业务规则可以为访问内容的编码方式、业务请求发送端的设备类型等等，又例如当业务请求为数据更改请求时，业务规则可以为请求更改的数据类型、更改的方式、更改的生效时间等等。应用防火墙中可以预先保存有风险规则库，风险规则库可以是指包含多种风险规则的集合，可以将风险规则库理解为是包括多种风险规则数据的数据库，例如是指包括多种规则数据和逻辑判断规则的集合。其中，规则数据例如可以包括IP地址，域名，网络接入方式，安全类型、业务规则，等等，而其中的安全类型里可以包括结构化查询语言(StructuredQueryLanguage，SQL)注入或跨站脚本注入，等等。进一步地，应用防火墙可以将针对业务请求信息的解析结果与前述的风险规则库进行风险规则匹配，进而获得风险匹配结果。例如，当业务请求为交易请求且风险规则库中的业务规则表明交易金额不超过1000元，那么当解析结果表明交易金额为300元时，则可以认为该请求为安全的，例如将其风险等级确定为如表1中的风险等级1，而当解析结果表明交易金额为20000元时，则可以认为该请求具有风险并且由于请求的交易金额与预定的交易金额之间差距较多，那么可以将其风险等级确定为如表1中的风险等级4，等等。在具体实施实施过程中，在接收到一个业务请求时，可以同时将其解析结果与风险规则库中的一种或多种风险规则进行匹配比较，当只与一种风险规则进行匹配比较时可以在较短时间内即完成匹配过程，确定风险等级的效率较高，当与多种风险规则同时或先后进行匹配比较的话，可以利用决策树法或规则引擎或专家调查法等方法进行匹配以获得匹配结果，通过多种风险规则的匹配可以提高对风险等级确定的准确性，并且还可以获得更加精细的风险等级划分结果。另外，风险规则库可以为静态的，即风险规则库是保持不变的，或者也可以为动态可更新的，即可以对风险规则库进行动态的更新，以使得风险规则库中的风险规则可以随着更新操作而发生相应的变化，例如增加风险规则库所包括的风险规则的种类，例如可以采用如图3所示的方式对风险规则库进行更新以获得更新后的风险规则库。风险规则库更新的方式有多种，例如可以对已有的规则数据进行数据更新，或者也可以根据实际需要增加或者减少规则数据的类型。可行的一种实施方式，根据实际使用的规则数据类型调整解析单元的解析内容范围，同理，也可以根据解析单元能够解析的内容范围确定所需的规则数据类型。在具体实施过程中，对于风险规则库的调整，可以采用规则引擎进行自动的数据库收集、下载以完成更新，即应用防火墙对风险规则库进行自动更新，或者也可以通过人工调整的方式对风险规则库中的规则数据和/或规则进行增删等更新操作，该调整的过程时时生效，以确保更新后的风险规则库能够及时地被应用防火墙使用，这样可以便于应用防火墙根据更新后的风险规则库对业务请求类型的划分可以更加精细、准确。另外，由于将风险规则库单独作为应用防火墙中的一个模块，比如采用规则引擎，能够在更新风险规则库的过程中，可以不需要关闭服务器或者暂停服务器，以确保服务器的持续正常运行。风险规则库更新的方式包括，动态采集用户的业务请求数据，更新风险规则。例如某用户历史上每周的交易业务请求数量均为5次，风险规则库则设定该用户每周的交易业务请求在5次及以下时为安全，并确定该用户每周的前5次交易业务请求的风险等级为如表1中的风险等级1。又例如该用户在某一周的交易业务请求数量达到了6次，风险规则库对该用户的第6次交易业务请求进行风险规则匹配时，则会确认该次交易业务请求具有一定的风险，并进一步确认该次交易业务请求的风险等级，如确认为表1中的风险等级3。但若该用户连续5周的交易业务请求数量均达到了6次，则风险规则库则调整该用户每周的交易业务请求在6次及以下时为安全。风险规则库的规则数据来源可以是互联网上公开的信息，例如危险IP地址名单、域名黑白名单，或者也可以是通过分析已知数据得到的新的规则数据，例如分析日志数据获得规则数据，或者也可以是业务服务器自身的业务规则，或者还可以是其它的能够获得数据的来源，等等，本发明实施例不做限制。进一步地，通过匹配结果确定业务请求的风险等级，即确定风险等级信息，该风险等级信息表征了业务请求的风险情况。例如当风险等级信息通过阿拉伯数字进行标识时，可采用如风险等级1表示安全，风险等级2表示较安全，风险等级3表示可能有危险，风险等级4表示危险程度低，风险等级5表示非常危险，即如表1所示。步骤103：根据风险等级，从与应用防火墙连接的M个业务服务器中确定第一业务服务器；其中，第一业务服务器为配置用于接收预定风险等级集的业务请求的业务服务器，M为正整数。其中，预定风险等级集可以只包括一个风险等级，或者也可以包括多个风险等级。例如，业务服务器1配置用于接收风险等级为风险等级1的业务请求，或者，业务服务器2配置用于接收风险等级为风险等级2、风险等级3和风险等级4的业务请求，等等。如果确定当前接收到的应用请求的风险等级为风险等级1，那么则可以将前述的业务服务器1确定为第一业务服务器，如果确定当前接收到的应用请求的风险等级为风险等级3，那么则可以将前述的业务服务器2确定为第一业务服务器。在实际中，用于配置接收同一预定风险等级集的业务服务器可以包括一个或多个，即M的取值可以为1也可以为大于的整数，例如为10、18，等等。例如与应用防火墙连接的一共有10个业务服务器，即此时M的取值为10，分别为业务服务器1-10，而其中的业务服务器1-3均可配置用于接收风险等级为风险等级2、风险等级3和风险等级4的业务请求，即业务服务器1-3的功能是相同的。在具体实施过程中，为了保证业务请求处理的单一性，以避免多个业务服务器对同一业务请求的重复处理而导致响应混乱，同时也是为了提高每个业务服务器的利用效率，在发送应用请求信息之前，应用防火墙还可以从多个功能相同的业务服务器中确定出一个满足预定条件的业务服务器作为本发明实施例中的第一业务服务器，以通过该一个业务服务器对应用请求进行处理。如图4A所示，图4A为应用防火墙与其连接的M个业务服务器间的连接关系示意图，可见此时M为7，例如将M个业务服务器中功能相同的业务服务器称作是N个业务服务器，而从M个业务服务器中确定出的N个业务服务器的示意图如图4B所示，可见此时N的取值为3，即M个业务服务器中的业务服务器1、业务服务器3和业务服务器6属于功能相同的业务服务器，假设业务服务器1、业务服务器3和业务服务器6都是配置用于存储风险等级为风险等级1和风险等级2的业务服务器。可选的，可以将N个业务服务器中物理上距离业务请求的发送端最近的业务服务器为第一业务服务器，这样可以缩短信息的传输时间，以便请求信息能够尽快被传输至业务服务器进行处理，提高处理效率，可替换的，可以将N个业务服务器中当前传输流量最少的业务服务器为第一业务服务器，这样可以尽量考虑到业务服务器负载均衡，避免将业务请求传输到传输流量较大的业务服务器处而导致等待排队的发生，以尽量提高业务请求的处理效率，同时均衡各个业务服务器的处理负荷。或者，还可以将N个业务服务器中随机选择一个作为第一业务服务器，或者可以综合其它因素从N个业务服务器中确定第一业务服务器，等等，对于从N个业务服务器中确定第一业务服务器的方式本发明实施例不做具体限制。步骤104：将业务请求信息发送给第一业务服务器。在确定出了第一业务服务器之后，便可以将业务请求信息发送给第一业务服务器进行处理，因为第一业务服务器是预先配置好用于存储并处理预定风险等级集的业务请求，所以可以对同一类型或者同一预定风险等级集的多个业务请求进行分组处理，便于提高处理效率，同时，第一业务服务器可以直接面向用户进行交互操作，用户还可以根据自己的实际使用需求或者对业务请求进行人为上的安全性判断以确定是否需要丢弃，所以在一定程度上可以提高对业务请求进行处理的准确性，这样可以满足用户在某些情况下的安全且具有差异化的业务请求。为了便于阅读者理解本发明实施例所提供的技术方案，以下再举例说明。情形一，当风险等级个数为6，且M为6，即应用防火墙共连接有6个业务服务器，每个业务服务器分别用于处理不同等级的业务请求信息时，若业务请求的风险等级为1，则确定6个业务服务器中用于处理风险等级为1的业务服务器为第一业务服务器。情形二，当风险等级个数为6，且M为12，即应用防火墙共连接有12个业务服务器，每两个业务服务器用于处理一个等级的业务请求信息时，例如一号业务服务器和二号业务服务器均用于处理风险等级为1的业务请求，此时一号业务服务器和二号业务服务器合称为N个业务服务器，若业务请求的风险等级为1，则首先从12个业务服务器中确定出一号业务服务器和二号业务服务器，再从一号业务服务器和二号业务服务器中确定出第一业务服务器。情形三，当风险等级个数为6，且M为12，即应用防火墙共连接有12个业务服务器，每两个风险等级组合为一个风险等级集时，例如风险等级1和风险等级2组成风险等级集1，若确定一号业务服务器、二号业务服务器、三号业务服务器用于处理风险等级为风险等级集1的业务请求，此时一号业务服务器、二号业务服务器、三号业务服务器合称为N个业务服务器，当业务请求时风险等级为1，则可以从一号业务服务器、二号业务服务器、三号业务服务器种确定出一个业务服务器作为第一业务服务器。请参见图5，本发明实施例提供了一种处理业务请求的装置，该装置包括接收单元501、风险等级确定单元502、业务服务器确定单元503和发送单元504，而且接收单元501、风险等级确定单元502、业务服务器确定单元503和发送单元504可以通过硬件处理器来实现相关功能单元。其中：接收单元501，用于接收与业务请求对应的业务请求信息；风险等级确定单元502，用于根据业务请求信息，确定用于表征业务请求的风险等级的风险等级信息；业务服务器确定单元503，用于根据风险等级从与该装置连接的M个业务服务器中确定第一业务服务器；其中，第一业务服务器为配置用于接收预定风险等级集的业务服务器，M为正整数；发送单元504，用于将业务请求信息发送给第一业务服务器。可选的，该装置还包括风险规则库，风险等级确定单元502用于：解析业务请求信息，获得解析结果；将解析结果与风险规则库进行风险规则匹配，获得风险匹配结果；根据风险匹配结果，确定风险等级信息。可选的，该装置还包括：风险规则库更新单元，用于更新风险规则库，获得更新后的风险规则库。可选的，业务服务器确定单元503用于：根据风险等级，从M个业务服务器中确定配置用于接收预定风险等级集的N个业务服务器，N为小于等于M的正整数；从N个业务服务器中确定满足预定条件的业务服务器为第一业务服务器。可选的，业务服务器确定单元503用于：确定N个业务服务器中物理上距离业务请求的发送端最近的业务服务器为第一业务服务器；或，确定N个业务服务器中当前传输流量最少的业务服务器为第一业务服务器。由于本发明实施例中的装置与上述处理业务请求的方法解决问题的原理相似，因此本发明实施例中装置的实施可以参见上述处理业务请求的方法的实施，在此不再赘述。本发明实施例中，在接收到与业务请求对应的业务请求信息时，装置可以根据业务请求信息确定出与该业务请求对应的风险等级，也就是说，装置可以对业务请求进行风险等级的划分，例如划分为优质业务请求、良好业务请求、1级风险业务请求或2级风险业务请求等等，而并非是简单地将业务请求判定为是安全的还是危险的，相当于是说，通过更大力度和更细致的风险评估方式，使得对业务请求信息的风险评估更加的精细和客观，进而可以提高对业务请求的安全性进行评估的准确性；进一步地，装置将确定了风险等级的业务请求直接分发给相应的业务服务器再由业务服务器对业务请求进行处理，例如由业务服务器对业务请求进行丢弃、转发或者响应的处理，而无需由装置自身进行处理，这样可以避免由于装置对业务请求的安全性误判而导致的误丢或者安全问题的而出现。同时，由于是先从M个业务服务器中确定出配置用于接收与该业务请求的风险等级相同的业务请求的第一业务服务器，进而再将业务请求分发给第一业务服务器进行处理，相当于是将每个业务请求分发到用于存储对应的风险等级的业务请求的业务服务器，这样可以便于业务服务器对同一风险等级的多个业务请求进行统一处理，并且针对性也较强，可以提高处理效率。此外，由于装置是按照风险等级将业务请求分发给对应的业务服务器，这样可以使得配置用于接收不同预定风险等级集的多个业务服务器能够对不同的风险等级的业务请求灵活、并行地进行处理，既保证了风险的防范，也达到了高效利用业务服务器资源的目的。以上所描述的装置实施例仅仅是示意性的，其中作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性的劳动的情况下，即可以理解并实施。通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到各实施方式可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件。基于这样的理解，上述技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品可以存储在计算机可读存储介质中，如ROM/RAM、磁碟、光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行各个实施例或者实施例的某些部分所述的方法。最后应说明的是：以上实施例仅用以说明本发明的技术方案，而非对其限制；尽管参照前述实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本发明各实施例技术方案的精神和范围。当前第1页1 2 3