针对目标应用的调用请求的处理方法、系统、界面和存储介质与流程

1.本技术涉及云应用技术领域，尤其涉及一种针对目标应用的调用请求的处理方法、系统、界面和存储介质。


背景技术：

2.随着云技术的发展，应用服务提供商越来越多地使用云技术来通过互联网向用户提供应用服务。在这样的云应用环境下，应用服务提供商需要将应用安装在云环境中，从而在向外提供应用服务的过程中，可以根据用户的请求来通过各个应用的接口来调用相应的应用，以实现对应的功能。因此，当使用某个应用的用户数量较多时，通过互联网接收到的用户请求的数量也较多，如果在同一时间或一段时间内，用户请求使用应用的某一个功能或更多功能的请求数量剧增，那么对应的应用的调用次数也随之增加，以便于分别处理用户的请求。而应用的调用需要使用云平台为其分配的物理资源，但是通常情况下这样的物理资源是有限的，也就是说应用的各个应用在一定时间段内的调用次数也是有限的。换言之，应用在一定时间内能够处理的用户请求的数量是有限的。因此，如果在短时间内用户的这样的请求非常集中，超过了应用所能够使用的资源的处理能力，那么就会导致处理这些请求消耗了过多或者甚至分配给该应用的全部物理资源，从而导致应用无法再为用户提供服务。


技术实现要素：

