CN111966445A - 调用应用程序接口的处理方法和装置 - Google Patents

Abstract

本申请公开了调用应用程序接口的处理方法和装置，涉及大数据、信息流技术领域。该方法应用于云平台，具体实现方案为：响应于获取的应用程序接口调用请求，确定调用请求中包括的目标应用程序接口标识；查询应用程序接口标识与容器的映射关系表，确定与目标应用程序接口标识匹配的目标容器；将调用请求转发给目标容器，以使目标容器对调用请求进行响应。由此，通过将调用请求转发给对应的容器，以使每个容器处理自己关联的应用程序接口的调用请求，即使某个容器崩溃也不会影响处理引擎和其他容器，从而提高了处理引擎的性能。

Description

调用应用程序接口的处理方法和装置

技术领域

本申请涉及数据处理技术领域，具体涉及大数据、信息流技术领域，尤其涉及一种调用应用程序接口的处理方法和装置。

背景技术

当某个公司或机构的内部系统需要调用其它外部第三方的开放应用程序接口时，请求流量一般首先都会经过一个处理引擎，然后由处理引擎进行处理，再将请求流量转发给其要请求的外部第三方后端系统。

可见，在大流量场景下，如何提高处理引擎的性能是至关重要的。

发明内容

本申请提出一种用于提高处理引擎性能的调用应用程序接口的处理方法和装置。

本申请一方面实施例提出了一种调用应用程序接口的处理方法，包括：

响应于获取的应用程序接口调用请求，确定所述调用请求中包括的目标应用程序接口标识；

查询应用程序接口标识与容器的映射关系表，确定与所述目标应用程序接口标识匹配的目标容器；以及

将所述调用请求转发给所述目标容器，以使所述目标容器对所述调用请求进行响应。

本申请实施例的调用应用程序接口的处理方法，通过响应于获取的应用程序接口调用请求，确定调用请求中包括的目标应用程序接口标识，然后查询应用程序接口标识与容器的映射关系表，确定与目标应用程序接口标识匹配的目标容器，之后将调用请求转发给目标容器，以使目标容器对调用请求进行响应。由此，通过将调用请求转发给对应的容器，以使每个容器处理自己关联的应用程序接口的调用请求，即使某个容器崩溃也不会影响处理引擎和其他容器，从而提高了处理引擎的性能。

本申请另一方面实施例提出了一种调用应用程序接口的处理装置，包括：

第一确定模块，用于响应于获取的应用程序接口调用请求，确定所述调用请求中包括的目标应用程序接口标识；

第二确定模块，用于查询应用程序接口标识与容器的映射关系表，确定与所述目标应用程序接口标识匹配的目标容器；以及

第一发送模块，用于将所述调用请求转发给所述目标容器，以使所述目标容器对所述调用请求进行响应。

本申请实施例的调用应用程序接口的处理装置，通过应于获取的应用程序接口调用请求，确定调用请求中包括的目标应用程序接口标识，然后查询应用程序接口标识与容器的映射关系表，确定与目标应用程序接口标识匹配的目标容器，之后将调用请求转发给目标容器，以使目标容器对调用请求进行响应。由此，通过将调用请求转发给对应的容器，以使每个容器处理自己关联的应用程序接口的调用请求，即使某个容器崩溃也不会影响处理引擎和其他容器，从而提高了处理引擎的性能。

本申请另一方面实施例提出了一种电子设备，包括：

至少一个处理器；以及

与所述至少一个处理器通信连接的存储器；其中，

所述存储器存储有可被所述至少一个处理器执行的指令，所述指令被所述至少一个处理器执行，以使所述至少一个处理器能够执行上述一方面实施例所述的调用应用程序接口的处理方法。

本申请另一方面实施例提出了一种存储有计算机指令的非瞬时计算机可读存储介质，其上存储有计算机程序，所述计算机指令用于使所述计算机执行上述一方面实施例所述的调用应用程序接口的处理方法。

上述本申请的实施例，通过将调用请求转发给对应的容器，以使每个容器处理自己关联的应用程序接口的调用请求，即使某个容器崩溃也不会影响处理引擎和其他容器，从而提高了处理引擎的性能。

上述可选方式所具有的其他效果将在下文中结合具体实施例加以说明。

附图说明

附图用于更好地理解本方案，不构成对本申请的限定。其中：

图1为本申请实施例提供的一种调用应用程序接口的处理方法的流程示意图；

图2为本申请实施例提供的一种处理引擎的示意图；

图3为本申请实施例提供的另一种调用应用程序接口的处理方法的流程示意图；

图4为本申请实施例提供的另一种调用应用程序接口的处理方法的流程示意图；

图5为本申请实施例提供的另一种调用应用程序接口的处理方法的流程示意图；

图6为本申请实施例提供的另一种调用应用程序接口的处理方法的流程示意图；

图7为本申请实施例提供的另一种调用应用程序接口的处理方法的流程示意图；

图8为本申请实施例提供的一种调用应用程序接口的处理装置的结构示意图；

图9为根据本申请实施例的调用应用程序接口的处理方法的电子设备的框图。

具体实施方式

以下结合附图对本申请的示范性实施例做出说明，其中包括本申请实施例的各种细节以助于理解，应当将它们认为仅仅是示范性的。因此，本领域普通技术人员应当认识到，可以对这里描述的实施例做出各种改变和修改，而不会背离本申请的范围和精神。同样，为了清楚和简明，以下的描述中省略了对公知功能和结构的描述。

下面参考附图描述本申请实施例的调用应用程序接口的处理方法和装置。

本申请实施例的调用应用程序接口的处理方法可应用于云平台，通过将调用请求转发给对应的容器，以使每个容器处理自己关联的应用程序接口的调用请求，即使某个容器崩溃也不会影响处理引擎和其他容器，从而提高了处理引擎的性能。

图1为本申请实施例提供的一种调用应用程序接口的处理方法的流程示意图。

本申请实施例的调用应用程序接口的处理方法，通过在处理引擎中设置转发节点和多个容器，以实现由每个容器处理与自己关联的应用程序接口的调用请求。

其中，处理引擎用于对内部系统调用外部应用程序接口的调用请求进行处理。

如图1所示，该调用应用程序接口的处理方法包括：

步骤101，响应于获取的应用程序接口调用请求，确定调用请求中包括的目标应用程序接口标识。

