API网关的动态配置方法、装置，以及，电子设备与流程

api网关的动态配置方法、装置，以及，电子设备
技术领域
1.本技术涉及通信技术领域，特别是涉及api网关的动态配置方法、装置，以及，电子设备，计算机可读存储介质。

背景技术：

2.随着互联网的发展，业务场景越来越复杂，单一web应用已无法满足业务的发展诉求，微服务架构逐渐成为了主流。为了对客户端屏蔽服务端架构，实现服务端的快速迭代，api(application program interface，应用程序)网关基本成为了微服务架构的标配组件。以nginx网关为例，作为web服务(基于标准的web协议提供服务)的唯一出入口，所有流量都会经过nginx网关，现有技术中，系统水平扩缩容等web服务列表发生更新时，需要人工配置nginx网关，不仅耗费时间久，还需要reload(重新加载)重启，造成部分请求耗时增长20％-50％。
3.可见，api网关的配置方法还需要改进。

技术实现要素：

4.本技术实施例提供一种api网关的动态配置方法及装置，能够提升api网关的配置实时性和效率。
5.第一方面，本技术实施例提供了一种api网关的动态配置方法，应用于api网关，所述方法包括：
6.向目标服务端注册由所述api网关进行路由处理的web服务；
7.基于所述目标服务端发送的更新信息，从所述目标服务端获取所述更新信息对应的web服务的服务配置信息，其中，所述web服务为：由所述api网关进行路由处理，且预先在所述目标服务端注册服务配置信息的服务，所述更新信息是所述目标服务端在监听到所述web服务注册的服务配置信息发生调整后生成的；
8.根据获取的所述服务配置信息，更新所述api网关中存储的相应上行服务路由表。
9.第二方面，本技术实施例提供了一种api网关的动态配置装置，应用于api网关，所述装置包括：
10.第一注册模块，用于向目标服务端注册由所述api网关进行路由处理的web服务；
11.服务配置信息获取模块，用于基于所述目标服务端发送的更新信息，从所述目标服务端获取所述更新信息对应的web服务的服务配置信息，其中，所述web服务为：由所述api网关进行路由处理，且预先在所述目标服务端注册服务配置信息的服务，所述更新信息是所述目标服务端在监听到所述web服务注册的服务配置信息发生调整后生成的；
12.上行服务路由表更新模块，用于根据获取的所述服务配置信息，更新所述api网关中存储的相应上行服务路由表。
13.第三方面，本技术实施例提供了一种api网关的动态配置方法，应用于目标服务端，所述方法包括：
14.基于api网关的注册操作，获取所述api网关注册的web服务，以及，基于所述web服务的注册操作，获取所述web服务注册的服务配置信息；
15.监听所述web服务注册的服务配置信息的调整；
16.在监听到所述web服务注册的服务配置信息发生调整之后，向所述api网关发送更新信息，所述更新信息用于触发所述api网关执行以下操作：基于所述更新信息，从所述目标服务端获取所述更新信息对应的web服务的服务配置信息；根据获取的所述服务配置信息，更新所述api网关中存储的相应上行服务路由表。
17.第四方面，本技术实施例提供了一种api网关的动态配置装置，应用于目标服务端，所述装置包括：
18.第二注册模块，用于基于api网关的注册操作，获取所述api网关注册的web服务，以及，基于所述web服务的注册操作，获取所述web服务注册的服务配置信息；
19.服务配置信息调整监听模块，用于监听所述web服务注册的服务配置信息的调整；
20.更新通知模块，用于在监听到所述web服务注册的服务配置信息发生调整之后，向所述api网关发送更新信息，所述更新信息用于触发所述api网关执行以下操作：基于所述更新信息，从所述目标服务端获取所述更新信息对应的web服务的服务配置信息；根据获取的所述服务配置信息，更新所述api网关中存储的相应上行服务路由表。
21.第五方面，本技术实施例还公开了一种电子设备，包括存储器、处理器及存储在所述存储器上并可在处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现本技术实施例所述的api网关的动态配置方法。
22.第六方面，本技术实施例提供了一种计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行时本技术实施例公开的api网关的动态配置方法的步骤。
23.本技术实施例公开的api网关的动态配置方法，应用于api网关，通过在启动后向目标服务端注册由所述api网关进行路由处理的web服务；并基于目标服务端发送的更新信息，从所述目标服务端获取所述更新信息对应的web服务的服务配置信息，其中，所述web服务为：由所述api网关进行路由处理，且预先在所述目标服务端注册服务配置信息的服务，所述更新信息是所述目标服务端在监听到所述web服务注册的服务配置信息发生调整后生成的；然后，根据获取的所述服务配置信息，更新所述api网关中存储的相应上行服务路由，实现了实时根据web服务的调整，对api网关进行动态维护，提升了api网关的维护实时性和效率。
24.上述说明仅是本技术技术方案的概述，为了能够更清楚了解本技术的技术手段，而可依照说明书的内容予以实施，并且为了让本技术的上述和其它目的、特征和优点能够更明显易懂，以下特举本技术的具体实施方式。
附图说明
25.为使本技术实施例的目的、技术方案和优点更加清楚，下面将结合本技术实施例中的附图，对本技术实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本技术一部分实施例，而不是全部的实施例。基于本技术中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本技术保护的范围。
26.图1是本技术实施例中的api网关的动态配置方法的一个流程图；
27.图2是本技术实施例中的api网关的动态配置方法应用系统架构示意图；
28.图3是本技术实施例中的api网关的动态配置方法的另一流程图；
29.图4是本技术实施例中的api网关的动态配置方法中api网关启动流程图之一；
30.图5是本技术实施例中的api网关的动态配置方法中api网关启动流程图之二；
31.图6是本技术实施例中的api网关的动态配置方法的又一个流程图；
32.图7是本技术实施例中的api网关的动态配置装置结构示意图之一；
33.图8是本技术实施例中的api网关的动态配置装置结构示意图之二；
34.图9示意性地示出了用于执行根据本技术的方法的电子设备的框图；以及
35.图10示意性地示出了用于保持或者携带实现根据本技术的方法的程序代码的存储单元。
具体实施方式
36.下面将结合本技术实施例中的附图，对本技术实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本技术一部分实施例，而不是全部的实施例。基于本技术中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本技术保护的范围。
37.本技术实施例公开了一种api网关的动态配置方法，应用于api网关，如图1所示，所述方法包括：步骤110至步骤130。
38.步骤110，向目标服务端注册由所述api网关进行路由处理的web服务。
39.本技术实施例中公开的api网关的动态配置方法，应用于如图2所示的微服务架构中。如图2所示，所述微服务架构包括：api网关210、目标服务端220，以及，web服务端230。
40.其中，所述api网关210作为客户端访问服务端的唯一入口。微服务架构内部服务，即web服务端230只需专注于业务逻辑，与业务无关的通用功能都提取到api网关统一处理，使得搭建一个内部服务变得更加简单、高效。
41.路由分发可以说是网关最核心的职责。对于客户端发送过来的请求，网关需要能根据请求信息进行正确的路由，将请求分根据负载策略转发到后端服务；对于后端服务发送过来的数据(例如：对请求的响应或后端服务主动推送)，网关需要数据正确响应到指定的客户端。其中，所述api网关可以为spring cloud gateway微服务网关，也可以为例如nginx网关。nginx网关本身性能比传统微服务网关spring cloud gateway高6倍以上。本技术实施例中所述的api网关的动态配置方法，应用于nginx为服务网关时，可以提升api网关的性能。
42.其中，目标服务端220用于根据所述api网关210，以及，web服务的注册信息，管理web服务的服务配置信息的变更，并实时同步至注册了该web服务的api网关210中。
43.本技术实施例中所述的目标服务端可以为具有配置信息管理功能的服务端，例如，所述目标服务端可以nacos(dynamic naming and configuration service的首字母简称，一个更易于构建云原生应用的动态服务发现、配置管理和服务管理平台)为服务平台的服务端。
44.上述微服务架构中各组成角的功能和具体实施方式，将在下文中结合api网关的动态配置方法具体实施方式进行说明。
45.本技术实施例中，api网关通过目标服务端开放的注册端口，将自身元数据发送到所述目标服务端，以完成api网关注册。其中api网关的自身元数据包括但不限于以下一项或多项数据：服务名、服务类型、ip地址和端口等。例如，可以通过以下格式的数据表达api网关匹配的服务类型：“api-service:8854＝now＝2022-05-02 08:50:50＝api”，其中，结尾为字符“api”的服务类型表示api网关(如nginx网关)。
46.api网关的自身元数据中，服务名用于指示该api网关注册哪些服务(例如，该api网关执行哪些服务的访问路由处理)，ip地址和端口用于目标服务端通过http服务向api网关发送通知等数据，服务类型用于目标服务端对api网关的注册数据和web服务的注册数据进行区分。
47.本技术的一些实施例中，在向目标服务端注册由所述api网关进行路由处理的web服务之后，还包括：通过发送心跳信号向所述目标服务端续约。例如，api网关按照预先配置的时间间隔向目标服务端发送心跳信号，以保持在目标服务端的存活状态，维持api网关与目标服务端之间的通信连接。
48.步骤120，基于所述目标服务端发送的更新信息，从所述目标服务端获取所述更新信息对应的web服务的服务配置信息。
49.其中，所述web服务为：由所述api网关进行路由处理，且预先在所述目标服务端注册服务配置信息的服务，所述更新信息是所述目标服务端在监听到所述web服务注册的服务配置信息发生调整后生成的。
50.本技术的实施例中，所述服务配置信息包括但不限于：web服务的ip地址、端口等相关信息。其中，服务配置信息可以理解为提供该web服务的服务端的配置信息，如服务端的ip地址、端口等。
51.本技术具体实施例时，不仅需要api网关在目标服务端进行注册，还需要web服务在所述目标服务端进行注册。只有web服务在所述目标服务端进行注册之后，所述目标服务端才能对已经注册的web服务的服务配置信息(如ip地址、端口等)进行监听。
52.例如，web服务可以通过目标服务端的开放的注册端口，将自身元数据发送到所述目标服务端，以完成web服务注册。其中web服务的自身元数据包括但不限于以下一项或多项数据：服务名、服务类型、ip地址和端口等。每个web服务的自身元数据中可以包括一个或多个ip地址和端口，其中，服务名为相应web服务的服务名，服务类型用于目标服务端区分api网关的注册信息或者web服务的注册信息。
53.本技术的一些实施例中，目标服务端根据web服务注册的元数据存储该web服务的服务配置信息，并监听web服务器的服务配置信息变化，以及时获取到web服务的扩缩容状态。例如，web服务在目标服务端完成注册之后，目标服务端和该web服务的各ip地址之间将建立心跳连接，web服务通过向目标服务端发送心跳信号与目标服务端续约，用于在目标服务端维持存活状态。当目标服务端在预设时长内未收到某个web服务的某个注册ip地址的心跳信号时，可以认为该web服务出现了缩容状态，该注册ip地址将被从该web服务的服务配置信息中被移除。之后，目标服务端将该web服务的状态变更通知到注册了该web服务的api网关，使得该api网关可以及时调整该web服务的路由信息。
54.本技术的另一些实施例中，当目标服务端接收到某个web服务的注册调用之后，会根据注册请求中携带的元数据中的服务名确定该web服务是否已经注册过，若未注册过，则
直接进行web服务注册，若已经注册过，则进一步判断注册的服务配置信息是否发生了变化。在目标服务端确定某个web服务的服务配置信息发生了变化之后(例如，该web服务新增了ip地址，出现了扩容状态)，更新存储该web服务的服务配置信息。之后，目标服务端将该web服务的状态变更通知到注册了该web服务的api网关，使得该api网关可以及时调整该web服务的路由信息。
55.本技术的一些实施例中，api网关在启动之后，还可以主动从目标服务端拉取注册的各web服务的服务配置信息。
56.本技术的一些实施例中，当某个web服务的服务配置信息发生调整之后，目标服务端根据api网关的发送的元数据，确定注册了某个web服务的api网关，并通过向该api网关发送更新通知或更新请求等方式，将该web服务更新后的服务配置信息推送至该api网关。
57.步骤130，根据获取的所述服务配置信息，更新所述api网关中存储的相应上行服务路由表。
58.本技术的实施例中，api网关中存储有每个web服务各自对应的上行服务路由表。api网关的程序代码在执行过程中，按照每个web服务各自对应的上行服务路由表，对该web服务的访问进行路由，基于负载均衡原则，将该访问路由到所述上行服务路由表中指定的某个ip地址。
59.因此，api网关根据获取的所述服务配置信息之后，首先需要及时更新所述api网关本地存储的上行服务路由表，使得api网关本地运行的路由处理程序可以根据web服务的最新配置信息，执行访问路由。
60.例如，api网关在根据获取的所述服务配置信息，更新所述api网关中存储的相应上行服务路由表之后，响应于客户端的访问，api网关可以根据所述上行服务路由表执行所述访问的转发。
61.本技术的一些实施例中，所述根据获取的所述服务配置信息，更新所述api网关中存储的相应上行服务路由表，包括：根据所述服务配置信息，更新所述api网关中存储的与所述web服务对应的上行服务路由表，使得所述api网关中启动的工作进程基于更新后的所述上行服务路由表进行所述web服务的路由处理。
62.nginx采用多进程的工作模式，在nginx启动后，会创建并启动一个master进程(即主进程)和多个互相独立的worker进程(即工作进程)。其中，master进程负责接收外部信号，然后通知各个worker进程有信号到了，每个worker进程通过抢占式的方式来处理这个信号对应的连接。同时，master进程能够监控每个worker进程的状态，当worker进程出现异常或退出后，master进程会fork(分叉)新的worker进程。
63.本技术实施例中，以api网关为nginx网关为例，nginx网关采用多进程的工作模式，在nginx网关启动后，创建并启动一个master进程(即主进程)和多个worker进程(即工作进程)。其中，master进程用于接收目标服务端发送的更新信息，之后，基于目标服务端发送的更新信息，从所述目标服务端获取所述更新信息对应的web服务的服务配置信息，并根据获取的所述服务配置信息，更新所述api网关中存储的相应上行服务路由表。master进程还负责接收客户端的访问，然后通知各个worker。每个worker进程通过抢占式的方式来处理这个访问。在worker进程处理访问的过程中，worker进程实时读取master进程存储的上行服务路由表，根据处理的访问对应的服务名获取相应的上行服务路由表，之后，根据获取
的上行服务路由表(如服务名对应的ip地址、端口号等)执行该访问的路由处理。
64.在nginx的设计中，每一个上行服务路由表(即upstream)维护了一张静态路由表，存储了web服务的ip地址、端口等配置信息。每次客户端的访问请求到达后，nginx首先检索该路由表获得转发地址，然后，依据具体的负载均衡算法转发请求。由于这张路由表是静态的，如果变更后，则必须reload(即重新加载)，现有技术中，当web服务的服务配置信息(如ip地址)发生变化后，需要网关维护人员手动修改nginx的配置文件，以修改该web服务对应的上行服务路由表(即upstream)下发，之后，通过重新启动nginx，以重新加载上行服务路由表，使新的web服务配置生效，实时性差，高并发情况下，会造成部分请求耗时增长20％-50％。
65.本技术实施例中，基于目标服务端(如nacos服务平台)动态监听web服务的配置信息(如ip地址和/或端口)，并通过接口把web服务地址等变更信息发送到nginx网关，nginx网关收到请求后，直接动态更新上行服务路由表(即upstream)，从而避免reaload，使得web服务的ip地址等配置信息变化可以及时生效，并且不会产生服务抖动。
66.以web服务为push服务集为例，push服务集注册到nacos，nacos记录的push服务(服务名、ip和端口)的地址列表。nginx中work进程upstream配置路由语法是upstream服务名，两者的服务名一致，作为服务配置信息(如ip地址)的索引。push服务的ip地址动态调整时，nacos动态通知nginx，nginx根据服务名到对应的upstream(即上行服务路由表)，再调整upstream(即上行服务路由表)下的ip地址信息，达到动态调整的效果。
67.本技术的一些实施例中，如图3所示，所述根据所述服务配置信息，更新所述api网关中存储的与所述web服务对应的上行服务路由表之后，还包括：步骤140。
68.步骤140，对更新后的所述服务配置信息进行备份存储。
69.在api网关根据所述服务配置信息，更新本地存储的与所述web服务对应的上行服务路由表之后，为了防止目标服务端意外宕机，影响api网关的正常服务，api网关进一步将更新后的所述上行服务路由表进行备份存储。dump文件又叫内存转储文件或者叫内存快照文件，是进程的内存镜像。本技术的一些实施例中，可以利用dump文件对更新后的所述上行服务路由表进行备份存储。例如，可以在api网关的配置文件中定义dump文件的存储路径，即web服务的服务配置信息的备份文件路径，在api网关拉取到web服务的最新服务配置信息之后，不仅要更新本地的上行服务路由表，还要对最新服务配置信息进行备份。
70.备份存储的最新服务配置信息的具体用途将在下文中阐述，此处不再赘述。
71.前述步骤110至步骤140描述了api网关正常工作过程中，执行动态配置的方案。为了使api网关能够正常工作，api网关的启动过程中，需要执行一系列相应的处理。下面结合图4对api网关的启动过程进行进一步说明。
72.如图4所示，api网关的启动过程包括：步骤410至步骤440。
73.步骤410，在启动过程中，验证本地存储的配置文件，所述配置文件中包括：所述目标服务端的访问配置。
74.api网关本地存储的配置文件是网关维护人员预先配置、下发的，是api网关正常工作的依据。以api网关为nginx网关为例，nginx启动时，首先验证配置文件是不是正确，如果配置文件错误则直接结束，启动失败。其中，验证本地存储的配置文件可以包括以下操作：验证配置文件中是否包括以下配置信息：目标服务端的访问配置、web服务的服务配置
信息的备份路径，以及，用于接收目标服务端发送的信息的位置(如location)；验证各配置信息的格式和取值是否符合要求等。
75.本技术的实施例中，可以通过自定义操作符按照预设语法定义各项内容的配置信息。其中，目标服务端的访问配置用于指定api网关访问的目标服务器(如nacos服务平台)的地址，以及，请求超时时间、重试次数、心跳续约时间等等。
76.步骤420，在验证通过的情况下，基于所述访问配置从所述目标服务端拉取预先注册的各web服务的服务配置信息。
77.在配置文件验证通过之后，api网关接下来可以基于配置文件中配置的目标服务端的地址与目标服务端建立连接，从目标服务端拉取预先注册的各web服务的服务配置信息。
78.本技术的一些实施例中，api网关可以通过目标服务端开放的服务获取接口，拉取预先注册的各web服务的服务配置信息。当api网关尚未在目标服务端进行注册时，需要首先在目标服务端进行注册，其中，注册是api网关提交的元数据包括：web服务的服务名，这样，在拉取服务配置信息时，既可以拉取注册的服务名对应web服务的服务配置信息。
79.步骤430，根据拉取的所述各web服务的服务配置信息，初始化各所述web服务对应的上行服务路由表。
80.如果api网关成功从目标服务端拉取到web服务的服务配置信息，则接下来，api网关根据拉取的web服务的服务配置信息，更新本地存储的相应web服务的上行服务路由表。例如，前述nginx网关中的master进程存储与各所述web服务对应的上行服务路由表，由各worker进程根据所述上行服务路由表，执行对相应web服务的访问处理。
81.本技术的一些实施例中，如图5所示，所述根据拉取的所述各web服务的服务配置信息，初始化各所述web服务对应的上行服务路由表之后，还包括：步骤440。
82.步骤440，对拉取的所述服务配置信息进行备份存储。
83.至此，结束启动流程。
84.对所述服务配置信息进行备份存储的具体实施方式，参见前文ai网关正常工作状态下动态更新配置信息时的备份存储操作，此处不再赘述。
85.本技术的一些实施例中，如图5所示，所述根据拉取的所述各web服务的服务配置信息，初始化各所述web服务对应的上行服务路由表之前，还包括：步骤422。
86.步骤450，确定是否成功拉取到所述服务配置信息。
87.在成功拉取到所述服务配置信息的情况下是，则跳转至步骤430；在未成功拉取到所述服务配置信息的情况下，跳转至步骤450。
88.步骤450，在未成功拉取到所述服务配置信息的情况下，根据所述api网关本地备份存储的服务配置信息，初始化各所述web服务对应的上行服务路由表。
89.至此，结束启动过程。
90.如果目标服务端宕机或者与api网关出现通信故障，api网关将无法成功从目标服务端成功拉取到web服务的服务配置信息。这种情况下，为了是api网关可以对客户端提供服务，可以基于api网关前一次正常运行备份存储的服务配置信息，初始化各所述web服务对应的上行服务路由表。
91.本技术的一些实施例中，在未成功拉取到所述服务配置信息的情况下，api网关还
可以按照配置文件中设置的超时等待时长、重复拉取次数等信息，重复执行预设次数的拉取操作。
92.为了使读者更加清楚地理解本技术实施例公开的api网关的动态配置方法，下面结合一个具体的基于nginx网关和nacos服务平台的微服务架构，具体说明api网关的动态配置方法的应用流程。
93.在一个具体业务系统中，采用基于springboot(一种开源应用框架)的微服务架构，结合应用的基础架构设施，进行k8s(一种开源容器编排器技术)容器化部署，并采用nginx对各业务中台暴露的api接口进行统一管理，业务站点访问某服务站点的时候，统一走nginx，然后nginx根据一定的轮询策略，将请求路由到后端一台指定的服务器上。
94.基于上述系统架构，业务系统更新时，首先通过gitlab ci/cd自动化构建docker镜像，再上传到harbor镜像仓库，调用kubectl工具，用kubectl工具来实现滚动升级。在系统服务升级时，升级工具(如前述kubectl)把业务系统后端服务器的ip地址注册到nacos注册中心；之后，再调用nginx的上线接口从nacos拉取业务系统后端服务器的ip地址，将服务端的ip地址新增或者更新到nginx的upstream(即上行服务路由表)中。这样，后端服务器就可以提供对相应业务的访问，很大程度上上减少了人工误操作，提升了而业务系统的运维效率。
95.在服务运行过程中，可能因为某些原因，服务请求飙高，超过了当前服务集的承载能力，当业务系统检测到这些情况后，可以动态扩充后端服务器。例如，在启动docker容器的时候，应用系统在启动的时候，将自身的后端服务器ip地址注册到nacos注册中心，nacos注册中心再将这些信息同步到nginx，有nginx更新upstream(即上行服务路由表)中，这样，新增的服务器就可以提供访问，整体上实现动态扩容或缩容。
96.本技术实施例公开的api网关的动态配置方法，应用于api网关，所述方法通过在启动后向目标服务端注册由所述api网关进行路由处理的web服务；并基于目标服务端发送的更新信息，从所述目标服务端获取所述更新信息对应的web服务的服务配置信息，其中，所述web服务为：由所述api网关进行路由处理，且预先在所述目标服务端注册服务配置信息的服务，所述更新信息是所述目标服务端在监听到所述web服务注册的服务配置信息发生调整后生成的；然后，根据获取的所述服务配置信息，更新所述api网关中存储的相应上行服务路由表，实现了实时根据web服务的调整，对api网关进行动态维护，提升了api网关的维护实时性和效率。
97.本技术实施例公开的api网关的动态配置方法，通过目标服务端实时监听注册到该目标服务端的服务列表(如web服务的服务端ip地址、端口等的列表)，并在服务列表发生调整时，及时将调整后的信息同步至api网关(如nginx网关)，由api网关根据调整后的服务列表更新本地存储的相应web服务的上行服务路由表，使得服务列表的变化可以即时生效，而不需要通过重新启动api网关，重新加载上行服务路由表，不仅缩短了配置时间，提升了维护效率，而且，大大减小了由于更新配置信息对客户端访问的造成的抖动。
98.相应的，本技术实施例中还公开了一种api网关的动态配置，应用于目标服务端，如图6所示，所述方法包括：步骤610至步骤630。
99.步骤610，基于api网关的注册操作，获取所述api网关注册的web服务，以及，基于所述web服务的注册操作，获取所述web服务注册的服务配置信息。
100.本技术的实施例中，api网关可以通过向目标服务端发送注册请求的方式，注册到所述目标服务端，也可以通过调用目标服务端开放的注册接口的方式注册到所述目标服务端。在向目标服务端注册时，api网关需要向目标服务端发送api网关的自身元数据，所述自身元数据中包括：api网关注册的web服务(例如服务名列表)，接收目标服务端发送的信息的地址等。
101.api网关的具体注册方案参见前文描述，此处不再赘述。
102.本技术的实施例中，web服务可以通过向目标服务端发送注册请求的方式，注册到所述目标服务端，也可以通过调用目标服务端开放的注册接口的方式注册到所述目标服务端。在向目标服务端注册时，web服务需要向目标服务端发送web服务的自身元数据，所述自身元数据中包括：web服务注册的服务名、所述服务名对应的ip地址、端口等服务配置信息。
103.web服务的具体注册方案参见前文描述，此处不再赘述。
104.步骤620，监听所述web服务注册的服务配置信息的调整。
105.本技术的一些实施例中，所述服务配置信息包括：ip地址，所述监听所述web服务注册的服务配置信息的调整，包括：基于所述web服务注册的所述ip地址发送的心跳信号，监听所述web服务注册的服务配置信息的调整。
106.在api网关完成注册之后，api网关和目标服务端之间将建立通信连接，用于api网关接收目标服务端推送的更新信息、从目标服务端拉取web服务的服务配置信息等，同时，所述通信连接还用于api网关向目标服务端发送心跳信号，以保持api网关在目标服务端的存活状态。同样的，在web服务完成注册之后，web服务基于注册的每个服务端ip地址分别和目标服务端之间将建立通信连接，用于向目标服务端发送心跳信号，以保持该服务端在目标服务端的存活状态。目标服务端可以根据web服务注册的ip地址(即服务端)发送的心跳信号的状态，判断相应ip地址对应的服务端是否已经停止服务，即web服务是否出现了缩容状态，从而确定所述web服务注册的服务配置信息是否发生了调整。
107.本技术的另一些实施例中，监听所述web服务注册的服务配置信息的调整，还可以包括：基于所述web服务的注册操作，监听所述web服务注册的服务配置信息的调整。
108.例如，当目标服务端接收到web服务发送的注册请求之后，将该web服务当前提交的服务配置信息与目标服务端记录的该web服务端的已注册服务配置信息进行比较，并根据比较结果确定该web服务注册的服务配置信息是否发生了调整。例如，当web服务需要新增服务端时，可以通过在服务配置信息中增加ip地址列表，并基于增加ip地址列表后的服务配置信息，像目标服务端发送注册请求，这样，目标服务端即可监听到该web服务的配置服务信息的调整。
109.步骤630，在监听到所述web服务注册的服务配置信息发生调整之后，向所述api网关发送更新信息，所述更新信息用于触发所述api网关执行以下操作：基于所述更新信息，从所述目标服务端获取所述更新信息对应的web服务的服务配置信息；根据获取的所述服务配置信息，更新所述api网关中存储的相应上行服务路由表。
110.在目标服务端监听到所述web服务注册的服务配置信息发生调整之后，目标服务端进一步根据web服务的服务号，确定注册该web服务的api网关，之后，向该api网关发送更新信息，以将web服务的最新服务配置信息同步到api网关进行生效。
111.本技术的一些实施例中，目标服务端可以通过向api网关推送更新信息的方式，通
知api网关更新存储的相应上行服务路由表。例如，目标服务端可以将web服务的更新后的服务配置信息携带在所述更新信息中，推送至api网关。
112.api网关在接收到目标服务端发送的更新信息之后，基于所述更新信息，从所述目标服务端获取所述更新信息对应的web服务的服务配置信息；之后，根据获取的所述服务配置信息，更新所述api网关中存储的相应上行服务路由表。
113.api网关基于所述更新信息，从所述目标服务端获取所述更新信息对应的web服务的服务配置信息的具体实施方式，参见前文描述，此处不再赘述。
114.api网关根据获取的所述服务配置信息，更新所述api网关中存储的相应上行服务路由表的具体实施方式，参见前文描述，此处不再赘述。
115.本技术实施例公开的api网关的动态配置，通过api网关和web服务首先分别在目标服务端进行注册，之后，由目标服务端监听所述web服务注册的服务配置信息的调整，并在监听到所述web服务注册的服务配置信息发生调整之后，向所述api网关发送更新信息，所述更新信息用于触发所述api网关执行以下操作：基于所述更新信息，从所述目标服务端获取所述更新信息对应的web服务的服务配置信息；根据获取的所述服务配置信息，更新所述api网关中存储的相应上行服务路由表，实现了实时根据web服务的调整对api网关进行动态维护，提升了api网关的维护效率。
116.相应的，本技术实施例还公开了一种api网关的动态配置装置，应用于api网关，如图7所示，所述装置包括：
117.第一注册模块710，用于向目标服务端注册由所述api网关进行路由处理的web服务；
118.服务配置信息获取模块720，用于基于所述目标服务端发送的更新信息，从所述目标服务端获取所述更新信息对应的web服务的服务配置信息，其中，所述web服务为：由所述api网关进行路由处理，且预先在所述目标服务端注册服务配置信息的服务，所述更新信息是所述目标服务端在监听到所述web服务注册的服务配置信息发生调整后生成的；
119.上行服务路由表更新模块730，用于根据获取的所述服务配置信息，更新所述api网关中存储的相应上行服务路由表。
120.本技术的一些实施例中，所述上行服务路由表更新模块730，进一步用于：
121.根据所述服务配置信息，更新所述api网关中存储的与所述web服务对应的上行服务路由表，使得所述api网关中启动的工作进程基于更新后的所述上行服务路由表进行所述web服务的路由处理。
122.本技术的一些实施例中，所述装置还包括：
123.备份存储模块(图中未示出)，用于对更新后的所述服务配置信息进行备份存储。
124.本技术的一些实施例中，所述装置还包括：
125.配置文件验证模块(图中未示出)，用于在启动过程中，验证本地存储的配置文件，所述配置文件中包括：所述目标服务端的访问配置；
126.服务配置信息拉取模块(图中未示出)，用于在验证通过的情况下，基于所述访问配置从所述目标服务端拉取预先注册的各web服务的服务配置信息；
127.上行服务路由表初始化模块(图中未示出)，用于根据拉取的所述各web服务的服务配置信息，初始化各所述web服务对应的上行服务路由表。
128.本技术的一些实施例中，所述根据拉取的所述各web服务的服务配置信息，初始化各所述web服务对应的上行服务路由表之后，所述备份存储模块，还用于对拉取的所述服务配置信息进行备份存储。
129.本技术的一些实施例中，所述根据拉取的所述各web服务的服务配置信息，初始化各所述web服务对应的上行服务路由表之前，所述装置还包括：
130.判断跳转模块(图中未示出)，用于确定是否成功拉取到所述服务配置信息；
131.所述判断跳转模块，还用于在成功拉取到所述服务配置信息的情况下，跳转至所述上行服务路由表初始化模块；
132.所述判断跳转模块，还用于在未成功拉取到所述服务配置信息的情况下，根据所述api网关本地备份存储的所述服务配置信息，初始化各所述web服务对应的上行服务路由表。
133.本技术实施例公开的api网关的动态配置装置，用于实现本技术实施例中所述的api网关的动态配置方法，装置的各模块的具体实施方式不再赘述，可参见方法实施例相应步骤的具体实施方式。
134.本技术实施例公开的一种api网关的动态配置装置，应用于api网关，所述装置通过在启动后向目标服务端注册由所述api网关进行路由处理的web服务；并基于目标服务端发送的更新信息，从所述目标服务端获取所述更新信息对应的web服务的服务配置信息，其中，所述web服务为：由所述api网关进行路由处理，且预先在所述目标服务端注册服务配置信息的服务，所述更新信息是所述目标服务端在监听到所述web服务注册的服务配置信息发生调整后生成的；然后，根据获取的所述服务配置信息，更新所述api网关中存储的相应上行服务路由表，实现了实时根据web服务的调整，对api网关进行动态维护，提升了api网关的维护实时性和效率。
135.本技术实施例公开的api网关的动态配置装置，通过目标服务端实时监听注册到该目标服务端的服务列表(如web服务的服务端ip地址、端口等的列表)，并在服务列表发生调整时，及时将调整后的信息同步至api网关(如nginx网关)，由api网关根据调整后的服务列表更新本地存储的相应web服务的上行服务路由表，使得服务列表的变化可以即时生效，而不需要通过重新启动api网关，重新加载上行服务路由表，不仅缩短了配置时间，提升了维护效率，而且，大大减小了对客户端访问造成的抖动。
136.相应的，本技术实施例中还公开了一种api网关的动态配置装置，应用于目标服务端，如图8所示，所述装置包括：
137.第二注册模块810，用于基于api网关的注册操作，获取所述api网关注册的web服务，以及，基于所述web服务的注册操作，获取所述web服务注册的服务配置信息；
138.服务配置信息调整监听模块820，用于监听所述web服务注册的服务配置信息的调整；
139.更新通知模块830，用于在监听到所述web服务注册的服务配置信息发生调整之后，向所述api网关发送更新信息，所述更新信息用于触发所述api网关执行以下操作：基于所述更新信息，从所述目标服务端获取所述更新信息对应的web服务的服务配置信息；根据获取的所述服务配置信息，更新所述api网关中存储的相应上行服务路由表。
140.本技术的一些实施例中，所述服务配置信息包括：ip地址，所述服务配置信息调整
监听模块820，进一步用于：
141.基于所述web服务注册的所述ip地址发送的心跳信号，监听所述web服务注册的服务配置信息的调整；和/或,
142.基于所述web服务的注册操作，监听所述web服务注册的服务配置信息的调整。
143.本技术实施例公开的api网关的动态配置装置，用于实现本技术实施例中所述的api网关的动态配置方法，装置的各模块的具体实施方式不再赘述，可参见方法实施例相应步骤的具体实施方式。
144.本技术实施例公开的一种api网关的动态配置装置，通过api网关和web服务首先分别在目标服务端进行注册，之后，由目标服务端监听所述web服务注册的服务配置信息的调整，并在监听到所述web服务注册的服务配置信息发生调整之后，向所述api网关发送更新信息，所述更新信息用于触发所述api网关执行以下操作：基于所述更新信息，从所述目标服务端获取所述更新信息对应的web服务的服务配置信息；根据获取的所述服务配置信息，更新所述api网关中存储的相应上行服务路由表，实现了实时根据web服务的调整对api网关进行动态维护，提升了api网关的维护效率。
145.本说明书中的各个实施例均采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似的部分互相参见即可。对于装置实施例而言，由于其与方法实施例基本相似，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。
146.以上对本技术提供的一种api网关的动态配置方法及装置进行了详细介绍，本文中应用了具体个例对本技术的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本技术的方法及其一种核心思想；同时，对于本领域的一般技术人员，依据本技术的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本技术的限制。
147.以上所描述的装置实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性的劳动的情况下，即可以理解并实施。
148.本技术的各个部件实施例可以以硬件实现，或者以在一个或者多个处理器上运行的软件模块实现，或者以它们的组合实现。本领域的技术人员应当理解，可以在实践中使用微处理器或者数字信号处理器(dsp)来实现根据本技术实施例的电子设备中的一些或者全部部件的一些或者全部功能。本技术还可以实现为用于执行这里所描述的方法的一部分或者全部的设备或者装置程序(例如，计算机程序和计算机程序产品)。这样的实现本技术的程序可以存储在计算机可读介质上，或者可以具有一个或者多个信号的形式。这样的信号可以从因特网网站上下载得到，或者在载体信号上提供，或者以任何其他形式提供。
149.例如，图9示出了可以实现根据本技术的方法的电子设备。所述电子设备可以为pc机、移动终端、个人数字助理、平板电脑等。该电子设备传统上包括处理器910和存储器920及存储在所述存储器920上并可在处理器910上运行的程序代码930，所述处理器910执行所述程序代码930时实现上述实施例中所述的方法。所述存储器920可以为计算机程序产品或
者计算机可读介质。存储器920可以是诸如闪存、eeprom(电可擦除可编程只读存储器)、eprom、硬盘或者rom之类的电子存储器。存储器920具有用于执行上述方法中的任何方法步骤的计算机程序的程序代码930的存储空间9201。例如，用于程序代码930的存储空间9201可以包括分别用于实现上面的方法中的各种步骤的各个计算机程序。所述程序代码930为计算机可读代码。这些计算机程序可以从一个或者多个计算机程序产品中读出或者写入到这一个或者多个计算机程序产品中。这些计算机程序产品包括诸如硬盘，紧致盘(cd)、存储卡或者软盘之类的程序代码载体。所述计算机程序包括计算机可读代码，当所述计算机可读代码在电子设备上运行时，导致所述电子设备执行根据上述实施例的方法。
150.本技术实施例还公开了一种计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行时实现如本技术实施例一所述的api网关的动态配置方法的步骤。
151.这样的计算机程序产品可以为计算机可读存储介质，该计算机可读存储介质可以具有与图9所示的电子设备中的存储器920类似布置的存储段、存储空间等。程序代码可以例如以适当形式进行压缩存储在所述计算机可读存储介质中。所述计算机可读存储介质通常为如参考图10所述的便携式或者固定存储单元。通常，存储单元包括计算机可读代码930’，所述计算机可读代码930’为由处理器读取的代码，这些代码被处理器执行时，实现上面所描述的方法中的各个步骤。
152.本文中所称的“一个实施例”、“实施例”或者“一个或者多个实施例”意味着，结合实施例描述的特定特征、结构或者特性包括在本技术的至少一个实施例中。此外，请注意，这里“在一个实施例中”的词语例子不一定全指同一个实施例。
153.在此处所提供的说明书中，说明了大量具体细节。然而，能够理解，本技术的实施例可以在没有这些具体细节的情况下被实践。在一些实例中，并未详细示出公知的方法、结构和技术，以便不模糊对本说明书的理解。
154.在权利要求中，不应将位于括号之间的任何参考符号构造成对权利要求的限制。单词“包含”不排除存在未列在权利要求中的元件或步骤。位于元件之前的单词“一”或“一个”不排除存在多个这样的元件。本技术可以借助于包括有若干不同元件的硬件以及借助于适当编程的计算机来实现。在列举了若干装置的单元权利要求中，这些装置中的若干个可以是通过同一个硬件项来具体体现。单词第一、第二、以及第三等的使用不表示任何顺序。可将这些单词解释为名称。
155.最后应说明的是：以上实施例仅用以说明本技术的技术方案，而非对其限制；尽管参照前述实施例对本技术进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本技术各实施例技术方案的精神和范围。