3.本技术实施例提供一种针对目标应用的调用请求的处理方法、系统、界面和存储介质，以解决现有技术中对于用户的请求的限制不合理的缺陷。
4.为达到上述目的，本技术实施例提供了一种针对目标应用的调用请求的处理方法，包括：
5.接收用户针对所述目标应用的调用请求，其中所述调用请求中包含有用户的用户标识以及所述目标应用的应用标识；
6.根据所述用户标识以及所述应用标识获取允许用户调用目标应用的调用条件，其中所述调用条件是响应于所述调用请求根据所述用户的用户信息以及目标应用的应用信息而实时生成的；
7.确定所述用户当前对于所述目标应用的调用请求是否符合所述调用条件；
8.当确定所述调用请求符合所述调用条件时执行所述调用请求。
9.本技术实施例还提供了一种针对目标应用的调用请求的处理系统，包括请求处理模块和调用条件生成模块，
10.其中，所述请求处理模块用于接收用户针对所述目标应用的调用请求，其中所述调用请求中包含有用户的用户标识以及所述目标应用的应用标识；根据所述用户标识以及所述应用标识获取允许用户调用目标应用的调用条件；确定所述用户当前对于所述目标应用的调用请求是否符合所述调用条件；
11.所述调用条件生成模块用于根据用户的用户标识获取用户的用户信息，以及根据应用的应用标识获取应用的应用信息，以及根据用户信息和应用信息实时生成所述调用条件。
12.本技术实施例还提供了一种针对目标应用的调用请求的处理界面，应用于用于管理应用的人员的终端，并包括：
13.请求显示区，用于显示用户针对所述目标应用的调用请求，其中所述调用请求中包含有用户的用户标识以及所述目标应用的应用标识；
14.调用条件显示区，用于显示允许用户调用所述目标应用的调用条件，其中，所述调用条件是响应于所述调用请求根据所述用户的用户信息以及目标应用的应用信息而生成的；
15.处理结果反馈区，用于显示所述用户当前对于所述目标应用的调用请求是否符合所述调用条件，以及接收针对用户对反馈结果的指令。
16.本技术实施例还提供了一种电子设备，包括：
17.存储器，用于存储程序；
18.处理器，用于运行所述存储器中存储的所述程序，所述程序运行时执行本技术实施例提供的处理方法。
19.本技术实施例还提供了一种计算机可读存储介质，其上存储有可被处理器执行的计算机程序，其中，该程序被处理器执行时实现如本技术实施例提供的处理方法。
20.本技术实施例提供的针对目标应用的调用请求的处理方法、系统和界面、调用条件生成方法和存储介质，通过接收用户针对目标应用的调用请求，该请求中包含用户标识和目标应用的应用标识，并根据该请求中的用户标识和应用标识来获取允许用户调用目标应用的调用条件，并且根据目标应用的运行状态和该调用条件来对调用请求进行处理，因此，能够在接收到用户的请求获取响应于该请求生成的调用条件，从而这样在接收到用户请求之后才生成的调用条件能够及时地反映当前用户请求调用应用的实际情况，实现了调用条件的实时动态生成，从而能够更加合理地对用户的请求进行处理，提高了处理的合理性，并确保了用户对于应用的合理调用，并因此提高了系统资源的利用率。
21.上述说明仅是本技术技术方案的概述，为了能够更清楚了解本技术的技术手段，而可依照说明书的内容予以实施，并且为了让本技术的上述和其它目的、特征和优点能够更明显易懂，以下特举本技术的具体实施方式。
附图说明
22.通过阅读下文优选实施方式的详细描述，各种其他的优点和益处对于本领域普通技术人员将变得清楚明了。附图仅用于示出优选实施方式的目的，而并不认为是对本技术的限制。而且在整个附图中，用相同的参考符号表示相同的部件。在附图中：
23.图1a为本技术实施例提供的请求处理方案的应用场景示意图；
24.图1b为本技术实施例提供的请求处理界面的示意图；
25.图2为本技术提供的请求处理方法的一个实施例的流程图；
26.图3为本技术提供的调用条件生成方法的一个实施例的流程图；
27.图4为本技术提供的请求处理系统的实施例的结构示意图；
28.图5为本技术提供的电子设备实施例的结构示意图。
具体实施方式
29.下面将参照附图更详细地描述本公开的示例性实施例。虽然附图中显示了本公开的示例性实施例，然而应当理解，可以以各种形式实现本公开而不应被这里阐述的实施例所限制。相反，提供这些实施例是为了能够更透彻地理解本公开，并且能够将本公开的范围完整的传达给本领域的技术人员。
30.实施例一
31.本技术实施例提供的方案可应用于任何具有应用调用能力的系统，例如包括有云计算资源调度功能的芯片以及相关应用的服务器系统等等。图1a为本技术实施例提供的请求处理方案的应用场景示意图，图1a所示的场景仅仅是本技术的技术方案可应用的示例之一。
32.在云计算得到广泛应用的今天，应用服务提供商越来越多地使用云技术来通过互联网向用户提供应用服务。在这样的云应用环境下，应用服务提供商需要将应用安装在云环境中，从而在向外提供应用服务的过程中，可以根据用户的请求来通过应用的接口来调用，以实现对应的功能。
33.因此，当使用某个应用的用户数量较多时，通过互联网接收到的用户请求的数量也较多，如果在同一时间或一段时间内，用户请求使用应用的某一个功能或更多功能的请求数量剧增，那么对应的应用的调用次数也随之增加，以便于处理更多请求。而应用执行用户的请求需要使用云平台为其分配的物理资源，但是通常情况下这样的物理资源是有限的，也就是说应用的各个应用的调用频率也是有限的。换言之，目标应用在一定时间内能够处理的用户请求的数量是有限的。因此，如果在短时间内用户的这样的请求非常集中，超过了该应用所能够使用的资源的处理能力，那么就会导致该应用消耗了过多或者甚至分配给该应用的全部物理资源，从而导致应用无法再为用户提供服务。
34.因此，为了解决用户的过多请求导致应用所使用的计算资源耗尽的问题，在现有技术中已经提出了预先设置在一定时间内接收到的用户请求阈值的方式来限制应用被调用过多次数的方案。这也被称为计数器算法。例如，可以由应用的开发人员或维护人员根据应用的用途等来预先设置针对该应用的接口在一定时间内执行的请求次数阈值，或者也可以设置对于该应用的接口在一定时间内执行的总请求次数阈值，甚至也可以设置对于该应用的各个应用在一定时间内的请求次数阈值，从而当该应用投入使用之后，可以先将该计数器清零并对时间开始计时，当每收到一个对应的请求时，就将计数器的计数值加一，从而在该一定时间内当计数器的计数值超过了预设的请求次数阈值时，就拒绝接下来接收到的请求。
35.之后，可以在计数器的计数值达到了预设的请求次数阈值之后，进一步检测接下来收到请求的时间是否仍然在该一定时间内，如果仍然处于该一定时间内，则可以认为该请求是过量请求，从而可以拒绝该请求，以此类推。而如果该时间已经超出了该一定时间，则可以认为对应应用已经有充足的时间完成了前面的处理，并降低了其处理负荷，因此可以将计数器的计数值清零，并接收该请求作为第一个请求来调用该应用进行处理。
36.现有技术中通过对用户请求调用应用的请求的数量设定阈值来解决防止针对在
短时间内针对一个应用的调用请求过多而导致的资源耗尽的问题。但是现有技术中的该方案由于仅考虑在一段时间内接收到的请求的总数，因此，如果在该一定时间内的一开始就已经接收到超过预设请求次数阈值的请求，那么在该一定时间内的剩余时间就只能够拒绝所有的请求，直到该一定时间过去。
37.例如，如图1a中所示，图1a是示出根据本技术实施例的请求处理方案的应用场景示例的示意图。在图1a中所示的场景中，在云平台上当前有两个用户，即用户1和用户2，在向云服务平台发送自己的云应用调用请求。具体地，用户1可以根据自己当前使用云平台上的应用的需求，在本地生成应用请求，并且该请求中可以包含用户在云平台上的用户标识以及用户需要调用的云平台上的应用的标识或目标应用的标识等信息。因此，云平台在接收到该调用请求之后，可以根据用户想要调用的目标应用的标识来将通过系统中该应用的接口来调用该应用。例如在图1a中所示的场景中，用户1和用户2都会发送多个请求给云平台，这些请求都用于请求平台系统通过接口1来调用应用1。因此，平台可以在接收到用户1和用户2的各个请求时，先在限流模块中对请求进行计数操作。例如当预先为应用1设置的调用请求阈值为4个/秒时，可以在限流模块中在接收到用户1的第一个调用时开始计时和计数，即，在接收到用户1的第一个调用请求时将请求总数计数为1个，并且持续计时。这时，限流模块可以确定当前接收到的用户的调用请求总数为1，还没有达到4个的阈值，因此，限流模块将该用户1的第一个调用请求转发到系统的接口1，以为用户1调用应用1来执行用户的调用请求中的任务。具体地，在系统根据该用户1的第一个调用请求调用应用1时，其实际上是通过将用户请求中包含的任务分配到系统中分配给该应用1所属的应用的计算资源池中的计算资源来执行。即，当限流模块确定当前接收到的用户1的调用请求是没有达到限流阈值的请求时，系统就可以以正常的方式来为用户1所请求的应用的该应用1分配一定的计算资源来执行用户的该调用任务。
38.在接下来的1秒内的前半秒内，平台可以先后接收到用户2的第一个调用请求和用户1的第二个以及第三个调用请求，并且限流模块分别针对这些调用请求实时更新其计数值，并随时判断是否达到了1秒的时间限制。并且由于这些请求都是在半秒内接收到的，并且限流模块计数的请求总数都没有超过4个的预设阈值，因此限流模块就分别将这些请求发送到接口1来调用应用1执行这些请求中要求的任务，并且系统也会为这些任务而给应用1分配计算资源来执行这些请求所针对的任务。但是当接下来继续接收到用户2的第二个调用请求时，由于限流模块在半秒内接收到用户1的第三个调用请求时，就已经将请求总数计数到4个，因此，在接收到用户2的第二个调用请求时，限流模块可以确定在预定的时间段(1秒)内，接收到的请求总数已经超过了预设阈值4个。即，当前在半秒到1秒的时间段内接收到的该用户2的第二个调用请求为在1秒内接收到的第5个调用请求。因此，根据现有技术的方案，限流模块将拒绝该用户2的第二调用请求，并且类似地，在接下来到1秒的时间段内，限流模块将拒绝任何针对应用1的调用请求，因为在前面的半秒时间内已经接收了4个针对应用1的调用请求，并且已经达到了预设的限制阈值了。
39.因此，现有技术的方案中，通过该方式来拒绝掉预设时间段内超出预设请求阈值的所有请求来防止应用1被调用过多，使得其计算资源被耗尽，无法正常提供服务。
40.但是如上所述，在现有技术的方案中，如果用户1为恶意攻击用户，即，在一开始的半秒内接收到的大部分请求都是来自于该用户1，并且这些请求由于限流模块的计数尚未
超过预设请求阈值，这些请求都会被限流模块转发给接口1来正常调用应用1执行任务。注意的是，实际上在该半秒的时间内，用户1发送了三个调用应用1的请求，而用户2实际上仅发送了1个调用应用1的请求。但是在接收到了用户1的第三个调用请求之后，由于限流模块中的请求计数已经达到了预设阈值，即4个，因此，在用户1的该请求之后接收到用户2的第二个调用请求时，就会由于用户1发送了过多的调用请求使得限流模块中的请求计数超出了预设请求阈值。因此，尽管用户2是正常使用云应用的应用1的用户，但是用户2的这些正常的调用请求仍然会被拒绝。
41.因此，现有技术这样的方案由于仅考虑预定时间内的请求总数，因此实际上在进行限流时没有考虑用户的差异，即，该现有技术的方案实际上进行的是用户无差别的限流。这样就会导致例如用户1作为恶意攻击的用户，其在一开始就抢先集中发送了大量的针对应用1的调用请求，来触发平台对于应用1的保护。但是这样的无用户差别限制方案显然会导致实际上不应该被限流的正常用户由于请求发送的时间较晚而被拒绝，并且在该段时间内(例如，图1a中所示的场景中的1秒内)，应用1都无法响应用户2的任何调用请求。这显然无法实现较好的用户体验，或者说并没有实现限流的真正目的。
42.在现有技术中，为了解决该问题，也引入了人工处理，即由专人对超过阈值的请求的拒绝情况进行检查，并且当发现限制处理导致了用户的正常使用遇到了问题时才去对限制进行解除或暂停限流，但是由于需要人工进行检查，并发现遇到问题时才处理，这使得处理的效率非常低，对于用户的实际体验的提升也非常有限。
43.为此，本技术实施例提出了一种请求处理方法，其可以在接收到用户的调用请求之后再根据用户的请求标识来生成请求处理规则，之后再根据这样生成的处理规则来处理用户的请求，从而避免了现有技术中预先设置限制阈值而无差别地限制所有用户的请求的缺陷。
44.例如，在如图1a中所示的场景中，平台在接收到用户1的第一个调用请求时，先根据用户的该调用请求中包含的用户标识和用户所请求的应用标识来获取调用条件。例如，可以首先根据用户的标识，即用户1来获取该用户1的调用请求历史数据。例如，用户1在当天或过去的几天内向云平台发送的调用请求历史数据。该调用请求历史数据可以反映用户发送给云平台的请求的情况。例如，如果用户1在过去一段时间向云平台发送的调用请求不多，那么该用户1很可能是使用云平台的频率较低的用户。因此可以针对其请求的应用1而为该用户1生成较小量的阈值，例如，1个/秒的阈值来作为调用条件。从而图1a中所示的请求处理模块可以根据该生成的调用条件来对该用户1的请求执行处理。在该情况下，即使用户1作为恶意攻击用户在半秒时间内发送了三个或更多个针对应用1的调用请求，那么根据该条件，也只能在一秒内接收用户1的第一个调用请求，而拒绝其他请求。因此，与现有技术中不区分用户而执行了用户1在半秒内发送的全部三个调用请求的方案相比，能够准确地对用户1的短时间内的大量请求进行限制，防止了恶意攻击用户导致的应用1不能够对外服务的问题。
45.此外，在本技术实施例中，在接收到用户1针对目标应用的第一个调用请求或接下来的第二或第三个调用请求时，还可以根据该用户的用户标识来获取该目标应用的历史调用数据，该历史调用数据可以包括该目标应用在该时间段(即，该1秒内)或当天的其他时间段内被该用户1调用的历史记录。特别地，该历史数据可以反映用户1发出的被云平台接收
并执行的调用请求记录。因此，在本技术实施例中，可以基于这样的调用历史数据来进一步辅助判断用户1的情况。例如，在历史调用数据为当前时间段(即，当前1秒内)的调用请求数据并且具体包括：第一个调用请求被接收，并且意味着第二个和第三个调用请求被拒绝。因此，可以基于这样的调用历史数据来生成用户1的请求处理规则，例如，可以进一步将用户1的请求阈值确定为0.5个每秒，即每两秒才允许执行用户1针对应用1的一个请求。因此，在本技术实施例中，可以基于用户的这样的历史调用数据来更准确地确定对用户请求的处理方式。进一步地，还可以在获取了用户的历史调用数据之后，根据历史调用数据和系统中各个应用的被调用数据来进行时序分析，从而确定该用户调用应用的时序数据。该时序数据可以包括用户在各个时间调用各个应用的记录。例如，这样确定的用户1的时序数据可以包括用户1在当前1秒内的第0秒、第0.1秒以及第0.4秒分别发出了针对应用1的第一、第二和第三个调用请求，而在该段时间内没有发出过针对其他应用的调用请求，那么可以进一步确认该用户1很可能是针对应用1的恶意攻击用户，因此可以进一步降低其请求阈值，例如降低为每10秒1个请求，甚至直接封禁该用户。另外，如果该时序数据包括用户1不仅在当前1秒内的第0秒、第0.1秒以及第0.4秒分别发出了针对应用1的第一、第二和第三个调用请求，而且还在第0.15秒以及第0.25秒分别发出了针对应用2的第四和第五个调用请求，那么该用户则也可能是计算量需求较大的用户，因此，也可以适当地提高其请求阈值。此外，该时序数据还可以包括用户在每天各个时刻调用应用的记录，因此，如果根据该时序数据确定用户1在每天的固定时刻都集中发出多个针对应用1的调用请求，例如每隔10秒都在第一秒发出三个调用请求，那么可以根据这样的时序数据就能够进一步确定用户1为针对应用1的恶意攻击用户，从而可以将用户1的处理规则确定为较低数值，以减少或甚至避免用户1的恶意攻击对于应用1的影响。
46.此外，在本技术实施例中，在接收到用户1的调用请求时，还可以进一步根据用户1的请求中包含的用户标识来获取用户的身份信息。例如，当根据用户1的请求中包含的用户标识确定用户1的身份信息为特定类型的客户时，或者根据该身份信息可以确定用户的等级为较高等级时，则可以将用户1的处理规则设置为较高或甚至无限制，以匹配用户的身份。
47.此外，在本技术实施例中，如图1a中所示，请求处理模块在接收到用户的调用请求之后，可以从调用条件生成模块来获取针对该用户调用该目标应用的调用条件。因此，对于该调用条件生成模块来说，云平台也可以在接收到用户的应用调用请求时，除了发送给请求处理模块对该请求进行处理，还可以同步地将该请求发送给调用条件生成模块，从而该调用条件生成模块可以根据该请求中包含的用户标识来获取用户的用户信息，例如上述用户针对该目标应用的调用请求历史数据、用户的身份信息以及该目标应用的调用历史数据等等，并根据这样获取的用户信息和应用信息来生成允许用户调用该目标应用的调用条件。因此，与现有技术相比，在请求处理模块接收到用户的调用请求时，该调用条件生成模块也可以同步接收到该调用请求，并根据该调用请求来实时地生成针对该用户调用该目标应用的调用条件，从而请求处理模块可以从该调用条件生成模块获取到针对当前用户的调用请求而实时生成或更新的调用条件，并根据这样的调用条件来对调用请求进行处理。
48.此外，如图1b中所示，本技术实施例还可以提供一种处理界面，其可以显示在用于管理用户的调用请求的云服务器的管理人员所使用的终端上。例如，如图1b中所示，该处理
界面可以包括请求显示区、调用条件显示区和处理结果反馈区。
49.在请求显示区中可以显示云服务器接收到的用户针对目标应用的调用请求，并且可以显示调用请求中包含的用户的用户标识以及目标应用的应用标识。因此，管理人员可以通过该区域来查看当前请求调用应用的用户的用户标识以及其所请求的应用。
50.调用条件显示区中可以显示允许用户调用所述目标应用的调用条件。如上所述，该调用条件可以是调用条件生成模块在接收到用户的调用请求而根据用户的用户信息以及目标应用的应用信息而生成的。因此，管理人员可以通过该区域来查看当前要对于该用户的该调用请求使用的调用条件，换言之，由于调用条件生成模块是在接收到用户的当前的调用请求时根据该请求实时生成的，因此该调用条件也是随着用户的请求而实时更新的。因此，管理人员可以通过该显示区而实时查看当前所使用的调用条件。
51.处理结果反馈区中可以显示根据调用条件对调用请求的处理结果，并接收针对处理结果的指令。例如，请求处理模块在根据调用条件对接收到的用户的调用请求进行处理之后，可以将处理结果，例如允许执行该调用请求或拒绝该调用请求。并且管理人员可以通过查看请求显示区中显示的用户请求的信息，来对处理结果反馈区中显示的处理结果进行检查，并且可以对其进行手动调整。
52.因此，本技术实施例提供的请求处理方案，通过接收用户针对目标应用的调用请求，该请求中包含用户标识和目标应用的应用标识，并根据该请求中的用户标识和应用标识来获取允许用户调用目标应用的调用条件，并且根据目标应用的运行状态和该调用条件来对调用请求进行处理，因此，能够在接收到用户的请求获取响应于该请求生成的调用条件，从而这样在接收到用户请求之后才生成的调用条件能够及时地反映当前用户请求调用应用的实际情况，实现了调用条件的实时动态生成，从而能够更加合理地对用户的请求进行处理，提高了处理的合理性，并确保了用户对于应用的合理调用，并因此提高了系统资源的利用率。
53.上述实施例是对本技术实施例的技术原理和示例性的应用框架的说明，下面通过多个实施例来进一步对本技术实施例具体技术方案进行详细描述。
54.实施例二
55.图2为本技术提供的针对目标应用的调用请求的处理方法的一个实施例的流程图，该方法的执行主体可以为具有云应用服务能力的各种终端或服务器设备，也可以为集成在这些设备上的装置或芯片。如图2所示，该处理方法可以应用于例如图1a中所示的用于对用户的调用请求进行处理的请求处理模块，并且可以包括如下步骤：
56.s201，接收用户针对目标应用的调用请求。
57.在步骤s201中，可以接收用户调用目标应用的请求。在本技术实施例中，用户可以将其调用云应用的请求发送到云服务器，并且在步骤s201中可以由例如图1a中所示的请求处理模块来接收，该请求中可以包含有用户的用户标识以及用户所请求调用的目标应用的应用标识。例如用户可以通过使用自己的终端登录到提供云应用服务的云平台来发出步骤s201中的该请求，并且因此，可以通过用户在云平台上的登录来将用户在云平台上的用户名称或其他标识信息作为用户的标识包含在用户发送的请求中。
58.s202，根据用户标识以及应用标识获取允许用户调用目标应用的调用条件。
59.在步骤s202中可以根据步骤s201中接收到的用户的请求中包括的用户标识以及
所请求的应用的应用标识来获取允许用户调用目标应用的调用条件。在本技术实施例中，步骤s202中获取的调用条件可以是响应于步骤s201中接收到调用请求根据所述用户的用户信息以及目标应用的应用信息而实时生成的。例如，用户信息可以包括用户的身份信息、用户对于目标应用的调用请求历史数据中的至少一项，并且应用信息可以包括目标应用的调用历史数据例如。
60.此外，可以在云服务器接收到用户的调用请求时，将该请求同时发送给例如图1a中所示的请求处理模块和调用条件生成模块，从而调用条件生成模块可以实时地生成针对该用户调用该目标请求的调用请求，并且请求处理模块可以从调用条件生成模块来获取该实时生成的。该调用条件可以包括用户对于目标应用在预定时间段内的请求数量阈值，例如，每秒10个请求或者每2秒1个请求，还可以包括该请求处理规则的生效时间段，例如，每天的早8点到中午12点等等。
61.s203，确定用户当前对于目标应用的调用请求是否符合调用条件。
62.s204，当确定调用请求符合调用条件时执行调用请求。
63.在步骤s203中可以由例如图1a中所示的请求处理模块根据步骤s202中获取到的调用条件来对步骤s201中接收到的请求进行判断，以确定其是否符合步骤s202中获取到的调用条件。例如，请求处理模块可以根据目标应用当前处理的请求的数目、负载情况等来判断该请求是否符合步骤s202中获取到的实时生成的调用条件。
64.此外，在步骤s203之前，还可以进一步计算在步骤s201中接收到用户的调用请求之前预定时间段内已经接收到了多少调用请求，并且从而在步骤s203中可以进一步基于该预定时间段内的总调用请求数量来结合调用条件对调用请求进行处理。
65.在步骤s204中，当确定用户当前的调用请求符合调用条件时，可以执行该调用请求，否则可以拒绝该调用请求。
66.本技术实施例提供的请求处理方法，通过接收用户针对目标应用的调用请求，该请求中包含用户标识和目标应用的应用标识，并根据该请求中的用户标识和应用标识来获取允许用户调用目标应用的调用条件，并且判断调用请求是否符合该调用条件，以确定说执行该调用请求，因此，能够在接收到用户的请求获取响应于该请求生成的调用条件，从而这样在接收到用户请求之后才生成的调用条件能够及时地反映当前用户请求调用应用的实际情况，实现了调用条件的实时动态生成，从而能够更加合理地对用户的请求进行处理，提高了处理的合理性，并确保了用户对于应用的合理调用，并因此提高了系统资源的利用率。
67.实施例三
68.图3为本技术提供的调用条件生成方法的一个实施例的流程图，该方法的执行主体可以为具有数据处理能力的各种终端或服务器设备，也可以为集成在这些设备上的装置或芯片。如图3所示，本技术实施例提供的调用条件生成方法可以由例如图1a中所示的调用条件生成模块执行，并可以包括如下步骤：
69.s301，接收用户针对目标应用的调用请求。
70.在步骤s301中，可以接收用户调用目标应用的请求。在本技术实施例中，用户可以将其调用云应用的请求发送到云服务器，并且在步骤s301中可以由云服务器转发给例如图1a中所示的调用条件生成模块，该请求中可以包含有用户的用户标识以及用户所请求调用
的目标应用的应用标识。例如用户可以通过使用自己的终端登录到提供云应用服务的云平台来发出步骤s301中的该请求，并且因此，可以通过用户在云平台上的登录来将用户在云平台上的用户名称或其他标识信息作为用户的标识包含在用户发送的请求中。
71.s302，根据用户标识获取用户的用户信息并根据应用标识获取目标应用的应用信息。
72.s303，根据用户信息和应用信息生成允许用户调用目标应用的调用条件。
73.在步骤s301中接收到用户的请求之后，可以根据该请求中包括的用户标识以及所请求的应用的应用标识来获取用户信息和应用信息。并且在步骤s303中可以根据步骤s302中获取到的用户信息和应用信息来生成允许用户调用目标应用的调用条件。
74.例如，在该调用条件中可以包括预定时间段内的请求数量阈值，例如，每秒10个请求或者每2秒1个请求，还可以包括该请求处理规则的生效时间段，例如，每天的早8点到中午12点等等。
75.在步骤s302中可以根据用户的用户标识来获取该用户的调用请求历史数据。例如，用户在当天或过去的几天内向云平台发送的调用请求历史数据。该调用请求历史数据可以反映用户发送给云平台的请求的情况。例如，如果用户在过去一段时间向云平台发送的调用请求不多，那么该用户很可能是使用云平台的频率较低的用户。因此可以针对其请求的应用而为该用户生成较小量的阈值，例如，1个/秒的阈值来作为调用条件，因此，可以根据该生成的调用条件来对该用户1的请求执行处理。在该情况下，即使用户作为恶意攻击用户在半秒时间内发送了三个或更多个针对应用的调用请求，那么根据该条件，也只能在一秒内接收用户的第一个调用请求，而拒绝其他请求。
76.此外，在本技术实施例中，在步骤s302中，可以根据该用户的用户标识来获取该目标应用的历史调用数据，该历史调用数据可以包括该目标应用在该时间段(即，该1秒内)或当天的其他时间段内被该用户调用的历史记录。特别地，该历史数据可以反映用户发出的被云平台接收并执行的调用请求记录。因此，在本技术实施例中，可以基于这样的调用历史数据来进一步辅助判断用户的情况。例如，在历史调用数据为当前时间段(即，当前1秒内)的调用请求数据并且具体包括：第一个调用请求被接收，并且意味着第二个和第三个调用请求被拒绝。因此，在步骤s303中可以基于这样的调用历史数据来生成用户调用该目标应用的调用条件，
77.在本技术实施例中，可以在步骤s303中基于用户的这样的历史调用数据来更准确地确定对用户请求的处理方式。还可以在步骤s302获取了用户的历史调用数据之后，根据历史调用数据和系统中各个应用的被调用数据来进行时序分析，从而确定该用户调用应用的时序数据。该时序数据可以包括用户在各个时间调用各个应用的记录，从而可以根据该记录来调整该用户针对该目标应用的请求阈值，甚至直接封禁该用户。另外，如果该时序数据包括用户不仅在当前1秒内的第0秒、第0.1秒以及第0.4秒分别发出了针对应用1的第一、第二和第三个调用请求，而且还在第0.15秒以及第0.25秒分别发出了针对应用2的第四和第五个调用请求，那么该用户则也可能是计算量需求较大的用户，因此，也可以适当地提高其请求阈值。此外，该时序数据还可以包括用户在每天各个时刻调用应用的记录，因此，如果根据该时序数据确定用户在每天的固定时刻都集中发出多个针对应用的调用请求，例如每隔10秒都在第一秒发出三个调用请求，那么可以根据这样的时序数据就能够进一步确定
用户为针对应用的恶意攻击用户，从而可以将用户的调用条件确定为较低数值，以减少或甚至避免用户1的恶意攻击对于应用的影响。
78.在步骤s302中，还可以进一步根据用户1的请求中包含的用户标识来获取用户的身份信息。例如，当根据步骤s301中接收到的用户的请求中包含的用户标识确定用户1的身份信息为特定类型的客户，或者根据该身份信息可以确定用户的等级为较高等级，则可以将用户的调用条件设置为具有较高的阈值或甚至无限制，以匹配用户的身份。
79.本技术实施例提供的调用条件生成方法，通过接收用户的请求，该请求中包含用户标识和请求的应用的应用标识，并根据该请求中的用户标识和应用标识来获取该用户的用户信息和目标应用的应用信息，最终使用该用户信息和应用信息来实时地生成该用户调用该应用的调用条件，因此，能够在接收到用户的请求之后，才根据该请求来生成该用户调用目标应用的调用条件，这样能够及时地反映当前用户请求调用应用的实际情况，实现了调用条件的实时生成，从而使得能够更加合理地对用户的请求进行处理，提高了处理的合理性，并确保了用户对于应用的合理调用，并因此提高了系统资源的利用率。
80.实施例四
81.图4为本技术提供的请求处理系统的实施例的结构示意图，可以用于执行图2中所示的处理方法或者图3中所示的调用请求生成方法。如图4所示，该调用请求的处理系统可以包括：请求处理模块41和调用条件生成模块42。
82.请求处理模块41可以用于接收用户针对目标应用的调用请求，该调用请求中包含有用户的用户标识以及目标应用的应用标识；根据用户标识以及应用标识获取允许用户调用目标应用的调用条件；根据目标应用的运行状态和调用条件对调用请求进行处理。
83.调用条件生成模块42可以用于接收调用请求；根据用户标识获取用户的用户信息并根据应用标识获取目标应用的应用信息；根据用户信息和应用信息实时生成允许用户调用目标应用的调用条件。
84.例如，当请求处理系统在接收到用户的调用请求时，可以将该请求发送给请求处理模块41和调用条件生成模块42，从而请求处理模块42可以根据用户的该调用请求中包含的用户标识和用户所请求的应用标识来获取调用条件生成模块42实时生成的调用条件。例如，调用条件生成模块42可以根据接收到的用户的调用请求中的用户的标识来获取该用户1的调用请求历史数据。例如，用户在当天或过去的几天内向该请求处理系统发送的调用请求历史数据。该调用请求历史数据可以反映用户发送给请求处理系统的请求的情况。例如，如果用户1在过去一段时间发送的调用请求不多，那么该用户很可能是调用应用的频率较低的用户。因此调用条件生成模块42可以针对其请求的应用而为该用户生成较小量的阈值来作为调用条件。从而请求处理模块可41以根据从调用条件生成模块42获取的这样实时生成的调用条件来对该用户的请求执行处理。在该情况下，即使存在恶意攻击用户在短时间内发送了超过阈值数量的调用请求，那么根据该条件，请求处理模块41也只能该时间段内接收用户的第一个调用请求，而拒绝其他请求。因此，与现有技术中不区分用户而执行了用户在该段时间内发送的全部调用请求而拒绝其他用户的请求的方案相比，能够准确地对用户在短时间内的大量请求进行限制，防止了恶意攻击用户导致的应用不能够对外服务的问题。
85.此外，在本技术实施例中，调用条件生成模块42在接收到用户针对目标应用的调
用请求时，还可以根据该用户的用户标识来获取该目标应用的历史调用数据，该历史调用数据可以包括该目标应用在该时间段(即，该1秒内)或当天的其他时间段内被该用户调用的历史记录。特别地，该历史数据可以反映用户发出的并由请求处理模块41允许执行的调用请求记录。
86.因此，在本技术实施例中，调用条件生成模块42可以基于这样的调用历史数据来进一步辅助判断用户的情况。例如，在历史调用数据为当前时间段(即，当前1秒内)的调用请求数据并且具体包括：第一个调用请求被接收，并且意味着第二个和第三个调用请求被拒绝。因此，调用条件生成模块42可以基于这样的调用历史数据来生成用户的请求处理规则，例如，调用条件生成模块42可以进一步将用户的请求阈值确定为0.5个每秒，即每两秒才允许执行用户针对应用的一个请求。从而可以基于用户的这样的历史调用数据来更准确地确定对用户请求的处理方式。进一步地，还可以在获取了用户的历史调用数据之后，根据历史调用数据和系统中各个应用的被调用数据来进行时序分析，从而确定该用户调用应用的时序数据。该时序数据可以包括用户在各个时间调用各个应用的记录。例如，这样确定的用户的时序数据可以包括用户在当前1秒内的第0秒、第0.1秒以及第0.4秒分别发出了针对应用的第一、第二和第三个调用请求，而在该段时间内没有发出过针对其他应用的调用请求，那么可以进一步确认该用户很可能是针对应用的恶意攻击用户，因此可以进一步降低其请求阈值，甚至直接封禁该用户。
87.此外，该时序数据还可以包括用户在每天各个时刻调用应用的记录，因此，如果根据该时序数据确定用户在每天的固定时刻都集中发出多个针对应用1的调用请求，例如每隔10秒都在第一秒发出三个调用请求，那么可以根据这样的时序数据就能够进一步确定用户为针对应用的恶意攻击用户，从而可以将用户的处理规则确定为较低数值，以减少或甚至避免用户的恶意攻击对于应用的影响。
88.此外，在本技术实施例中，调用条件生成模块42在接收到用户的调用请求时，还可以进一步根据用户的请求中包含的用户标识来获取用户的身份信息。例如，当根据用户的请求中包含的用户标识确定用户的身份信息为特定类型的客户时，或者根据该身份信息可以确定用户的等级为较高等级时，则可以将用户的处理规则设置为较高或甚至无限制，以匹配用户的身份。
89.此外，在本技术实施例中，请求处理模块41在接收到用户的调用请求之后，可以获取调用条件生成模块42针对该用户调用该目标应用而实时生成的调用条件。因此，对于该调用条件生成模块来说，云平台也可以在接收到用户的应用调用请求时，除了发送给请求处理模块对该请求进行处理，还可以同步地将该请求发送给调用条件生成模块，从而该调用条件生成模块可以根据该请求中包含的用户标识来获取用户的用户信息，例如上述用户针对该目标应用的调用请求历史数据、用户的身份信息以及该目标应用的调用历史数据等等，并根据这样获取的用户信息和应用信息来生成允许用户调用该目标应用的调用条件。因此，与现有技术相比，在请求处理模块接收到用户的调用请求时，该调用条件生成模块也可以同步接收到该调用请求，并根据该调用请求来实时地生成针对该用户调用该目标应用的调用条件，从而请求处理模块可以从该调用条件生成模块获取到针对当前用户的调用请求而实时生成或更新的调用条件，并根据这样的调用条件来对调用请求进行处理。
90.此外，在本技术实施例中，请求处理系统还可以进一步包括调用条件存储模块43。
调用条件生成模块42在生成了调用条件之后，还可以进一步将该调用条件与用户标识和应用标识关联地发送给该调用条件存储模块43，并且处理模块41可以从该存储模块43来获取与接收到的用户请求中的用户标识和应用标识对应的调用条件。
91.因此，本技术实施例提供的请求处理系统，通过在接收到用户针对目标应用的调用请求时将该该请求发送给调用请求处理模块41和调用条件生成模块42，从而调用条件生成模块42根据对应的用户信息和应用信息来生成允许用户调用目标应用的调用条件，并且请求处理模块41可以从调用条件生成模块42获取该调用条件，并根据该调用条件来对调用请求进行处理，因此，能够在接收到用户的请求获取响应于该请求生成的调用条件，从而这样在接收到用户请求之后才生成的调用条件能够及时地反映当前用户请求调用应用的实际情况，实现了调用条件的实时动态生成，从而能够更加合理地对用户的请求进行处理，提高了处理的合理性，并确保了用户对于应用的合理调用，并因此提高了系统资源的利用率。
92.实施例五
93.以上描述了请求处理装置的内部功能和结构，所述装置可实现为一种电子设备。图5为本技术提供的电子设备实施例的结构示意图。如图5所示，该电子设备包括存储器51和处理器52。
94.存储器51，用于存储程序。除上述程序之外，存储器51还可被配置为存储其它各种数据以支持在电子设备上的操作。这些数据的示例包括用于在电子设备上操作的任何应用程序或方法的指令，联系人数据，电话簿数据，消息，图片，视频等。
95.存储器51可以由任何类型的易失性或非易失性存储设备或者它们的组合实现，如静态随机存取存储器(sram)，电可擦除可编程只读存储器(eeprom)，可擦除可编程只读存储器(eprom)，可编程只读存储器(prom)，只读存储器(rom)，磁存储器，快闪存储器，磁盘或光盘。
96.处理器52，不仅仅局限于处理器(cpu)，还可能为图形处理器(gpu)、现场可编辑门阵列(fpga)、嵌入式神经网络处理器(npu)或人工智能(ai)芯片等处理芯片。处理器52，与存储器51耦合，执行存储器51所存储的程序，以执行上述实施例二或三的请求处理方法。
97.进一步，如图5所示，电子设备还可以包括：通信应用53、电源应用54、音频应用55、显示器56等其它应用。图5中仅示意性给出部分应用，并不意味着电子设备只包括图5所示应用。
98.通信应用53被配置为便于电子设备和其他设备之间有线或无线方式的通信。电子设备可以接入基于通信标准的无线网络，如wifi、3g、4g或5g，或它们的组合。在一个示例性实施例中，通信应用53经由广播信道接收来自外部广播管理系统的广播信号或广播相关信息。在一个示例性实施例中，所述通信应用53还包括近场通信(nfc)模块，以促进短程通信。例如，在nfc模块可基于射频识别(rfid)技术，红外数据协会(irda)技术，超宽带(uwb)技术，蓝牙(bt)技术和其他技术来实现。
99.电源应用54，为电子设备的各种应用提供电力。电源应用54可以包括电源管理系统，一个或多个电源，及其他与为电子设备生成、管理和分配电力相关联的应用。
100.音频应用55被配置为输出和/或输入音频信号。例如，音频应用55包括一个麦克风(mic)，当电子设备处于操作模式，如呼叫模式、记录模式和语音识别模式时，麦克风被配置为接收外部音频信号。所接收的音频信号可以被进一步存储在存储器51或经由通信应用53
发送。在一些实施例中，音频应用55还包括一个扬声器，用于输出音频信号。
101.显示器56包括屏幕，其屏幕可以包括液晶显示器(lcd)和触摸面板(tp)。如果屏幕包括触摸面板，屏幕可以被实现为触摸屏，以接收来自用户的输入信号。触摸面板包括一个或多个触摸传感器以感测触摸、滑动和触摸面板上的手势。所述触摸传感器可以不仅感测触摸或滑动动作的边界，而且还检测与所述触摸或滑动操作相关的持续时间和压力。
102.本领域普通技术人员可以理解：实现上述各方法实施例的全部或部分步骤可以通过程序指令相关的硬件来完成。前述的程序可以存储于一计算机可读取存储介质中。该程序在执行时，执行包括上述各方法实施例的步骤；而前述的存储介质包括：rom、ram、磁碟或者光盘等各种可以存储程序代码的介质。
103.最后应说明的是：以上各实施例仅用以说明本发明的技术方案，而非对其限制；尽管参照前述各实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分或者全部技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本发明各实施例技术方案的范围。