本实施例中，在处理引擎中设置转发节点，并在处理引擎中为外部应用程序接口配置对应的容器，那么每个容器具有关联的应用程序接口标识。其中，转发节点和多个容器可以位于同一设备，转发节点和多个容器也可分布在多个设备中。

这里配置的容器可以是docker容器，关联的应用程序接口标识为外部应用程序接口的标识，比如第三方的开放应用程序接口的标识。

比如，有3个第三方的开放应用程序接口分别为a、b、c，那么在处理引擎中分别配置与a、b、c对应的容器。

需要说明的是，可以在处理引擎中配置与多个第三方的应用程序接口对应的容器。

图2为本申请实施例提供的一种处理引擎的示意图。图2中，处理引擎210中包含转发节点、容器1、容器2、容器3、容器4(如图2中的211、212、213、214、215所示)。

图2中的容器数量仅为示例，处理引擎中包含的容器的数量可以根据实际需要确定。

本实施例中，处理引擎中的转发节点对应用程序接口调用请求进行监听，当转发节点听到调用请求时，该转发节点对调用请求进行解析，获取调用请求中的目标应用程序接口标识。

其中，目标应用程序接口标识为待调用的外部应用程序接口的标识。

步骤102，查询应用程序接口标识与容器的映射关系表，确定与目标应用程序接口标识匹配的目标容器。

本实施例中，预先建立应用程序接口标识与容器之间的映射关系，得到映射关系表。处理引擎中的转发节点在获取目标应用程序接口标识后，通过查询应用程序接口标识与容器的映射关系表，确定映射关系表中与目标应用程序接口标识匹配的应用程序接口标识，然后获取该应用程序接口标识对应的容器，将该应用程序接口标识对应的容器，确定为与目标应用程序接口标识匹配的目标容器。

比如，调用请求中目标应用程序接口标识为S，通过查询查询应用程序接口标识与容器的映射关系表，确定映射关系表中应用程序接口标识S对应的容器为s，那么容器s为与目标应用程序接口标识S匹配的目标容器。

步骤103，将调用请求转发给目标容器，以使目标容器对调用请求进行响应。

转发节点在确定与目标应用程序接口标识匹配的目标容器后，将调用请求准发给该目标容器，由该目标容器对调用请求进行响应，具体可以是由目标容器将调用请求转发给目标容器关联的应用程序接口对应的第三方的后端系统。

在实际应用中，若由处理引擎对每个调用请求进行处理，在请求流量比较大时，处理引擎可能会因为请求流量较大而崩溃，可见在大流量场景下，处理引擎的性能较差。而本实施例中，在处理引擎中设置多个容器，由转发节点将调用请求转发给对应的容器，由容器处理自己关联的应用程序接口的调用请求，显然在大流量场景下，处理引擎具有较好的性能。

本申请实施例的调用应用程序接口的处理方法，通过响应于获取的应用程序接口调用请求，确定调用请求中包括的目标应用程序接口标识，然后查询应用程序接口标识与容器的映射关系表，确定与目标应用程序接口标识匹配的目标容器，之将调用请求转发给目标容器，以使目标容器对调用请求进行响应。由此，通过将调用请求转发给对应的容器，以使每个容器处理自己关联的应用程序接口的调用请求，即使某个容器崩溃也不会影响处理引擎和其他容器，从而提高了处理引擎的性能。

为了提高处理引擎的性能，在本申请的一个实施例中，在处理引擎中可以为应用程序接口配置多个容器，即映射关系表中应用程序接口标识可能对应一个容器，也可能对应多个容器。

转发节点在获取目标应用程序接口标识，查询映射关系表，如果确定映射关系表中与目标应用程序接口标识匹配的容器数量为N，其中，N为大于1的正整数，N个容器对应的应用程序接口标识相同，也就是与目标应用程序接口匹配的容器有多个。

转发节点在确定与目标应用程序接口标识匹配的目标容器时，可以从N个容器中随机选择一个容器，作为目标容器，然后将调用请求转发给目标容器，由目标容器进行响应。

或者，当同一应用程序接口对应多个容器时，为预设多个容器的被调用顺序，转发节点可以根据N个容器被调用顺序，确定当前待调用的容器作为目标容器，然后将调用请求转发给目标容器，由目标容器进行响应。

比如，与某应用程序接口对应的容器有a、b、c共3个容器,被调用的顺序为a、b、c。当转发节点获取到该应用程序接口的第一个调用请求时，将第一个调用请求转发给容器a；当获取到该应用程序接口的第二个调用请求时，将第二个调用请求转发给容器b；当获取到该应用程序接口的第三个调用请求时，将第三个调用请求转发给容器c；当获取到该应用程序接口的第四个调用请求时，将第四个调用请求转发给容器a。

本申请实施例中，如果映射关系表中与目标应用程序接口标识匹配的容器数量为N，其中，N为大于1的正整数，在查询应用程序接口标识与容器标识的映射关系表，确定与目标应用程序接口标识匹配的目标容器时，可以从N个容器中随机抽取一个容器，作为目标容器，或者根据N个容器的被调用顺序，确定当前待调用的容器为目标容器。由此，当与目标应用程序接口标识匹配的容器有多个时，从中确定一个容器作为目标容器，使得转发节点将调用请求转发给相应的容器进行响应，避免将调用请求转发给所有匹配的容器。

在实际应用中，若容器转发的调用请求较多，容器存在崩溃的风险。基于此，在本申请的一个实施例中，处理引擎还包括主控节点，若处理引擎中的容器都分配在同一个设备中，那么每个容器可以自己监测请求流量，当请求流量大于预设阈值时，可以向主控节点发送容器生成请求，以使主控节点创建新容器，以通过新容器协助处理调用请求。下面结合图3进行说明，图3为本申请实施例提供的另一种调用应用程序接口的处理方法的流程示意图。

如图3所示，该调用应用程序接口的处理方法还包括：

步骤301，获取每个容器各自每秒转发的调用请求的数量。

本实施例中，处理引擎中的容器分布在同一个设备中，处理引擎中的每个容器可统计连续时间段内关联的应用程序接口的调用请求的数量，然后计算每秒转发的调用请求数量，从而可以获取每个容器各自每秒转发的调用请求的数量。