技术特征：

1.一种api网关的动态配置方法，应用于api网关，其特征在于，所述方法包括：向目标服务端注册由所述api网关进行路由处理的web服务；基于所述目标服务端发送的更新信息，从所述目标服务端获取所述更新信息对应的web服务的服务配置信息，其中，所述web服务为：由所述api网关进行路由处理，且预先在所述目标服务端注册服务配置信息的服务，所述更新信息是所述目标服务端在监听到所述web服务注册的服务配置信息发生调整后生成的；根据获取的所述服务配置信息，更新所述api网关中存储的相应上行服务路由表。2.根据权利要求1所述的方法，其特征在于，所述根据获取的所述服务配置信息，更新所述api网关中存储的相应上行服务路由表，包括：根据所述服务配置信息，更新所述api网关中存储的与所述web服务对应的上行服务路由表，使得所述api网关中启动的工作进程基于更新后的所述上行服务路由表进行所述web服务的路由处理。3.根据权利要求2所述的方法，其特征在于，所述根据所述服务配置信息，更新所述api网关中存储的与所述web服务对应的上行服务路由表之后，还包括：对更新后的所述服务配置信息进行备份存储。4.根据权利要求1至3任一项所述的方法，其特征在于，还包括：在启动过程中，验证本地存储的配置文件，所述配置文件中包括：所述目标服务端的访问配置；在验证通过的情况下，基于所述访问配置从所述目标服务端拉取预先注册的各web服务的服务配置信息；根据拉取的所述各web服务的服务配置信息，初始化各所述web服务对应的上行服务路由表。5.根据权利要求4所述的方法，其特征在于，所述根据拉取的所述各web服务的服务配置信息，初始化各所述web服务对应的上行服务路由表之后，还包括：对拉取的所述服务配置信息进行备份存储。6.根据权利要求4所述的方法，其特征在于，所述根据拉取的所述各web服务的服务配置信息，初始化各所述web服务对应的上行服务路由表之前，还包括：确定是否成功拉取到所述服务配置信息；在成功拉取到所述服务配置信息的情况下，执行所述根据拉取的所述各web服务的服务配置信息，初始化各所述web服务对应的上行服务路由表的步骤；在未成功拉取到所述服务配置信息的情况下，根据所述api网关本地备份存储的所述服务配置信息，初始化各所述web服务对应的上行服务路由表。7.一种api网关的动态配置方法，应用于目标服务端，其特征在于，所述方法包括：基于api网关的注册操作，获取所述api网关注册的web服务，以及，基于所述web服务的注册操作，获取所述web服务注册的服务配置信息；监听所述web服务注册的服务配置信息的调整；在监听到所述web服务注册的服务配置信息发生调整之后，向所述api网关发送更新信息，所述更新信息用于触发所述api网关执行以下操作：基于所述更新信息，从所述目标服务端获取所述更新信息对应的web服务的服务配置信息；根据获取的所述服务配置信息，更
新所述api网关中存储的相应上行服务路由表。8.根据权利要求7所述的方法，其特征在于，所述服务配置信息包括：ip地址，所述监听所述web服务注册的服务配置信息的调整，包括：基于所述web服务注册的所述ip地址发送的心跳信号，监听所述web服务注册的服务配置信息的调整；和/或,基于所述web服务的注册操作，监听所述web服务注册的服务配置信息的调整。9.一种api网关的动态配置装置，应用于api网关，其特征在于，所述装置包括：第一注册模块，用于向目标服务端注册由所述api网关进行路由处理的web服务；服务配置信息获取模块，用于基于所述目标服务端发送的更新信息，从所述目标服务端获取所述更新信息对应的web服务的服务配置信息，其中，所述web服务为：由所述api网关进行路由处理，且预先在所述目标服务端注册服务配置信息的服务，所述更新信息是所述目标服务端在监听到所述web服务注册的服务配置信息发生调整后生成的；上行服务路由表更新模块，用于根据获取的所述服务配置信息，更新所述api网关中存储的相应上行服务路由表。10.一种api网关的动态配置装置，应用于目标服务端，其特征在于，所述装置包括：第二注册模块，用于基于api网关的注册操作，获取所述api网关注册的web服务，以及，基于所述web服务的注册操作，获取所述web服务注册的服务配置信息；服务配置信息调整监听模块，用于监听所述web服务注册的服务配置信息的调整；更新通知模块，用于在监听到所述web服务注册的服务配置信息发生调整之后，向所述api网关发送更新信息，所述更新信息用于触发所述api网关执行以下操作：基于所述更新信息，从所述目标服务端获取所述更新信息对应的web服务的服务配置信息；根据获取的所述服务配置信息，更新所述api网关中存储的相应上行服务路由表。11.一种电子设备，包括存储器、处理器及存储在所述存储器上并可在处理器上运行的程序代码，其特征在于，所述处理器执行所述程序代码时实现权利要求1至8任意一项所述的api网关的动态配置方法。12.一种计算机可读存储介质，其上存储有程序代码，其特征在于，该程序代码被处理器执行时实现权利要求1至8任意一项所述的api网关的动态配置方法的步骤。

技术总结

本申请公开了一种API网关的动态配置方法及装置，属于通信技术领域。所述方法应用于API网关，该方法包括：向目标服务端注册由所述API网关进行路由处理的Web服务；基于目标服务端发送的更新信息，从所述目标服务端获取所述更新信息对应的Web服务的服务配置信息，其中，所述Web服务为：由所述API网关进行路由处理，且预先在所述目标服务端注册服务配置信息的服务，所述更新信息是所述目标服务端在监听到所述Web服务注册的服务配置信息发生调整后生成的；根据获取的所述服务配置信息，更新所述API网关中存储的相应上行服务路由。该方法实现了实时根据Web服务的调整对API网关进行动态维护，提升了API网关的维护实时性和效率。提升了API网关的维护实时性和效率。提升了API网关的维护实时性和效率。