访问控制方法、设备及***
技术领域
本发明的软件控制技术,尤其是涉及客户端访问控制。
背景技术
目前随着计算机软件技术及电子商务的发展,为大量客户通过标准接口例如http协议接口访问***平台并开发前端应用提供了大量机会。然而在作为平台的后端开发过程中,如果客户端频繁甚至滥用接口调用后端,一旦超过某个阈值,后端将无法响应客户端请求或响应的非常慢。为了防止这种情况的发生,保护后端服务器的资源,保证服务的高可用,通常需要对接口调用量进行限制。
图1示出了现有技术中限制***接口调用量的控制***。如图所示,该控制***包括:数据库100、控制设备200以及可选的数据库300。数据库100用于维护不同客户端对接口的当前实际发生的调用量;数据库300中存储有客户端身份信息以及关于客户端访问的授权信息,例如允许不同客户端调用***接口的最大允许调用量。控制设备200根据来自客户端的调用接口的请求,生成用于查询客户端的当前实际调用量的查询请求,并从数据库100接收作为所述查询请求的响应的客户端当前实际调用量。同时,控制设备200从数据库300获取当前客户端的最大允许调用量的限定阈值。控制设备200对比所接收的当前实际调用量以及最大调用量阈值而决定是否允许所述客户端继续调用接口,并且在允许所述客户端调用接口时更新所述数据库100中的当前实际调用量。而一旦当前实际调用量达到最大调用量的限定阈值,则可以拒绝调用请求,例如重定向到错误页或者返回服务不可用、排队或者等待,降级等处理。该方案所带来的一个问题是当数据库100故障时,则无法获取客户端的当前调用量,因此导致无法限制客户端的调用量或者出现宕机等问题。
发明内容
本发明提代一种改进的访问控制方案,通过一个备用数据库来同步备份主数据库的客户端访问记录,并通过监视客户端的访问请求而将客户端的访问维持在一个可控的状态。
根据本发明的一个方面,提供一种访问控制方法,包括:控制第一数据库将客户端访问记录同步到第二数据库作为备用访问记录,以便在所述第一数据库不能对查询请求进行响应时提供所述备用访问记录,其中该查询请求是响应于客户端访问请求而用于获取所述第一数据库上的客户端访问记录;接收查询消息并将其缓存到消息缓冲池中,该查询消息是基于所述第一数据库不能对所述查询请求进行响应而发出的;监听所述消息缓冲池中的查询消息以按照该查询消息中包含的客户端标识生成关于所述客户端访问请求的统计信息,其中,当所述统计信息满足一预定条件时,输出所述统计信息以更新所述第二数据库中与所述客户端标识对应的备用访问记录。
根据本发明的另一个方面,提供一种访问控制设备,包括:监控模块,配置为控制第一数据库将客户端访问记录同步到第二数据库作为备用访问记录;所述第二数据库,配置为当所述第一数据库不能响应于查询请求而提供述客户端访问记录时,提供所述备用访问记录作为所述查询请求的响应,其中该查询请求是响应于客户端访问请求而用于获取所述第一数据库上的客户端访问记录;消息缓冲池,用于接收查询消息并将其缓存到消息缓冲池中,该查询消息是基于所述第一数据库不能对所述查询请求进行响应而发出的,该查询消息包含有关所述查询请求的信息;其中,所述监控模块进一步配置为监听所述消息缓冲池中的查询消息以按照该查询消息中包含的客户端标识生成关于所述户访问请求的用统计信息,其中,当所述统计信息满足一预定条件时,输出该统计信息以更新所述第二数据库中与所述客户端标识对应的备用访问记录。
根据本发明的再一个方面,提供一种访问控制***,包括:第一数据库,用于维护客户端访问记录;第一控制设备,配置为:响应于客户端访问请求,向所述第一数据库发送查询请求并从第一数据库接收作为所述查询请求的响应的所述客户端访问记录,以及在不能从第一数据库接收到所述客户端访问记录时生成查询消息;第二控制设备,包括:监控模块,配置为控制所述第一数据库将客户端访问记录同步到第二数据库作为备用访问记录;所述第二数据库,配置为当所述第一控制设备不能从第一数据库接收所述客户端访问记录时,向所述第一控制设备提供所述备用访问记录作为所述查询请求的响应;消息缓冲池,用于接收并缓存来自所述第一控制设备的所述查询消息,该查询消息包含有关所述查询请求的信息;其中,所述监控模块进一步配置为监控所述消息缓冲池中的查询消息以按照该查询消息中包含的客户端标识生成关于所述客户端访问请求的统计信息,其中,当所述统计信息满足一预定条件时,所述监控模块输出该统计信息以更新所述第二数据库中与所述客户端标识对应的备用访问记录。
根据本发明的再一个方面,提供一种具有指令的机器可读介质,所述指令在被一个或多个机器执行时,使所述机器执行根据本发明的方法。
根据本发明的再一个方面,提供一种访问控制设备,包括:存储器,其上存储有指令;处理器,所述处理器可配置为执行所述指令以实现根据本发明的方法。
利用本发明的方案,即便是在数据库故障时仍然可以对诸如接口调用等客户端访问进行限制,避免了拖库、接口滥用导致的服务宕机等情况的发生。
附图说明
图1示出了现有技术的访问控制***的示意性框图;
图2示出了根据本发明一个实施例的访问控制***的示意性框图;
图3示出了根据本发明一个实施例的访问控制***的内部的操作示意图;
图4A与4B示出了根据本发明实施例的访问控制流程图;
图5示出根据本发明的一个实施例中的控制设备的示意图。
具体实施方式
下面结合附图对本发明实施例提供的***、方法和设备进行详细说明。虽然附图中显示了本公开的优选实施方式,然而应该理解,可以以各种形式实现本公开而不应被这里阐述的实施方式所限制。相反,提供这些实施方式是为了使本公开更加透彻和完整,并且能够将本公开的范围完整的传达给本领域的技术人员。在本说明书中,相同的附图标记指示相同的部件。
在以下说明中,‘客户端’既可以是指客户端设备的操作者,也可以是客户端设备本身,而‘客户端访问请求’则是指通过客户端设备发出的访问请求,这里的访问请求既可以是访问某一个***、数据库或服务器,也可以是调用***资源,例如***接口、计算资源等。
图2示出了根据本发明一个实施例的访问控制***10的示意图,该访问控制***用于对客户端的访问操作进行控制。如图所示,该访问控制***10除了包括数据库100以及控制设备200之外,还包括备份控制设备400,其中控制设备400包括备用数据库401、监控模块402以及消息缓冲池403。数据库100作为主数据库用于维护客户端访问记录,例如历史访问次数等。控制设备200响应于来自客户端的访问请求,向数据库100发送查询请求以希望获取客户端的当前访问记录,并从数据库100接收作为所述查询请求的响应的客户端访问记录,由此控制设备200可以基于接收到的客户端访问记录来确定是否允许本次访问请求。此外,控制设备200还可以在不能从数据库100接收到客户端访问记录时向控制设备400发送查询请求,同时生成包含有关该客户端访问请求的查询消息。
控制设备400中的监控模块402配置为控制数据库100按照预定的定时要求将其中存储的客户端访问记录同步到备用数据库401作为备用访问记录。由此当例如主数据库100发生故障,所述控制设备200不能从数据库100接收到客户端访问记录时,备用数据库401根据接收到的来自控制设备200的查询请求向控制设备200提供所述备用访问记录作为所述查询请求的响应。由此,即便是控制设备200不能从数据库100接收到客户端访问记录,也可以基于接收到的备用访问记录来确定是否允许本次访问请求。
此外,控制设备400中的消息缓冲池403接收来自控制设备200的查询消息并排队缓存。监控模块402监听消息缓冲池中的查询消息以按照该查询消息中包含的客户端标识生成关于所述客户端访问请求的统计信息,并且当统计信息满足一预定条件时,监控模块402输出该统计信息以更新备用数据库中与所述客户端标识对应的备用访问记录。按照本发明的一个实施例,当数据库100恢复对查询请求的响应时,监控模块402控制备用数据库401将更新的备用访问记录同步到数据库100,其中数据库100可利用更新的备用访问记录来更新客户端访问记录。
以下结合客户端调用接口的实例来详细描述本发明的访问控制***及各控制设备的操作。
按照本发明的该实施例,对于不同客户端的每次接口调用,控制***10都会记录,并通过数据库100来维护不同客户端的当前接口调用记录,包括已经发生的接口调用量CallCount,即接口调用次数。当控制设备200接收到来自客户端的新的接口调用请求CallRequest时,基于该请求CallRequest生成查询该户的当前调用量的查询请求QueryCount,并发送到数据库100。随后控制设备200从数据库100接收作为所述查询请求的响应的当前接口调用量CallCount,控制设备200基于从数据库100返回的接口调用量CallCount来确定是否允许客户端调用接口,例如通过与针对该客户端设置的最大接口调用量MaxCallCount的比较来做出决定。
根据该实施例,当数据库100发生故障时,控制设备200不能从数据库100接收到相应的接口调用量CallCount,例如在预定的定时内不能接收到作为所述查询请求QueryCount的响应的接口调用量CallCount或接收到错误故障提示,控制设备200将所述查询请求QueryCount发送给备份控制设备400,同时控制设备200创建一查询消息QueryMessage,该查询消息包含了有关接口调用请求CallCount的信息,其中包含有发起所述接口调用请求CallRequest的客户端标识。随后,控制设备200将该查询消息QueryMessage也发送给备份控制设备400。
如图所示,控制设备400中的备用数据库401存储有数据库100同步的各客户端的当前调用量的备份,以下以CallCount_Standby表示,其中监控模块402可控制数据库100将客户端接口调用记录周期性地同步到备用数据库401中,以供控制设备200查询。监控模块402也可以设置一个任务定时器,以便按照需要来定时完成数据库100与数据库401之间的同步目的。由此,当从控制设备200接收到查询请求QueryCount时,控制设备400中的备用数据库401将备用接口调用量CallCount_Standby作为响应发送回控制设备200。由此200基于从数据库401返回的接口调用量CallCount_Standby来确定是否允许客户端本次调用接口的请求。
此外,消息缓存器403也接收到控制设备200发送的查询消息QueryMessage并缓冲起来。由于控制设备200可能会接收到来自一个或多个客户端的大量的接口调用请求,消息缓冲池403同样会接收到大量的来自控制设备200的查询消息,由此,消息缓冲池403对接收到的查询消息QueryMessage进行排队并缓存起来,例如按照先入先出(FIFO)的原则。
监控模块402对消息缓冲池403进行监听,以确定其中是否有待处理的查询消息,并按照该查询消息中包含的客户端标识生成关于接口调用请求的统计信息。在一个示例中,当确定消息缓冲池403存在待处理的消息队列时,监控模块402按顺序例如FIFO规则处理该消息队列中的每个消息。监控模块402首先从缓冲池403中提取第一个查询消息QueryMessage1,解析该消息以确定该查询消息中所包含的客户端标识信息,假设所包含的客户端标识为ID1。随后监控模块402启动与所标识的客户端ID1相关的计数器CT1,并将该计数器CT1的计数值+1,作为客户端ID1的接口调用请求CallCount的统计数据CountStatistic,其中计数器ID1的初始值为0。随后,监控模块402从缓冲池403中提取第二个查询消息QueryMessage2,解析该消息以确定该查询消息中所包含的客户端标识信息。假设所包含的客户端标识为ID2,监控模块402启动与所标识的客户端ID2相关的计数器CT2,并将该计数器CT2的计数值+1作为客户端ID2的统计数据统计数据。如果监控模块403解析出第二个查询消息QueryMessage2中所包含的客户端标识仍为ID1,监控模块402将客户端ID1的计数器CT1的统计数据再次加1。
在统计查询消息的同时,监控模块402监听各个客户端的计数器CT的统计数据CountStatistic,并判统计数据是否满足一定的条件。作为一个示例,该预定条件是允许客户端调用接口的最大允许调用量MaxCallCount的一个额外冗余量Δmax。例如,当监控模块402监测到客户端ID1的计数器ID1-COUNT的统计数据CountStatistic达到额外冗余量Δmax时,则监控模块402利用当前的CountStatistic更新备用数据库401中存储的客户端ID1的当前接口调用量CallCount_Standby。在一个示例中,监控模块402可以向备用数据库401发送一个更新命令或代码,在该命令中包含客户端身份ID1、统计数据CountStatistic等信息。在接收到更新命令后,备用数据库403就可以将相应客户端的当前接口调用量累加上CountStatistic并更新当前调用量,即CallCount_Standby+CountStatistic→CallCount_Standby。也就是说,按照该实施例,备用数据库401每隔CountStatistic次调用接口请求后就会得到一次更新。由此,按照本发明,即使是在控制设备200不能从数据库100接收到相应的接口调用量CallCount时,也可以通过查询备用数据库401的方式获取客户端的不断更新的接口调用记录,从而做出是否允许客户端接口调用的决策。利用本发明的方案,不但保证了***对接口调用的支持的持续,避免了当数据库100故障时,无法对调用量进行限制的情况发生,而且也能使客户的调用量保持可控,即控制在Δmax+MaxCallCount的范围内,从而保证一定的调用量限制功能,阻止了整个服务被拖库、宕机的情况的发生。
此外,监控模块402还可设置一个定时器,用于设置客户端调用量限制的清零时间,从而可在定时到期后清除备用数据库401中记录的备用调用量数据CallCount,以便在新的时间周期内恢复客户在最大调用量MaxCallCount下对接口的调用。
按照本发明一个实施例,监控模块402可以设计为在确认消息缓冲池中排队了查询消息后,定期地监视数据库100的状态以确认数据库100是否恢复正常工作,并且在确认数据库100可以正常工作时,指示备用数据库401将其中存储的备份调用记录同步给数据库100。该同步操作可以在监控模块402确认消息缓存池403中没有查询消息时才开始,也可以选择忽略消息缓存池403中的剩余未处理的查询消息,这样的代价只是会向客户端多开放了一些接口调用次数。
按照本发明一个实施例,由于数据库100需要频繁地访问进行读写等操作,因此可以采用一个关系数据库例如tair、redis/memcache类型的数据库,而备用数据库401则可以采用hbase,mssql类型的数据库实现。由此,利用本发明的方案,在tair等类型的关系数据库故发生障时可能出现的无法限制客户端调用量的情况,通过利用hbase等类型数据库来作为服务降级方案,在一定程度上仍然可以对客户端调用进行限制,避免了拖库、接口滥用导致的服务宕机等情况的发生,且成本更低。
在本发明的另一实施例中,访问控制***10还可以包括一个验证数据库200,用于存储客户端身份信息以及关于客户端访问的授权信息,例如允许不同客户端调用***接口的最大调用量MaxCallCount,其中控制设备200通过对比从数据库100或401接收的调用量CallCount或CallCount_Standby以及最大允许调用量而决定是否允许所述客户端调用接口。但不难想到,验证数据库200并不是必须的,例如客户端身份信息以及接口最大调用量信息也可以存储于控制设备200或其它位置。
图3示出根据本发明一个实施例的控制设备200、数据库100、与备份控制设备400中的备用数据库401、监控模块402以及消息缓冲池403的操作示意图。如图中所示,S1表示:在控制设备400的控制下,数据库100将其中存储的客户端接口调用记录CallCount同步至备用数据库401中。S2表示:控制设备200根据接收到的客户端接口调用请求CallRequest而向数据库100发送查询客户端的当前调用量CallCount的请求QueryCount。S3表示:数据库100没有响应,例如控制设备200收到一个出错信息Error。S4表示:在没有从数据库100获取到当用调用量的情况下,控制设备200向备用数据库401发送查询请求QueryCount,同时或随后,向消息缓冲池403发送一个查询消息QueryMessaage。S5表示:在收到来自控制设备200的查询请求QueryCount后,备用数据库401返回客户端的备用接口调用量记录CallCount_Standby,从而便于控制设备200基于该返回的备用调用量记录CallCount_Standby做出相应的决策。S6表示:监控模块402监听消息缓冲池403以查看其中是否存在正在排队的查询消息QueryMessaage,在存在查询消息排队情况下通过解析并统计每个查询消息QueryMessaage来统计客户端的接口调用请求CallRequest,并生成统计数据CountStatistic。S7表示:在针对某一客户端的统计数据CountStatistic达到一预定条件时,向备用数据库401发送统计数据CountStatistic,由此,备用数据库401利用该统计数据CountStatistic更新其中存储的备用接口调用量CallCount_Standby。S8表示:监控模块402监听数据库100以确认其工作状态是否正常,并且在正常时指示所述备用数据库401将当前调用量CallCount_Standby同步至数据库100。
图4A和4B示出了根据本发明实施例的在访问控制***10内实现的访问控制流程图,其中图4A示出了由控制设备200实现的流程,而图4B示出了由控制设备400实现的流程。
以下仍以客户端调用接口实例来说明图4A所示的流程图。在步骤401,控制设备200接收客户端调用接口请求CallRequest,然后在步骤402生成获取当前客户端的实际接口调用量CallCount的查询请求QueryCount,并向数据库100发送查询请求QueryCount。
在步骤403,监控数据库100是否返回响应。如果作为响应,从数据库100接收到所返回的当前接口调用量CallCount,则进程前到步骤404。在步骤404,将所查询的客户端的当前实际调用量CallCount与针对该客户端的最大允许调用量MaxCallCount进行对比,当没有超出最大允许调用量时,则授权本次的客户端接口调用请求,然后进程前进到步骤405。在步骤405,判断在步骤403返回的当前接口调用量数据的来源,即是来自数据库100还是备用数据库401,如果来自数据库100,则前进到步骤406;如果来自数据库401,则前进到步骤407,流程结束。
在步骤406,向数据库100发送更新指令,指示数据库100将当用的调用量CallCount加1并更新,即CallCount+1→CallCount。然后进程前进到步骤407,流程结束。
如果在步骤404判断当前调用量CallCount已经达到最大允许调用量MaxCallCount,则禁止客户端的本次调用请求CallRequest,然后前进至步骤407,流程结束。
如果在步骤403,控制设备200在预定的定时内没有从数据库100收到当前接口调用量的响应信号,或者收到一个出错信息Error,例如指示数据库100故障的信息,则进入步骤408。
在步骤408,控制设备200向控制设备400中的备用数据库401发送查询请求QueryCount,同时基于该客户端接口调用请求CallRequest生成一个查询消息QueryMessage并将其发送给控制设备400中的消息缓冲池403。控制设备200从备用数据库401接收作为查询请求QueryCount的响应的备用调用量记录CallCount_Standby,然后进入步骤404。通过执行步骤404-405完成本次调用请求的验证与授权过程。
图4B示出了在控制***10内由控制设备400执行的访问控制的方法流程图。如前所述,控制设备400用于维护控制设备200所使用的备用数据库401,以实现对客户端访问的有限控制。由控制设备400实施的方法包括:控制主数据库100将客户端访问记录同步到备用数据库作为备用访问记录,以便在主数据库不能对查询请求进行响应时提供所述备用访问记录;接收来自外部的控制设备200的查询消息并将其缓存到消息缓冲池中,该查询消息是基于主数据库不能对控制设备200的查询请求进行响应而发出的;监听消息缓冲池中的查询消息以按照该查询消息中包含的客户端标识生成关于客户端访问请求的统计信息,其中,当所述统计信息满足一预定条件时,输出该统计信息以以便备用数据库利用该统计信息更新其中存储的客户端的备用访问记录。
以下仍以客户端调用接口实例并结合图4A来说明图4B的流程。
在步骤501,备用控制设备400设置同步定时,以便控制数据库100按照预定的定时将其中存储的客户端接口调用记录CallCount同步至备用数据库403,并作为备用调用记录CallCount_Standby存储起来。
在步骤502,接收来自控制设备200在步骤408发送的查询消息QueryMessage后,将其放入消息缓冲池403。在缓冲池403中,如果连续收到多个查询消息,则对这些查询消息进行排队,例如按照FIFO原则。
在步骤503,监听缓冲池403以确认其中是否有查询消息QueryMessage在排队。如果存在排队的查询消息,则从缓冲池403中提取第一个查询消息QueryMessage,解析该查询消息QueryMessage以确定其中所包含的客户端标识信息。如果所包含的客户端标识为ID1,则启动与所标识的客户端ID1相关的计数器CT1,并将该计数器CT1的计数值+1,作为对客户端的调用请求次数的统计数据CountStatistic。随后,监控模块402从缓冲池403中提取并解析第二个查询消息。如果第二个查询消息来自不同的客户端,则启动与其对应的计数器。例如如果客户端标识为ID2,监控模块402启动与所标识的客户端ID2相关的计数器CT2以将该计数器CT2的计数值+1。如果监控模块403解析出第二个查询消息中所包含的客户端标识仍为ID1,监控模块402将客户端ID1的计数器CT1的计数值再次加1。以此方式重复处理消息缓冲池403中排队的消息。
在步骤504,检测每个客户端的计数器CT的计数值是否满足一预定条件,例如是否达到了最大冗余量Δmax。如果没有达到预定条件,则回到步骤504,继续监听缓冲池403并处理查询消息。如果确认计数器CT的计数值已经满足了预定条件,则前进到步骤505。
在步骤505,向备用数据库401发送更新命令,在该更新命令中包含统计的计数CountStatistic,由此,备用数据库401利用统计数据CountStatistic更新相应客户端的备用调用量记录:
CallCount_Standby+CountStatistic→CallCount_Standby。
在向备用数据库401发送更新命令后,同时复位客户端的计数器CT,以执行下一轮统计。
这里需要指出的是,如果对于所有客户端均设置了相同的最大冗余量Δmax时,则可以向备用数据库401发送一个简单的更新命令,由此,备用数据库401可以根据接收到更新命令,可以每次均用最大冗余量Δmax来更新其存储的当用调用量当前调用量,即
CallCount_Standby+Δmax→CallCount_Standby。
在本发明的另一实施例中,还包括步骤506,控制设备400确定数据库100的工作是否恢复正常,如果恢复正常,则生成一个更新数据库100中的接口调用记录CallCount的更新请求并发送给数据库100,该更新请求可同时包含备用数据库403中的当前调用记录CallCount_Standby。从而数据库100在接收到该更新请求后更新其调用记录,实现与备用数据库401的同步。如果确定数据库100仍工作异常,则继续检测消息缓冲池403中是否有查询消息。
本发明参照图4B的实施例的方案不限于对接口调用方案的备份控制,而是可以适用于其它可预见的备用数据库或服务器的控制。从而避免由于频繁读取备用数据库或服务器而造成对备用数据库或服务器的干扰和不必要的资源浪费。
需要指出的是,虽然如上参照图2到图4A、4B,对根据本公开的访问控制设备、***及方法的实施例进行了描述,但本发明并不限于此。此外,图2中的各模块可以包括处理器、电子设备、硬件设备、电子部件、逻辑电路、存储器、软件代码、固件代码等,或者它们的任意组合。技术人员还将认识到的是,结合本文公开内容描述的各种说明性的逻辑方框、模块和方法步骤可以实现为电子硬件、计算机软件或二者的组合。以软件实现为例,作为一个逻辑意义上的识别装置,是通过处理器将非易失性存储器中对应的计算机程序指令读取内存中运行形成的。从硬件层面而言,如图5所示,在一种实现方式中,根据本发明的控制设备200或400可以由一个或多个计算机实现,除了图5所示的处理器、内存、网络接口以及非易失性存储器之外,实施例中实现控制设备的计算机通常根据其实际功能,还可以包括其它硬件,对此不再赘述。这里需要说明的是,在由图5所示的计算机实现备份控制设备400的情况下,备用数据库401可以位于计算机本地(图中未出),例如计算机内部一个或多个存储器上。
本发明另一实施例提供的机器可读介质上存储有机器可读指令,该机器可读指令在被计算机执行时,使计算机执行本文公开的前述的任一种方法。具体地,可以提供配有机器可读介质的***或者装置,在该机器可读介质上存储着实现上述实施例中任一实施例的功能的软件程序代码,且使该***的机器读出并执行存储在该机器可读介质中的机器可读指令。在这种情况下,从机器可读介质读取的程序代码本身可实现上述实施例中任何一项实施例的功能,因此机器可读代码和存储机器可读代码的机器可读介质构成了本发明的一部分。机器可读介质的实施例包括软盘、硬盘、磁光盘、光盘、磁带、非易失性存储卡和ROM。可选择地,可以由通信网络从服务器计算机上或云上下载程序代码。
需要说明的是,上述各流程和识别装置的结构图中不是所有的步骤或模块都是必须的,可以根据实际的需要忽略某些步骤或模块。各步骤的执行顺序不是固定的,可以根据需要进行调整。上述各实施例中描述的***结构可以是物理结构,也可以是逻辑结构,即,有些模块可能由同一物理实体实现,或者,有些模块可能分由多个物理实体实现,或者,可以由多个独立设备中的某些部件共同实现。
上文通过附图和优选实施例对本发明进行了详细展示和说明,然而本发明不限于这些已揭示的实施例,基与上述多个实施例本领域技术人员可以知晓,可以组合上述不同实施例中的代码审核手段得到本发明更多的实施例,这些实施例也在本发明的保护范围之内。