步骤302，如果多个容器中的任一容器确定其每秒转发的调用请求的数量大于第一流量阈值，则向主控节点发送容器生成请求。

本实施例中，每个容器将每秒转发的调用请求的数量与第一流量阈值进行比较，如果存在容器其每秒转发的调用请求的数量大于第一流量阈值，说明该容器存在崩溃的风险，则该容器向主控接节点发送容器生成请求，以使主控接节点根据容器生成请求，创建新容器。

其中，主控节点可以和多个容器在同一设备中，也可以在不同设备中；容器生成请求中包括发送容器生成请求的容器的自关联的应用程序接口标识。

因此，本实施例中，当处理引擎中的任一容器每秒转发的调用请求数量大于第一流量阈值时，可以向主控节点发送容器生成请求，请求生成新容器。

本申请实施例中，还可获取每个容器各自每秒转发的调用请求的数量，如果多个容器中的任一容器确定其每秒转发的调用请求的数量大于第一流量阈值，则向主控节点发送容器生成请求，其中，容器生成请求中包括任一容器自关联的应用程序接口标识。由此，当处理引擎中任一容器每秒转发的调用请求的数量大于第一流量阈值时，通过向主控节点发送容器生成请求，以请求主控节点创建新容器，使通过新容器缓解容器的请求流量，减小容器崩溃的风险，进一步提高了处理引擎的性能。

上述实施例描述的处理引擎中的容器分布在同一设备中时，由容器监测自己的请求流量，在本申请的一个实施例中，当处理引擎中的容器分布在多个设备中时，可以利用同设备中的监控节点监测容器的请求流量。

本实施例中，多个容器分布在至少两个设备中，处理引擎中除了包括转发节点和多个容器外，还可包括主控节点和分别分布在至少两个设备中的监控节点。也就是说，如果处理引擎中的多个容器分布在多个设备中，在每个设备中也分布有监控节点。其中，主控节点可以分布在至少两个设备中的一个设备中，也可以分配在其他设备中。

每个监控节点可以统计连续时间内其所在设备中每个容器转发调用请求数量，然后计算同设备中每个容器每秒转发的调用请求数量，之后将同设备中每个容器每秒转发的调用请求数量与第二流量阈值进行比较。

如果监控节点确定同设备中任一容器每秒转发的调用请求数量大于其对应的第一流量阈值，说明容器存在崩溃的风险，则监控节点向主控节点发送容器生成请求，以使主控节点根据容器生成请求生成新容器。

其中，容器生成请求中包括调用请求数量大于第一流量阈值的容器的自关联的应用程序接口标识。

本实施例中，当处理引擎中的容器分别在多个设备中时，处理引擎可以通过每个设备中的监控节点，监控同设备中每个容器的请求流量，当请求流量较小时，请求生成新容器。

本申请实施例中，多个容器分布在至少两个设备中，该方法还包括:获取同设备中每个容器每秒转发的调用请求数量，如果同设备中任一容器每秒转发的调用请求数量大于其对应的第一流量阈值时，则向主控节点发送容器生成请求。由此，当处理引擎中的多个容器分布在多个设备中时，可以通过分布在每个设备中的监控节点，监控同设备中每个容器的请求流量，在请求流量较大时，向主控节点发送请求生成请求，请求生成新容器，通过新容器协助请求流量较大的容器处理调用请求，减小容器崩溃的风险，提高了处理引擎的性能。

在本申请的一个实施例中，在上述向主控节点发送容器生成请求之后，主控节点根据容器生成请求生成新容器，以缓解请求流量较大的容器的请求流量压力。

具体地，镜像数据库中包括镜像文件，其中，镜像文件包含容器运行所需的基础信息。主控节点接收到容器生成请求后，从容器生成请求中获取容器自关联的应用程序接口标识，并根据镜像文件和该容器自关联的应用程序接口标识，生成新容器。

可见，新容器中既包含有容器运行所需的基础信息，还包括容器生成请求中容器自关联的应用程序接口的信息，那么新容器自关联的应用程序接口，与容器生成请求中容器自关联的应用程序接口标识相同。

本实施例中，主控节点在接收到监控节点或者容器发送的容器生成请求后，根据容器生成请求，生成与新容器，以使生成的新容器能够处理容器生成请求中，自关联的应用程序接口标识对应的应用程序接口的调用请求。

比如，容器生成请求中包括容器a自关联的应用程序接口标识，主控节点可以生成新容器，其中，新容器自关联的应用程序接口标识与容器a自关联的应用程序接口标识相同。该新容器可以协助容器a处理调用请求。

本申请实施例中，在向主控节点发送容器生成请求之后，根据镜像数据库中的镜像文件及任一容器自关联的应用程序接口标识，生成新容器，其中，新容器自关联的应用程序接口标识与任一容器自关联的应用程序接口标识相同。由此，处理引擎通过主控节点生成，与容器生成请求中容器自关联的应用程序接口标识的容器，以使生成的新容器处理容器生成请求中容器关联的应用程序接口的调用请求，从而缓解请求流量较大的容器的请求流量压力，减小容器崩溃的风险，不仅提高了处理引擎的性能，而且可以根据请求流量进行扩容，处理引擎的拓展性强。

为了保证生成的新容器能够处理，容器生成请求中容器自关联的应用程序接口的调用请求，在本申请的一个实施例中，可以利用图4所示的方法生成新容器。下面结合图4进行说明，图4为本申请实施例提供的另一种调用应用程序接口的处理方法的流程示意图。

如图4所示，上述根据镜像数据库中的镜像文件及任一容器自关联的应用程序接口标识，生成新容器，包括：

步骤401，获取与任一容器自关联的应用程序接口标识对应的第一配置文件。

本实施例中，可将容器自关联的应用程序接口的参数、自关联的应用程序接口的地址等放置在配置文件中。处理引擎中的主控节点获取到容器生成请求后，根据容器生成请求中容器自关联的应用程序接口标识，获取对应的配置文件，这里称为第一配置文件。

其中，第一配置文件中包括容器生成请求中容器自关联的应用程序接口的参数、自关联的应用程序接口的地址等配置信息。

步骤402，触发运行镜像数据库中的镜像文件、及第一配置文件，以生成新容器。

本实施例中，将容器运行所需的基础信息放置在镜像数据库中的镜像文件中，将应用程序接口的参数等放置在另外的配置文件中。主控节点从镜像数据库中获取镜像文件，并触发运行镜像库中的镜像文件，并将第一配置文件中的配置信息注入到镜像文件中，以生成新容器。

本实施例中，将容器运行所需的基础信息放在镜像文件中与应用程序接口对应的配置文件分开，这样不仅便于镜像文件的更新，而且保证了处理引擎中每个容器的运行环境一致。

由于处理引擎中每个容器的运行环境一致，从而使得处理引擎的部署迁移更加容易。由于容器可以在很多平台上运行，无论是物理机、虚拟机、公有云、私有云、甚至是笔记本等，其运行结果是一致的。因此，在后续部署时可以将处理引擎从一个平台迁移到另一个平台上，而无需担心运行环境的变化导致处理引擎无法正常运行的情况。

本申请实施例中，在根据镜像数据库中的镜像文件及任一容器自关联的应用程序接口标识，生成新容器时，获取与任一容器自关联的应用程序接口标识对应的第一配置文件，然后触发运行镜像数据库中的镜像文件、及第一配置文件，以生成新容器。由此，通过根据镜像文件和任一容器自关联的应用程序接口对应的配置文件，生成新容器，使得新容器与容器生成请求中的应用程序接口标识对应的容器，运行环境相同，而且与容器生成请求中的应用程序接口标识对应的容器，具有相同的自关联的应用程序接口标识，从而可以协助容器生成请求中的应用程序接口标识对应的容器处理调用请求。

在实际应用中，内部系统对某个应用程序接口的调用可能会减少。基于此，在本申请的一个实施例中，如果应用程序接口对应的容器有多个，且主控节点确定存在容器每秒转发的调用请求的数量小于预设值时，可以销毁这些容器，以节约系统资源。下面结合图5进行说明，图5为本申请实施例提供的另一种调用应用程序接口的处理方法的流程示意图。

如图5所示，在上述获取同设备中每个容器每秒转发的调用请求数量之后，该调用应用程序接口的处理方法还包括：

步骤501，将同设备中每个容器每秒转发的调用请求数量、及每个容器关联的应用程序接口标识，上报给主控节点，以使主控节点确定与每个应用程序接口标识关联的各容器每秒转发的调用请求数量。

本实施例中，每个监控节点根据应用程序接口标识与容器的映射关系表，获取同设备中每个容器关联的应用程序接口标识，并将获取的同设备中每个容器每秒转发的调用请求数量、以及每个容器关联的应用程序接口标识，上报给主控节点。由此，主控节点可获取处理引擎中每个容器每秒转发的调用请求数量，以及每个容器关联的应用程序接口标识。

主控节点根据每个容器每秒转发的调用请求数量，以及每个容器关联的应用程序接口标识，确定每个应用程序接口标识对应的各容器每秒转发的调用请求数量。其中，每个应用程序接口标识可能对应一个容器，也可能对应多个容器。

步骤502，如果与任一应用程序接口标识关联的多个容器中至少一个容器每秒转发的调用请求的数量小于第二流量阈值，则将至少一个容器确定为待销毁容器。

对于关联多个容器的应用程序接口标识，主控节点将应用程序接口标识对应的每个容器每秒转发的调用请求的数量，与第二流量阈值进行比较。其中，第二流量阈值小于第一流量阈值。

如果存在至少一个容器每秒转发的调用请求的数量小于第二流量阈值，说明容器的请求流量较小，那么将至少一个容器确定为待销毁容器。

比如，处理引擎中有8个容器，其中，容器A、容器B和容器C自关联的应用程序接口标识相同，剩余5个容器的自关联的应用程序接口标识不同。若容器A和容器B每秒转发的调用请求的数量都小于第二流量阈值，那么可将容器A和容器B确定为待销毁容器。

可见，对于每个关联多个容器的应用程序接口标识，如果关联的多个容器中，存在一个或多个容器每秒转发的调用请求的数量小于第二流量阈值，那么将一个或多个容器确定为待销毁容器。

步骤503，在确定待销毁容器无待处理的调用请求后，销毁待销毁容器。

为了不影响对调用请求的处理，本实施例中，监控节点获取到同设备中待销毁容器对应的调用请求数量，并发送给主控节点。当主控节点确定待销毁容器对应的待处理的调用请求的数量为零时，说明待销毁容器无待处理的调用请求，那么将待销毁容器销毁，具体是将待销毁容器删除，从而对处理引擎中的容器进行缩容，节省了系统资源。

如果处理引擎中的容器分别在同一设备中，主控节点可获取待销毁容器上报的待处理的调用请求的数量，当确定待销毁容器待处理的调用请求的数量为零时，将待销毁容器销毁。

本申请实施例中，在获取同设备中每个容器每秒转发的调用请求数量之后，将同设备中每个容器每秒转发的调用请求数量、及每个容器关联的应用程序接口标识，上报给主控节点，以使主控节点确定与每个应用程序接口标识关联的各容器每秒转发的调用请求数量，如果与任一应用程序接口标识关联的多个容器中至少一个容器每秒转发的调用请求的数量小于第二流量阈值，则将至少一个容器确定为待销毁容器，并在确定待销毁容器无待处理的调用请求后，销毁待销毁容器。由此，若应用程序接口对应多个容器，当存在容器每秒转发的调用请求数量均小于第二流量阈值时，可以在该容器无待处理的调用请求后，将其销毁，从而处理引擎通过主控节点进行缩容，拓展性强，并且节省了系统资源。

为了提高处理引擎的拓展性，在本申请的一个实施例中，当增加新的应用程序接口时，可以通过主控节点为该应用程序接口创建对应的容器。下面结合图6进行说明，图6为本申请实施例提供的另一种调用应用程序接口的处理方法的流程示意图。

如图6所示，该调用应用程序接口的处理方法还包括：

步骤601，响应于获取到的应用程序接口增加请求，获取增加请求中包含的待增加的应用程序接口对应的第二配置文件。

本实施例中，当外部有新的开放应用程序接口时，向处理引擎发送应用程序接口增加请求。处理引擎中的主控节点获取应用程序接口增加请求，其中，应用程序接口增加请求中包括待增加的应用程序接口对应的第二配置文件。

这里第二配置文件中包括待增加的应用程序接口的参数、待增加的应用程序接口的地址等配置信息。

比如，应用程序接口m为新增的应用程序接口，监控节点可获取应用程序接口m的增加请求，该增加请求中包括应用程序接口m对应的配置文件。

步骤602，触发运行镜像数据库中的镜像文件、及第二配置文件，以生成与第二配置文件对应的容器。

主控节点在获取应用程序接口增加请求后，解析该增加请求，获取第二配置文件，并从镜像数据库中获取镜像文件。然后，主控节点触发运行镜像数据库中的镜像文件，将第二配置文件中的配置信息注入到镜像文件中，从而可以生成与第二配置文件对应的容器。

其中，生成的容器自关联的应用程序接口标识，为待增加的应用程序接口的标识，生成的容器用于处理对待增加的应用程序接口的调用请求。

本实施例中，当增加应用程序接口时，处理引擎通过主控节点，可以生成与增加的应用程序接口对应的容器。

本申请实施例中，还可通过响应于获取到的应用程序接口增加请求，获取增加请求中包含的待增加的应用程序接口对应的第二配置文件，然后触发运行镜像数据库中的镜像文件、及第二配置文件，以生成与第二配置文件对应的容器。由此，当增加应用程序接口时，处理引擎通过主控节点可以创建与增加的应用程序接口对应的容器，通过该容器处理增加的应用程序接口的调用请求，从而实现了根据需求对处理引擎进行扩容，拓展性强。

基于上述描述可以看出，本申请实施例中，处理引擎可以根据请求流量创建容器或销毁容器，当增加应用程序接口时，也可以方便的创建对应的容器，具有较强的拓展性。

为了提高应用程序接口调用的安全性，在本申请的一个实施例中，在将调用请求转发给目标容器之后，目标容器可先对调用请求进行鉴权处理，在鉴权通过后对调用请求进行转发处理。

具体地，在创建容器时，设置可以调用容器对应的应用程序接口的调用权限，比如设置可以调用应用程序接口的调用方。在目标容器接收到转发节点转发的调用请求后，判断调用请求的调用方是否具有调用目标容器对应的应用程序接口的权限。如果有权限，也即鉴权通过，那么目标容器将调用请求转发给待调用的应用程序接口所属的第三方。如果鉴权未通过，那么目标容器对调用请求不作处理。

本申请实施例中，在将调用请求转发给目标容器之后，目标容器对调用请求进行鉴权处理，并在鉴权通过后将调用请求进行转发处理。由此，由此，在调用请求鉴权通过后，目标容器才对调用请求进行转发处理，从而提高了应用程序接口调用的安全性。

为了提高安全性，在本申请的一个实施例中，可以通过为每个容器配置访问地址，限制容器间的访问。下面结合图7进行说明，图7为本申请实施例提供的另一种调用应用程序接口的处理方法的流程示意图。

如图7所示，上述目标容器对调用请求进行转发处理，包括：

步骤701，获取自关联应用程序接口对应的访问地址。

本实施例中，每个应用程序接口具有对应的访问地址，由于容器与应用程序接口之间具有对应关系，那么目标容器对调用请求进行处理时，可以根据获取自关联的应用程序接口标识对应的访问地址。

其中，访问地址可以为域名，或者本地主机等。

步骤702，将调用请求，发送至自关联应用程序接口对应的访问地址。

目标容器在获取访问地址后，将调用请求发送给自关联的应用程序接口对应的访问地址，使得该访问地址对应的第三方获取该调用请求。

本实施例中，通过为处理引擎中每个容器配置访问地址，使得每个容器只能访问与其对应的访问地址，从而可以限制容器间的互相访问，提高了安全性。

本申请实施例中，在对调用请求进行转发处理时，获取自关联应用程序接口对应的访问地址，然后将调用请求，发送至自关联应用程序接口对应的访问地址。由此，通过为每个容器配置访问地址，使容器将调用请求，发送给该容器自关联的应用程序接口标识对应的访问地址，从而限制了容器间的互相访问，提高了安全性。

进一步地，为了防止两个容器间互相通信，在本申请的一个实施例中，目标容器在获取到访问请求时，响应于获取的访问请求，解析访问请求，确定访问请求对应的访问方。如果访问方是处理引擎中多个容器中的任一容器，说明是其他容器要访问目标容器，即该访问请求是容器之间的互相访问，那么可将该访问丢弃。其中，访问方是指发送访问请求的一方。

本申请实施例中，还可响应于获取的访问请求，确定访问请求对应的访问方，如果访问方为多个容器中的任一容器，则将访问请求丢弃。由此，在目标容器接收到访问请求时，通过判断发送访问请求的访问方是否为处理引擎中的容器，如果是，则丢弃访问请求，从而可以防止两个容器间的互相通信。

本申请实施例中，处理引擎还可向用户展现请求数量、请求成功数、请求失败数等监控数据，以便于用户获知应用程序接口的调用情况。

为了实现上述实施例，本申请实施例还提出一种调用应用程序接口的处理装置。图8为本申请实施例提供的一种调用应用程序接口的处理装置的结构示意图。

本申请实施例的调用应用程序接口的处理装置，可应用于包含转发节点及多个容器的处理引擎，该处理引擎可以位于云平台。

如图8所示，该调用应用程序接口的处理装置800包括：第一确定模块810、第二确定模块820及第一发送模块830。

第一确定模块810，用于响应于获取的应用程序接口调用请求，确定调用请求中包括的目标应用程序接口标识；

第二确定模块820，用于查询应用程序接口标识与容器的映射关系表，确定与目标应用程序接口标识匹配的目标容器；以及

第一发送模块830，用于将调用请求转发给目标容器，以使目标容器对调用请求进行响应。

在本申请实施例一种可能的实现方式中，如果映射关系表中与目标应用程序接口标识匹配的容器数量为N，其中，N为大于1的正整数，则第二确定模块820，用于：

从N个容器中随机抽取一个容器，作为目标容器；

或者，

根据N个容器的被调用顺序，确定当前待调用的容器为目标容器。

在本申请实施例一种可能的实现方式中，该装置还可包括：

第一获取模块，用于获取每个容器各自每秒转发的调用请求的数量；以及

第二发送模块，用于当多个容器中的任一容器确定其每秒转发的调用请求的数量大于第一流量阈值是，向主控节点发送容器生成请求，其中，容器生成请求中包括任一容器自关联的应用程序接口标识。

在本申请实施例一种可能的实现方式中，多个容器分布在至少两个设备中，装置还包括：

第二获取模块，用于获取同设备中每个容器每秒转发的调用请求数量；

第三发送模块，用于如果同设备中任一容器每秒转发的调用请求数量大于其对应的第一流量阈值时，则向主控节点发送容器生成请求，其中，生成请求中包括任一容器自关联的应用程序接口标识。

在本申请实施例一种可能的实现方式中，该装置还可包括：

第一生成模块，用于根据镜像数据库中的镜像文件及任一容器自关联的应用程序接口标识，生成新容器，其中，新容器自关联的应用程序接口标识与任一容器自关联的应用程序接口标识相同。

在本申请实施例一种可能的实现方式中，上述第一生成模块，包括：

获取单元，用于获取与任一容器自关联的应用程序接口标识对应的第一配置文件；

生成单元，用于触发运行镜像数据库中的镜像文件、及第一配置文件，以生成新容器。

在本申请实施例一种可能的实现方式中，该装置还可包括：

上报模块，用于将同设备中每个容器每秒转发的调用请求数量、及每个容器关联的应用程序接口标识，上报给主控节点，以使主控节点确定与每个应用程序接口标识关联的各容器每秒转发的调用请求数量；

第三确定模块，用于当与任一应用程序接口标识关联的多个容器中至少一个容器每秒转发的调用请求的数量小于第二流量阈值时，将至少一个容器确定为待销毁容器；以及

销毁模块，用于在确定待销毁容器无待处理的调用请求后，销毁待销毁容器。

在本申请实施例一种可能的实现方式中，该装置还可包括：

第三获取模块，用于响应于获取到的应用程序接口增加请求，获取增加请求中包含的待增加的应用程序接口对应的第二配置文件；

第二生成模块，用于触发运行镜像数据库中的镜像文件、及第二配置文件，以生成与第二配置文件对应的容器。

在本申请实施例一种可能的实现方式中，该装置还可包括：

鉴权模块，用于对调用请求进行鉴权处理；

处理模块，用于在鉴权通过后将调用请求进行转发处理。

在本申请实施例一种可能的实现方式中，上述处理模块，用于：

获取自关联应用程序接口对应的访问地址；以及

将调用请求，发送至自关联应用程序接口对应的访问地址。

在本申请实施例一种可能的实现方式中，该装置还可包括：

第四确定模块，用于响应于获取的访问请求，确定访问请求对应的访问方；

丢弃模块，用于当访问方为多个容器中的任一容器时，将访问请求丢弃。

需要说明的是，前述调用应用程序接口的处理方法实施例的解释说明，也适用于该实施例的调用应用程序接口的处理装置，故在此不再赘述。

本申请实施例的调用应用程序接口的处理装置，通过响应于获取的应用程序接口调用请求，确定调用请求中包括的目标应用程序接口标识，然后查询应用程序接口标识与容器的映射关系表，确定与目标应用程序接口标识匹配的目标容器，之后将调用请求转发给目标容器，以使目标容器对调用请求进行响应。由此，通过将调用请求转发给对应的容器，以使每个容器处理自己关联的应用程序接口的调用请求，即使某个容器崩溃也不会影响处理引擎和其他容器，从而提高了处理引擎的性能。

根据本申请的实施例，本申请还提供了一种电子设备和一种可读存储介质。

如图9所示，是根据本申请实施例的调用应用程序接口的处理方法的电子设备的框图。电子设备旨在表示各种形式的数字计算机，诸如，膝上型计算机、台式计算机、工作台、个人数字助理、服务器、刀片式服务器、大型计算机、和其它适合的计算机。电子设备还可以表示各种形式的移动装置，诸如，个人数字处理、蜂窝电话、智能电话、可穿戴设备和其它类似的计算装置。本文所示的部件、它们的连接和关系、以及它们的功能仅仅作为示例，并且不意在限制本文中描述的和/或者要求的本申请的实现。

如图9所示，该电子设备包括：一个或多个处理器901、存储器902，以及用于连接各部件的接口，包括高速接口和低速接口。各个部件利用不同的总线互相连接，并且可以被安装在公共主板上或者根据需要以其它方式安装。处理器可以对在电子设备内执行的指令进行处理，包括存储在存储器中或者存储器上以在外部输入/输出装置(诸如，耦合至接口的显示设备)上显示GUI的图形信息的指令。在其它实施方式中，若需要，可以将多个处理器和/或多条总线与多个存储器和多个存储器一起使用。同样，可以连接多个电子设备，各个设备提供部分必要的操作(例如，作为服务器阵列、一组刀片式服务器、或者多处理器系统)。图9中以一个处理器901为例。

存储器902即为本申请所提供的非瞬时计算机可读存储介质。其中，所述存储器存储有可由至少一个处理器执行的指令，以使所述至少一个处理器执行本申请所提供的调用应用程序接口的处理方法。本申请的非瞬时计算机可读存储介质存储计算机指令，该计算机指令用于使计算机执行本申请所提供的调用应用程序接口的处理方法。

存储器902作为一种非瞬时计算机可读存储介质，可用于存储非瞬时软件程序、非瞬时计算机可执行程序以及模块，如本申请实施例中的调用应用程序接口的处理方法对应的程序指令/模块(例如，附图8所示的第一确定模块810、第二确定模块820及第一发送模块830)。处理器901通过运行存储在存储器902中的非瞬时软件程序、指令以及模块，从而执行服务器的各种功能应用以及数据处理，即实现上述方法实施例中的调用应用程序接口的处理方法。

存储器902可以包括存储程序区和存储数据区，其中，存储程序区可存储操作系统、至少一个功能所需要的应用程序；存储数据区可存储根据调用应用程序接口的处理电子设备的使用所创建的数据等。此外，存储器902可以包括高速随机存取存储器，还可以包括非瞬时存储器，例如至少一个磁盘存储器件、闪存器件、或其他非瞬时固态存储器件。在一些实施例中，存储器902可选包括相对于处理器901远程设置的存储器，这些远程存储器可以通过网络连接至调用应用程序接口的处理方法的电子设备。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。

调用应用程序接口的处理方法的电子设备还可以包括：输入装置903和输出装置904。处理器901、存储器902、输入装置903和输出装置904可以通过总线或者其他方式连接，图9中以通过总线连接为例。

输入装置903可接收输入的数字或字符信息，以及产生与调用应用程序接口的处理方法的电子设备的用户设置以及功能控制有关的键信号输入，例如触摸屏、小键盘、鼠标、轨迹板、触摸板、指示杆、一个或者多个鼠标按钮、轨迹球、操纵杆等输入装置。输出装置904可以包括显示设备、辅助照明装置(例如，LED)和触觉反馈装置(例如，振动电机)等。该显示设备可以包括但不限于，液晶显示器(LCD)、发光二极管(LED)显示器和等离子体显示器。在一些实施方式中，显示设备可以是触摸屏。

此处描述的系统和技术的各种实施方式可以在数字电子电路系统、集成电路系统、专用ASIC(专用集成电路)、计算机硬件、固件、软件、和/或它们的组合中实现。这些各种实施方式可以包括：实施在一个或者多个计算机程序中，该一个或者多个计算机程序可在包括至少一个可编程处理器的可编程系统上执行和/或解释，该可编程处理器可以是专用或者通用可编程处理器，可以从存储系统、至少一个输入装置、和至少一个输出装置接收数据和指令，并且将数据和指令传输至该存储系统、该至少一个输入装置、和该至少一个输出装置。

这些计算程序(也称作程序、软件、软件应用、或者代码)包括可编程处理器的机器指令，并且可以利用高级过程和/或面向对象的编程语言、和/或汇编/机器语言来实施这些计算程序。如本文使用的，术语“机器可读介质”和“计算机可读介质”指的是用于将机器指令和/或数据提供给可编程处理器的任何计算机程序产品、设备、和/或装置(例如，磁盘、光盘、存储器、可编程逻辑装置(PLD))，包括，接收作为机器可读信号的机器指令的机器可读介质。术语“机器可读信号”指的是用于将机器指令和/或数据提供给可编程处理器的任何信号。

为了提供与用户的交互，可以在计算机上实施此处描述的系统和技术，该计算机具有：用于向用户显示信息的显示装置(例如，CRT(阴极射线管)或者LCD(液晶显示器)监视器)；以及键盘和指向装置(例如，鼠标或者轨迹球)，用户可以通过该键盘和该指向装置来将输入提供给计算机。其它种类的装置还可以用于提供与用户的交互；例如，提供给用户的反馈可以是任何形式的传感反馈(例如，视觉反馈、听觉反馈、或者触觉反馈)；并且可以用任何形式(包括声输入、语音输入或者、触觉输入)来接收来自用户的输入。

可以将此处描述的系统和技术实施在包括后台部件的计算系统(例如，作为数据服务器)、或者包括中间件部件的计算系统(例如，应用服务器)、或者包括前端部件的计算系统(例如，具有图形用户界面或者网络浏览器的用户计算机，用户可以通过该图形用户界面或者该网络浏览器来与此处描述的系统和技术的实施方式交互)、或者包括这种后台部件、中间件部件、或者前端部件的任何组合的计算系统中。可以通过任何形式或者介质的数字数据通信(例如，通信网络)来将系统的部件相互连接。通信网络的示例包括：局域网(LAN)、广域网(WAN)和互联网。

计算机系统可以包括客户端和服务器。客户端和服务器一般远离彼此并且通常通过通信网络进行交互。通过在相应的计算机上运行并且彼此具有客户端-服务器关系的计算机程序来产生客户端和服务器的关系。服务器可以是云服务器，又称为云计算服务器或云主机，是云计算服务体系中的一项主机产品，以解决了传统物理主机与VPS(VirtualPrivate Server,虚拟专用服务器)服务中，存在的管理难度大，业务扩展性弱的缺陷。

根据本申请实施例的技术方案，通过将调用请求转发给对应的容器，以使每个容器处理自己关联的应用程序接口的调用请求，即使某个容器崩溃也不会影响处理引擎和其他容器，从而提高了处理引擎的性能。

在本说明书的描述中，术语“第一”、“第二”仅用于描述目的，而不能理解为指示或暗示相对重要性或者隐含指明所指示的技术特征的数量。由此，限定有“第一”、“第二”的特征可以明示或者隐含地包括至少一个该特征。在本申请的描述中，“多个”的含义是至少两个，例如两个，三个等，除非另有明确具体的限定。

尽管上面已经示出和描述了本申请的实施例，可以理解的是，上述实施例是示例性的，不能理解为对本申请的限制，本领域的普通技术人员在本申请的范围内可以对上述实施例进行变化、修改、替换和变型。

Claims (24)

1.一种调用应用程序接口的处理方法，包括：

响应于获取的应用程序接口调用请求，确定所述调用请求中包括的目标应用程序接口标识；

查询应用程序接口标识与容器的映射关系表，确定与所述目标应用程序接口标识匹配的目标容器；以及

将所述调用请求转发给所述目标容器，以使所述目标容器对所述调用请求进行响应。

2.如权利要求1所述的方法，其中，如果所述映射关系表中与所述目标应用程序接口标识匹配的容器数量为N，其中，N为大于1的正整数，则所述查询应用程序接口标识与容器标识的映射关系表，确定与所述目标应用程序接口标识匹配的目标容器，包括：

从所述N个容器中随机抽取一个容器，作为所述目标容器；

或者，

根据所述N个容器的被调用顺序，确定当前待调用的容器为目标容器。

3.如权利要求1所述的方法，还包括:

获取每个所述容器各自每秒转发的调用请求的数量；以及

如果所述多个容器中的任一容器确定其每秒转发的调用请求的数量大于第一流量阈值，则向主控节点发送容器生成请求，其中，所述容器生成请求中包括所述任一容器自关联的应用程序接口标识。

4.如权利要求1所述的方法，多个容器分布在至少两个设备中，所述方法还包括:

获取同设备中每个容器每秒转发的调用请求数量；

如果同设备中任一容器每秒转发的调用请求数量大于其对应的第一流量阈值时，则向主控节点发送容器生成请求，其中，所述生成请求中包括所述任一容器自关联的应用程序接口标识。

5.如权利要求4所述的方法，其中，在所述向主控节点发送容器生成请求之后，还包括：

根据镜像数据库中的镜像文件及所述任一容器自关联的应用程序接口标识，生成新容器，其中，所述新容器自关联的应用程序接口标识与所述任一容器自关联的应用程序接口标识相同。

6.如权利要求5所述的方法，其中，所述根据镜像数据库中的镜像文件及所述任一容器自关联的应用程序接口标识，生成新容器，包括：

获取与所述任一容器自关联的应用程序接口标识对应的第一配置文件；

触发运行所述镜像数据库中的镜像文件、及所述第一配置文件，以生成所述新容器。

7.如权利要求4所述的方法，其中，在所述获取同设备中每个容器每秒转发的调用请求数量之后，还包括：

将所述同设备中每个所述容器每秒转发的调用请求数量、及每个容器关联的应用程序接口标识，上报给主控节点，以使所述主控节点确定与每个应用程序接口标识关联的各容器每秒转发的调用请求数量；

如果与任一应用程序接口标识关联的多个容器中至少一个容器每秒转发的调用请求的数量小于第二流量阈值，则将所述至少一个容器确定为待销毁容器；以及

在确定所述待销毁容器无待处理的调用请求后，销毁所述待销毁容器。

8.如权利要求4-7任一所述的方法，还包括：

响应于获取到的应用程序接口增加请求，获取所述增加请求中包含的待增加的应用程序接口对应的第二配置文件；

触发运行所述镜像数据库中的镜像文件、及所述第二配置文件，以生成与所述第二配置文件对应的容器。

9.如权利要求1-7任一所述的方法，其中，在所述将所述调用请求转发给所述目标容器之后，还包括：

对所述调用请求进行鉴权处理，并在鉴权通过后将所述调用请求进行转发处理。

10.如权利要求9所述的方法，其中，所述将所述调用请求进行转发处理，包括：

获取自关联应用程序接口对应的访问地址；以及

将所述调用请求，发送至所述自关联应用程序接口对应的访问地址。

11.如权利要求10所述的方法，还包括：

响应于获取的访问请求，确定所述访问请求对应的访问方；

如果所述访问方为所述多个容器中的任一容器，则将所述访问请求丢弃。

12.一种调用应用程序接口的处理装置，包括：

第一确定模块，用于响应于获取的应用程序接口调用请求，确定所述调用请求中包括的目标应用程序接口标识；

第二确定模块，用于查询应用程序接口标识与容器的映射关系表，确定与所述目标应用程序接口标识匹配的目标容器；以及

第一发送模块，用于将所述调用请求转发给所述目标容器，以使所述目标容器对所述调用请求进行响应。

13.如权利要求12所述的装置，其中，如果所述映射关系表中与所述目标应用程序接口标识匹配的容器数量为N，其中，N为大于1的正整数，则所述第二确定模块，用于：

从所述N个容器中随机抽取一个容器，作为所述目标容器；

或者，

根据所述N个容器的被调用顺序，确定当前待调用的容器为目标容器。

14.如权利要求12所述的装置，还包括：

第一获取模块，用于获取每个所述容器各自每秒转发的调用请求的数量；以及

第二发送模块，用于当所述多个容器中的任一容器确定其每秒转发的调用请求的数量大于第一流量阈值是，向主控节点发送容器生成请求，其中，所述容器生成请求中包括所述任一容器自关联的应用程序接口标识。

15.如权利要求12所述的装置，其中，多个容器分布在至少两个设备中，所述装置还包括：

第二获取模块，用于获取同设备中每个容器每秒转发的调用请求数量；

第三发送模块，用于如果同设备中任一容器每秒转发的调用请求数量大于其对应的第一流量阈值时，则向主控节点发送容器生成请求，其中，所述生成请求中包括所述任一容器自关联的应用程序接口标识。

16.如权利要求15所述的装置，还包括：

第一生成模块，用于根据镜像数据库中的镜像文件及所述任一容器自关联的应用程序接口标识，生成新容器，其中，所述新容器自关联的应用程序接口标识与所述任一容器自关联的应用程序接口标识相同。

17.如权利要求16所述的装置，其中，所述第一生成模块，包括：

获取单元，用于获取与所述任一容器自关联的应用程序接口标识对应的第一配置文件；

生成单元，用于触发运行所述镜像数据库中的镜像文件、及所述第一配置文件，以生成所述新容器。

18.如权利要求15所述的装置，还包括：

上报模块，用于将所述同设备中每个所述容器每秒转发的调用请求数量、及每个容器关联的应用程序接口标识，上报给主控节点，以使所述主控节点确定与每个应用程序接口标识关联的各容器每秒转发的调用请求数量；

第三确定模块，用于当与任一应用程序接口标识关联的多个容器中至少一个容器每秒转发的调用请求的数量小于第二流量阈值时，将所述至少一个容器确定为待销毁容器；以及

销毁模块，用于在确定所述待销毁容器无待处理的调用请求后，销毁所述待销毁容器。

19.如权利要求15-18任一所述的装置，还包括：

第三获取模块，用于响应于获取到的应用程序接口增加请求，获取所述增加请求中包含的待增加的应用程序接口对应的第二配置文件；

第二生成模块，用于触发运行所述镜像数据库中的镜像文件、及所述第二配置文件，以生成与所述第二配置文件对应的容器。

20.如权利要求12-18任一所述的装置，还包括：

鉴权模块，用于对所述调用请求进行鉴权处理；

处理模块，用于在鉴权通过后将所述调用请求进行转发处理。

21.如权利要求20所述的装置，所述处理模块，用于：

获取自关联应用程序接口对应的访问地址；以及

将所述调用请求，发送至所述自关联应用程序接口对应的访问地址。

22.如权利要求21所述的装置，还包括：

第四确定模块，用于响应于获取的访问请求，确定所述访问请求对应的访问方；

丢弃模块，用于当所述访问方为所述多个容器中的任一容器时，将所述访问请求丢弃。

23.一种电子设备，包括：

至少一个处理器；以及

与所述至少一个处理器通信连接的存储器；其中，

所述存储器存储有可被所述至少一个处理器执行的指令，所述指令被所述至少一个处理器执行，以使所述至少一个处理器能够执行权利要求1-11中任一项所述的调用应用程序接口的处理方法。

24.一种存储有计算机指令的非瞬时计算机可读存储介质，所述计算机指令用于使所述计算机执行权利要求1-11中任一项所述的调用应用程序接口的处理方法。

Images