CN109639572A - 路由管理方法、装置及微服务系统 - Google Patents

Abstract

本发明实施例提供一种路由管理方法、装置及微服务系统，该微服务系统包括SDS、API网关、微服务和代理网关，其中，API网关与SDS之间通过代理网关进行通信，代理网关用于动态管理微服务的API路由。通过代理网关的引入，将微服务、API网关和SDS形成的单网关架构变成了包含有微服务、API网关、SDS和代理网关的双网关架构，由于代理网关可随时起停，且只要有正常工作的进程存在，代理网关某些进程的起停不影响将API网关发送的请求转发到对应的微服务中，因此，使得各组件之间减少耦合，API路由的发现更新更灵活，解决现有微服务系统中存在的功能耦合严重，路由频繁更新影响正常业务请求等问题。

Description

路由管理方法、装置及微服务系统

技术领域

本发明实施例涉及微服务技术，尤其涉及一种路由管理方法、装置及微服务系统。

背景技术

当前流行的微服务系统包括微服务、提供微服务注册与发现的服务(ServiceDiscovery Service，简称：SDS)和应用程序编程接口(Application ProgrammingInterface，简称：API)网关。其中，微服务通过SDS获取另一微服务的API路由地址以实现微服务之间的通信，或者，微服务通过SDS和API网关，与另一微服务进行通信。无论微服务之间通过上述哪种方式进行通信，其核心为API路由的发现更新机制。

在上述微服务系统下，针对微服务的API路由的配置主要包括静态配置和动态配置。传统的API网关，例如Nginx是通过配置文件进行API路由的更新，具体地手动修改配置文件或者通过脚本程序修改配置文件，然后执行重新加载(reload)操作，重启worker进程。而当前流行API网关，例如OpenResty，由于在Nginx的核心基础上嵌入动态的Lua脚本语言支持，针对API路由的一些管理操作，例如重写统一资源标识符(Uniform ResourceIdentifier，简称：URI)、重定向等，可以通过Lua脚本去修改worker进程里的缓存数据，在无需重启worker进程的情况下，实行配置的动态热更新。

上述静态配置主要应用于简单、少量服务，在微服务要经常起停更新的场景下，路由频繁更新影响正常业务请求；另外，要实现动态热更新，微服务须借助SDS的帮助进行API路由的告知，功能耦合严重。

发明内容

本发明实施例提供一种路由管理方法、装置及微服务系统，以解决现有微服务系统中存在的功能耦合严重，路由频繁更新影响正常业务请求等问题，使得各组件之间减少耦合，API路由的发现更新更灵活。

第一方面，本发明实施例提供一种微服务系统，包括SDS、API网关、微服务和代理网关。其中，API网关与SDS之间通过代理网关进行通信，代理网关用于动态管理微服务的API路由。

第二方面，本发明实施例提供一种路由管理方法，应用于如第一方面所述的代理网关，该方法包括：采用预设模式，从SDS获取API路由信息，该预设模式包括拉取模式和推送模式；根据API路由信息，动态更新路由表中微服务的API路由。

第三方面，本发明实施例提供一种路由管理装置，应用于第一方面所述的代理网关，该装置包括：获取模块，用于采用预设模式，从SDS获取API路由信息，预设模式包括拉取模式和推送模式；更新模块，用于根据API路由信息，动态更新路由表中微服务的API路由。

第四方面，本发明实施例提供一种代理网关，包括：

存储器，用于存储程序指令；

处理器，用于执行所述程序指令来实现如第二方面所述的路由管理方法。

第五方面，本发明实施例提供一种计算机可读存储介质，其上存储有计算机程序，所述计算机程序被处理器执行时实现如第二方面所述的路由管理方法。

本发明实施例提供一种路由管理方法、装置及微服务系统，该微服务系统包括SDS、API网关、微服务和代理网关，其中，API网关与SDS之间通过代理网关进行通信，代理网关用于动态管理微服务的API路由。通过代理网关的引入，将微服务、API网关和SDS形成的单网关架构变成了包含有微服务、API网关、SDS和代理网关的双网关架构，由代理网关进行微服务的API路由的动态管理，由于代理网关可随时起停，且只要有正常工作的进程存在，代理网关某些进程的起停不影响将API网关发送的请求转发到对应的微服务中，因此，使得各组件之间减少耦合，API路由的发现更新更灵活，解决现有微服务系统中存在的功能耦合严重，路由频繁更新影响正常业务请求等问题。

附图说明

为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图做一简单地介绍，显而易见地，下面描述中的附图是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1为本发明实施例提供的微服务系统的一示意图；

图2为本发明实施例提供的代理网关的一结构示意图；

图3为本发明实施例提供的路由管理方法的一流程图；

图4为本发明实施例提供的代理网关的另一结构示意图；

图5为本发明实施例提供的代理网关的又一结构示意图。

具体实施方式

为使本发明实施例的目的、技术方案和优点更加清楚，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

需要说明的是，本发明实施例各部分及附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本发明的实施例能够以除了在这里图示或描述的那些以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。

本发明下述实施例所涉及的方法流程图仅是示例性说明，不是必须包括所有的内容和步骤，也不是必须按照所描述的顺序执行。例如，有些步骤还可以分解，而有些步骤可以合并或部分合并，因此，实际执行的顺序可根据实际情况改变。

本发明下述实施例所涉及的方框图中的功能模块仅仅是功能实体，不一定必须与物理上独立的实体相对应。即，可以采用软件形式实现这些功能实体，或在一个或多个硬件模块或集成电路中实现这些功能实体，或者不同网络和/或处理器和/或微控制器中实现这些功能实体。

首先，对本发明涉及的部分术语进行解释说明。

微服务(Micro Service)系统，是一种将单体应用拆分成多个细小(Micro)应用(即微服务)的架构。拆分后的每个微服务由于脱离单体应用进程的环境，微服务之间的彼此通信须依赖于SDS，微服务由SDS获得另一微服务的API路由地址，通过该API路由地址与另一微服务进行通信。具体地，每一个微服务在启动时，将自身的API路由地址变更信息注册到SDS中，并从SDS获得另一微服务API路由地址。

微服务之间的通信方式大约归类为以下两种：

1.直接通信方式。由SDS通过推送模式或者微服务通过拉取模式，将API路由信息通知到微服务，由微服务之间互相直连。

2.代理通信方式。每个微服务不需知道其它微服务的API路由地址，微服务的请求由API网关进行代理转发，API网关依赖于SDS去获取每一个微服务的API路由信息，并进行请求转发到对应的另一微服务中。

其中，推送模式是指由SDS通调用API网关集群结点提供的通用网关接口(CommonGateway Interface，简称：CGI)进行配置有更新告知。拉取模式是指由API网关定时去SDS检查是否有配置更新，如果有则拉取最新的配置内容进行更新。

例如，目前OpenResty从流行的consul中获取配置更新状态就是启动由Lua语言编写的插件consul-template，定时去检查consul中的API路由状态，采取的就是拉取模式。而基于OpenResty进行二次开发的Kong则采用推送模式和拉取模式的结合方式，通过提供配置操作的CGI或者管理后台，可以由开发人员在后台操作或者由其它服务调用进行CGI调用告知某一AIP网关结点服务的配置更新并且写数据库，这种是推送模式；再由其它结点定时从数据库中拉取配置状态，如有更改，则将数据库配置同步到结点的内存中。

不管是推送模式还是拉取模式，对于整个包含多个结点(即微服务)的API网关集群来说，每一个更新都必须要通知到集群的每一个结点。这意味着如果采用拉取模式，则每个结点都须定时从SDS拉取最新的配置状态。如果全部采用推送模式，则SDS须依次调用每个结点提供的配置更新接口进行告知。

另外，不管是推送模式还是更新模式，还需要根据自身的需求对API网关进行二次的插件开发，利用开源网关架构暴露出来的外部调用方式，完成从SDS获取API路由变更的功能。但API网关受限于框架的设计和语言限制，在此基础上进行二次开发受限制较大且过于复杂。由于API网关受限于特定的语言，如Nginx须c语言，OpenResty只能c语言或者Lua语言，这要求开发人员必须非常熟悉API网关的源码，并且对插件的开发非常熟悉。另外，插件开发的难度也较大，大部分框架提供的调试测试机制很不友好，对于线上问题很难跟踪定位。网关层作为接入层，要求稳定可靠，二次开发的插件须要提供高可靠的稳定性，否则会影响整个应用。

再者，不管是拉取模式还是推模式，都各有利弊。以下针对单网关架构下微服务的API路由配置的更新，先从实际生产的环境中出来，根据微服务的API路由更新的频率进行分析，做以下两大归类，如表1所示：

表1

经常更新对应的场景是众多微服务的版本迭代更新。每一个微服务的重启都会有一次微服务API路由的上下线操作。大中型的微服务系统下，微服务数量众多，版本迭代快速，就会引起API网关要经常性对路由表做增删操作。如果采用推送模式告知每个结点进行更新，就会导致频繁调用每个结点的HTTP接口，对于N个结点+M个更新服务进程的生产场景，就会产生N*M次HTTP接口调用，而一旦某个调用发生阻塞，就会造成本次API路由更新失败或者API路由配置错误。并且对于是否正确配置也很难做结果的判定和修正重试。因此，采用推送模式的API路由的发现更新机制不适用于需要经常更新的场景，这种场景下采用拉取模式更合适，并且拉取的定时时间间隔造成的延时对于微服务上下线的路由请求影响较小。

偶尔更新对应的场景是后台对微服务的API路由进行运维的操作，一般是对微服务进行限流，重定向，重写，或者偶尔处理突发性情况等。这种操作频率不高，更新次数少，此模式下更适合采用推送模式。

综上，在单网关的微服务系统下，不管是API路由从SDS的推送模式还是API路由定时从SDS的拉取模式，都存在着以下问题：

1)API网关需要提供对路由表更新的频繁处理；

2)拉取模式要求在现有的API网关上做二次定制开发，受限于框架本身，限制较多；

3)推送模式要求API网关提供API路由更新的接口，需要在SDS上做二次开发，调用API网关提供的接口；

4)没有按照API路由的更新频率作区分，推送模式下频繁进行API路由更新影响正常业务请求；

5)功能模块耦合，API网关和SDS、微服务之间耦合严重，API网关的功能太重；

6)对API网关进行深度扩展会严重受限于框架，灵活度不高，二次开发难度较高且不易维护。

因此，本发明基于微服务的API路由的发现更新机制，提供一种双网关架构，在微服务，SDS，API网关所形成的单网关架构的基础上引入代理网关，以此来解决当前单网关架构下存在的功能耦合严重，路由频繁更新影响正常业务请求等问题，使得各组件之间减少耦合，API路由的发现更新更灵活。

如图1所示，本发明实施例提供一种微服务系统10，包括：SDS 11、API网关12、微服务13，以及代理网关14。其中，API网关12与SDS 11之间通过代理网关14进行通信，代理网关14用于动态管理微服务13的API路由。可以理解，SDS 11、API网关12、微服务13、代理网关14，的个数为至少一个。

通过微服务系统10，将现有单网关架构中API网关的功能进行分解，其中一部分功能由代理网关14实现，这部分功能包括动态管理微服务13的API路由。代理网关14作为API网关12的上游，通过把这部分功能从现有单网关架构中API网关中抽离出来，减轻API网关12的功能负重，降低了SDS 11与API网关12之间的耦合性和关联性，提高整个微服务系统二次开发的灵活性。

其中，代理网关主要功能包括：

一、采用拉取模式，定时从SDS拉取API路由的状态，避免API网关的频繁更新；

二、拉取模式功能只需要在代理网关开发，不受语言框架限制；

三、推送模式功能只需要在代理网关开发，不受语言框架限制；

四、区分API路由的更新频率，由代理网关处理微服务的API路由经常更新的场景，由API网关处理微服务的API路由偶尔更新的场景；

五、解耦功能模块，将常用的API路由管理功能由API网关承担，将需要二次开发或者跟业务强相关的功能由代理网关承担；

六、解决原API网关框架的受限问题，代理网关的开发根据喜好可以任何语言开发，不受其它限制；

七、简化插件的开发，通过提供便利的插件开发方法，使得代理网关更加容易做功能扩展，灵活定制。

通过代理网关的引入，将微服务、API网关和SDS形成的单网关架构变成了包含有微服务、API网关、SDS和代理网关的双网关架构。在实际应用中，请求从API网关12转发到代理网关14，由代理网关14根据SDS11提供的API路由信息，将请求转发到对应的微服务13中。

本发明的代理网关作为某些功能的承载体，对于形成双网关架构在功能上是有共同性的。也就是说，无论使用什么语言或者工具或者框架，代理网关要符合以下几个特性：

代理网关中进程无状态，可随时起停；

只要还有正常工作的进程存在，代理网关中某些进程的起停不影响将API网关发送的请求转发到对应的微服务中；

代理网关作为API网关的上游，代理网关中每个进程的负载均衡在API网关中配置；

代理网关不受限于任何开发语言，只要能满足基本的代理请求功能即可；

代理网关中每个进程维护一份微服务的路由表，定时从SDS拉取最新API路由信息来更新进程维护的路由表；

API网关是第一层网关入口，负责常用的API路由管理方法；代理网关作为第二层网关入口，负责复杂、特定的、需要二次开的API路由管理方法。

为实现上述功能，接下来通过具体实施例进行说明。

对于配置加载，代理网关14可具体用于：读取配置文件；根据配置文件，完成配置的加载；生成线程，该线程用于监听配置文件的变化以及配置的重载。其中，配置文件是配置服务运行的一些配置项。示例性地，配置文件可以支持json或者yaml配置格式。

可选地，按照功能划分，上述配置可包括以下至少一项：

超文本传输协议(Hyper Text Transfer Protocol，简称：HTTP)代理模块配置，其中，HTTP代理模块用于将API网关12的请求转发到微服务13，以及将微服务13的响应转发到API网关12；

服务发现管理模块(Service Discovery Manager，简称：SDM)配置，其中，SDM用于从SDS 11中获取微服务13的API路由信息，并更新路由表；

插件模块配置，其中，插件模块用于实现预设功能需求；

监测模块配置，其中，监测模块用于监控并汇报微服务13的运行状态，该运行状态可以包括路由总数，处理器使用状态和端口使用状态等；

HTTP API相关配置，包括提供各个组件的HTTP接口。

示例性地，监测模块可将上述运行状态汇报给监控系统或管理人员等。可选地，监测模块负责统计汇报，收集与分析操作由使用方根据自身业务的需要进行。

可选地，HTTP代理模块配置可以包括以下至少一项：

配置要监听的网络协议(Internet Protocol，简称：IP)地址和端口；

HTTP请求头读取超时时间；

HTTP请求内容读取超时时间；

HTTP响应内容写超时时间；

传输控制协议(Transmission Control Protocol，简称：TCP)长连接时间设置；

等等。

例如，表2示出各HTTP代理模块配置及其对应的配置名。

表2

配置名	配置说明
		listen	配置要监听的IP地址和端口
ht(header timeout)	HTTP请求头读取超时时间
		rt(read timeout)	HTTP请求内容读取超时时间
wt(write timeout)	HTTP响应内容写超时时间
		KeepAlive	TCP长连接时间设置

SDM配置可以包括以下至少一项：

服务发现的模式，该模式包括本地配置文件模式和分布式服务注册组件模式；

SDS提供获取API路由信息的接口统一资源定位符(Uniform Resource Locator，简称：URL)，其中，API路由包括URL；

SDS响应超时时间。

例如，表3示出各SDM配置及其对应的配置名。

表3

插件模块配置可以包括是否启用插件等。

在完成配置加载之后，进一步地，代理网关14还可以用于：读取静态API路由文件，该静态API路由文件包括API路由信息；根据API路由信息，完成API路由的加载。

可选地，API路由信息可以包括：API路由的标识，API路由对应的统一资源标识符(Uniform Resource Identifier，简称：URI)，URI对应的权重；URI对应的至少一标签和目的地址等。其中，当URI相同时，优先将请求转发到权重更高的API路由提供的目的地址中。

静态API路由文件与配置文件不同，静态API路由文件配置的路由优先级高于SDS提供的动态路由。静态API路由文件的每一行为一个API路由，按行进行分隔。示例性地，对于API路由的定义可以为API ROUTE＝{MARK}.{URI}.{WEIGHT}.{TAG}.{DEST}共5段，其中每个字段的含义定义如下：

其中，API路由的MARK字段表示惟一的路由，MARK字段是根据具体的需求具体生成，MARK字段不能为空。WEIGHT字段用来表示在当URI相同时，优先将请求转发到WEIGHT更高的API路由提供的DEST中。针对配置多个目的地址，代理网关14可支持不同的负载均衡算法。其中，该负载均衡算法可以包括以下至少一个：按目的地址对应的权重进行优先转发模式，随机转发模式以及轮询转发模式，等等。例如，weight表示按DEST对应的权重进行优先转发模式，random表示随机转发模式，round-robin表示轮询转发模式。

可选地，代理网关14还可以用于：在根据静态API路由文件，完成API路由的加载之后，生成路由表。其中，路由表例如表示为：

需说明的是，在路由表中，通过静态API路由文件加载的API路由对应有静态标签。具体地，在完成对静态API路由文件的加载后，对路由表进行初始化，并且对所有的静态API路由文件加载的路由打上静态标签“static”。

当从SDS加载动态路由时，如果发现某个路由跟静态API路由文件配置的路由URI重复，则优先使用静态路由，重复的动态路由将被丢弃掉。为了解决不同的SDS提供路由信息格式不一致问题，SDM通过对路由进行统一的定义，通过对不同SDS的兼容模块，提供通用的路由封装操作。

一些实施例中，代理网关14可以包括配置加载模块，上述实施例中所涉及的操作均有配置加载模块实现。这些操作例如包括：读取配置文件；根据配置文件，完成配置的加载；生成线程，该线程用于监听配置文件的变化以及配置的重载；读取静态API路由文件，该静态API路由文件包括API路由信息；根据API路由信息，完成API路由的加载；生成路由表。

对于从SDS加载动态路由的情况，代理网关14还可以用于：从SDS获取API路由信息；根据该API路由信息，动态更新路由表中微服务的API路由。

一种实现方式中，代理网关14可具体用于：采用预设模式，从SDS获取API路由信息。其中，预设模式可以包括拉取模式和推送模式。

具体地，代理网关14具体用于：启动SDM线程，该SDM线程用于采用预设模式，定时从SDS获取API路由信息；将从SDS获取的API路由信息与当前的路由表映像进行比较；根据比较结果，动态更新路由表中微服务的API路由。

其中，在路由表中，从SDS获取的API路由信息对应的API路由，对应有动态标签。例如，每个API路由信息将会打上“dynamic”标签。

另外，静态API路由文件配置的API路由的优先级高于，从SDS获取的API路由信息对应的API路由的优先级。

可选地，代理网关14可以包括SDM，该SDM用于执行上述从SDS获取API路由信息；根据该API路由信息，动态更新路由表中微服务的API路由，等等。

例如，SDM从配置的SDS中主动拉取所有的API路由信息，并将API路由信息写入路由表中。其中，对于跟静态API路由文件中重复的路由将直接摒弃掉，同时启动SDM线程，定时从SDS拉取API路由信息，并跟当前的路由表映像做比较，把增减某个路由事件写入镜像路由表中，在完成后统一对主进程维护的路由表进行内存整体替换，改变路由表的内存指向，并释放旧路由表内容，避免进程内存泄露。

一些实施例中，上述配置包括启动插件的配置。此时，代理网关14还包括：第一插件，该第一插件，用于读取完整HTTP请求报文，和/或，读取完整HTTP响应报文。

例如，代理网关14还包括插件模块，该插件模块根据配置加载模块所加载的配置确定是否启用插件。对于插件的设计，本发明实施例不同于现有技术中API网关中插件的设计，具体地：现有技术中API网关在多个HTTP处理的请求阶段提供例如URI重写，重定向，限速，限IP等工作；但代理网关的插件只能工作在读取完整HTTP请求报文，读取完整HTTP响应报文两个阶段。通过这样的设计，保证代理网关的插件的实现更加简单方便，只需对HTTP请求/相应做处理；代理网关跟现有API网关的不同可表现为代理网关更轻，更偏向业务开发，对HTTP的处理只在应用层面做，减轻插件的开发难度；同时，也降低底层HTTP代理的开发难度。

而基本的这些API路由管理，尤其是涉及到TCP包体读取流程过程中的，应该由API网关来完成，例如IP限制，请求头报文检验等。通过这样设计可以使用插件开发不用入侵HTTP代理模块读取数据流的过程。

代理网关对插件工作的阶段进行划分，插件工作在以下两个阶段：

1.请求Request阶段,即读取完整的API网关转发的HTTP请求报文。

2.请求Response阶段，即读取完微服务的完整HTTP响应报文。

示例性地，要实现一个插件，需实现init(),process_request(),process_response()三个函数。具体地，初始化函数init(config,weight,ctx)，config参数是配置加载模块对象，提供配置内容读取，weight是表示插件的权重，决定了插件在本阶段被调用的顺序，ctx是跟请求绑定的上下文对象，ctx贯穿整件请求对象的生命周期。在实现自定义的插件的时，可以利用ctx来保存全局状态。process_requests(request)函数，用于处理HTTP请求报文，返回处理后的request对象。process_response(response)函数，用于处理HTTP响应报文。

可选地，代理网关可自带两个固定的插件：日志插件，用于提供日志记录；和/或，过滤插件，用于对HTTP响应报文进行报文压缩处理，等等。其中，过滤插件的权重可以是最低的，在调用完所有插件的process_response()函数后，再调用过滤插件进行标准HTTP响应报文进行报文压缩，其中报文压缩可默认是gzip压缩方法，但本发明实施例不以此为限制。

由于代理网关14是自主开发的，因此可以根据自身的需要开发支持不同的插件内容，相比现有的单网关架构提供的定制功能来说，双网关架构具有更大的灵活性。

进一步地，上述实施例提及代理网关14可包括：配置加载模块21、HTTP代理模块22、SDM 23、插件模块24、监测模块25和HTTP接口26等，如图2所示。当配置加载模块、SDM、插件模块和监测模块等都启动后，最终启动HTTP代理模块，监听指定的端口地址，接收来自API网关的HTTP请求报文。其中，HTTP代理模块在所有的功能模块初始化好后才启动。由于代理网关14提供的插件并不入侵HTTP请求报文的读取中间过程，只有HTTP代理模块读取完一个完整的HTTP请求报文后再调用插件的处理函数，相比于当前开源的API网关，从整体上减少代理网关开发的复杂性，同时保证简浩性；进一步地，为了保证代理网关的高性能，处理TCP请求采用输入输出(in-out，简称：IO)复用Epoll模式，保证单进程的处理能力。

基于上述内容，在本发明实施例中，API网关与代理网关共同管理微服务的API路由，其中，代理网关用于管理更新频率大于或等于预设频率的API路由；API网关用于管理更新频率小于预设频率的API路由。至于预设频率的大小，可根据实际情况进行设置，对此不进行限制。

另需说明的是，代理网关中各进程的负载均衡是在API网关中配置的。

示例性地，在实际应用中，在启动之后，代理网关加载配置文件、加载静态API路由文件、初始化路由表、从SDS加载API路由信息、加载插件模块、启动监测模块、启动HTTP代理模块，之后，代理网关根据路由表，处理报文，包括HTTP请求报文和HTTP响应报文。具体地，代理网关接收API网关发送的HTTP请求报文，并按照权重从大到小的顺序依次调用插件的process_requests()函数，将HTTP请求报文转发至微服务，之后，接收微服务反馈的HTTP响应报文，并按照权重从大到小的顺序依次调用插件的process_response()函数，调用过滤插件进行gzip压缩，最后，发送HTTP响应报文给API网关。

本发明实施例利用API网关和代理网关构成的双网关架构，有效地解决传统单网关架构中面临的一些问题，其中包括：

解除开发语言的限制，代理网关可以利用任何语言进行开发，解决在传统的API网关上开发功能时受API网关本身开发语言的限制，如Nginx(C语言)，OpenResty(Lua)，Envoy(C++)等。开发团队可以根据团队的具体情况，灵活选择合适的开发语言；

解耦系统模块之间依赖，SDS的更新只须通知代理网关，不需要通知API网关，解决API网关由于SDS的频繁更新导致API网关经常性做重载操作，导致正常的业务请求受到影响的问题；

提供深度的定制功能和增强架构的灵活性，传统的API网关由于框架巨大、功能复杂且提供的定制入侵深度不够，要基于传统的API网关定制功能，解决业务上的痛点会受限于框架，大多数情况下实施困难。通过增加代理网关，在保证基本的请求转发代理的功能基础上，还可以对代理网关进行全方面的定制开发，从而满足自身的要求；

层级角色分离，API网关作为请求的第一层，负责常规的一些API路由的管理，如限流，URL重定向重写，授权，负载均衡等。而代理网关作为请求的第二层，可以承担更加复杂的功能需求，对于进来的请求结合业务做二次的降级，限流，分流，智能负载等功能。

本发明实施例还提供一种路由管理方法，应用于如上述任一实施例所述的代理网关。其中，路由管理方法的具体实现可参考上述实施例，此处不再赘述，只做简单的步骤说明。

如图3所示，该路由管理方法，包括：

S301、采用预设模式，从SDS获取API路由信息。

其中，预设模式包括拉取模式和推送模式。

S302、根据API路由信息，动态更新路由表中微服务的API路由。

该实施例主要涉及对API路由的动态更新。

其中，S301、采用预设模式，从SDS获取API路由信息，可以包括：启动SDM线程，该SDM线程用于采用所述预设模式，定时从SDS获取API路由信息。

进一步地，S302、根据API路由信息，动态更新路由表中微服务的API路由，可以包括：将从SDS获取的API路由信息与当前的路由表映像进行比较；根据比较结果，动态更新路由表中所微服务的API路由。

可选地，在S302、根据API路由信息，动态更新路由表中微服务的API路由之前，该路由管理方法还可以包括：

读取配置文件；根据配置文件，完成配置的加载；生成线程，该线程用于监听配置文件的变化以及配置的重载。该实施例主要涉及对API路由的静态配置。

可选地，所述生成线程之后，该路由管理方法还可以包括：读取静态API路由文件，静态API路由文件包括API路由信息；根据API路由信息，完成API路由的加载。

可选地，在所述根据静态API路由文件，完成API路由的加载之后，该路由管理方法还可以包括：生成路由表。

本发明实施例提供一种路由管理装置，应用于如上述任一实施例所述的代理网关。其中，路由管理装置用于执行上述路由管理方法，其功能和实现原理可参考上述实施例，此处不再赘述，只做示例的说明。

如图4所示，该路由管理装置40，包括：获取模块41和更新模块42。其中，获取模块41，用于采用预设模式，从SDS获取API路由信息，该预设模式包括拉取模式和推送模式。更新模块42，用于根据API路由信息，动态更新路由表中微服务的API路由。

本实施例的路由管理装置，可以执行上述方法实施例中涉及的步骤，其实现原理和技术效果类似，在此不再赘述。

参考图5，本发明实施例提供一种代理网关50，包括：

存储器51，用于存储程序指令；

处理器52，用于执行所述程序指令来实现如上任一路由管理方法。

其中，存储器51与处理器52之间可通过总线53进行连接，但本发明实施例不以此为限制。

本实施例的代理网关，可以执行上述方法实施例中涉及的步骤，其实现原理和技术效果类似，在此不再赘述。

补充说明的是，图5仅为代理网关的一种简单设计，本发明实施例不限制代理网关中处理器、存储器等的个数。且，可选地，除图4所示的元件，代理网关还可以包含其他元器件。

本发明实施例提供一种计算机可读存储介质，其上存储有计算机程序，该计算机程序被处理器执行时实现如上任一路由管理方法，其具体实现及有效效果，可参见上述，在此不再赘述。

本领域普通技术人员可以理解：实现上述各方法实施例的全部或部分步骤可以通过程序指令相关的硬件来完成。前述的计算机程序可以存储于一计算机可读取存储介质中。该程序在执行时，执行包括上述各方法实施例的步骤；而前述的存储介质包括：只读内存(Read-Only Memory，ROM)、随机存取存储器(Random Access Memory，RAM)、磁碟或者光盘等各种可以存储程序代码的介质。

最后应说明的是：以上各实施例仅用以说明本发明的技术方案，而非对其限制；尽管参照前述各实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分或者全部技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本发明各实施例技术方案的范围。

Claims (27)

1.一种微服务系统，包括提供微服务注册与发现的服务SDS、应用程序编程接口API网关和微服务，其特征在于，所述微服务系统还包括：代理网关；

其中，所述API网关与所述SDS之间通过所述代理网关进行通信，所述代理网关用于动态管理所述微服务的API路由。

2.根据权利要求1所述的微服务系统，其特征在于，所述代理网关，具体用于：

读取配置文件；

根据所述配置文件，完成配置的加载；

生成线程，所述线程用于监听所述配置文件的变化以及配置的重载。

3.根据权利要求2所述的微服务系统，其特征在于，所述配置包括以下至少一项：

超文本传输协议HTTP代理模块配置，HTTP代理模块用于将所述API网关的请求转发到所述微服务，以及将所述微服务的响应转发到所述API网关；

服务发现管理模块SDM配置，SDM用于从所述SDS中获取微服务的API路由信息，并更新路由表；

插件模块配置，插件模块用于实现预设功能需求；

监测模块配置，监测模块用于监控并汇报所述微服务的运行状态，所述运行状态包括路由总数，处理器使用状态，端口使用状态；

HTTP API相关配置，包括提供各个组件的HTTP接口。

4.根据权利要求3所述的微服务系统，其特征在于，所述HTTP代理模块配置包括以下至少一项：

配置要监听的网络协议IP地址和端口；

HTTP请求头读取超时时间；

HTTP请求内容读取超时时间；

HTTP响应内容写超时时间；

传输控制协议TCP长连接时间设置。

5.根据权利要求3所述的微服务系统，其特征在于，所述SDM配置包括以下至少一项：

服务发现的模式，所述模式包括本地配置文件模式和分布式服务注册组件模式；

SDS提供获取API路由信息的接口统一资源定位符URL；

SDS响应超时时间。

6.根据权利要求2至5中任一项所述的微服务系统，其特征在于，所述代理网关，还用于：

读取静态API路由文件，所述静态API路由文件包括API路由信息；

根据所述API路由信息，完成API路由的加载。

7.根据权利要求6所述的微服务系统，其特征在于，所述API路由信息包括：

API路由的标识，API路由对应的统一资源标识符URI，URI对应的权重；URI对应的至少一标签和目的地址；

其中，当URI相同时，优先将请求转发到权重更高的API路由提供的目的地址中。

8.根据权利要求7所述的微服务系统，其特征在于，针对配置多个目的地址，所述代理网关支持不同的负载均衡算法，所述负载均衡算法包括以下至少一个：

按目的地址对应的权重进行优先转发模式，随机转发模式以及轮询转发模式。

9.根据权利要求6所述的微服务系统，其特征在于，所述代理网关，还用于：

在所述根据所述静态API路由文件，完成API路由的加载之后，生成路由表。

10.根据权利要求9所述的微服务系统，其特征在于，在所述路由表中，通过所述静态API路由文件加载的API路由对应有静态标签。

11.根据权利要求1所述的微服务系统，其特征在于，所述代理网关，还用于：

从所述SDS获取API路由信息；

根据所述API路由信息，动态更新路由表中所述微服务的API路由。

12.根据权利要求11所述的微服务系统，其特征在于，所述代理网关，具体用于：

采用预设模式，从SDS获取API路由信息；

其中，所述预设模式包括拉取模式和推送模式。

13.根据权利要求12所述的微服务系统，其特征在于，所述代理网关，具体用于：

启动SDM线程，所述SDM线程用于采用所述预设模式，定时从所述SDS获取API路由信息；

将从所述SDS获取的API路由信息与当前的路由表映像进行比较；

根据比较结果，动态更新路由表中所述微服务的API路由。

14.根据权利要求11所述的微服务系统，其特征在于，在所述路由表中，从所述SDS获取的API路由信息对应的API路由，对应有动态标签。

15.根据权利要求6所述的微服务系统，其特征在于，所述静态API路由文件配置的API路由的优先级高于，从所述SDS获取的API路由信息对应的API路由的优先级。

16.根据权利要求3所述的微服务系统，其特征在于：

所述配置包括启动插件的配置；

所述代理网关，还包括：第一插件；

所述第一插件，用于读取完整HTTP请求报文，和/或，读取完整HTTP响应报文。

17.根据权利要求3所述的微服务系统，其特征在于，所述代理网关，还包括：

日志插件，用于提供日志记录；

和/或，过滤插件，用于对HTTP响应包进行报文压缩处理。

18.根据权利要求1所述的微服务系统，其特征在于，所述API网关与所述代理网关共同管理所述微服务的API路由；

其中，所述代理网关用于管理更新频率大于或等于预设频率的API路由；所述API网关用于管理更新频率小于所述预设频率的API路由。

19.根据权利要求1所述的微服务系统，其特征在于，所述代理网关中各进程的负载均衡是在所述API网关中配置的。

20.根据权利要求1所述的微服务系统，其特征在于，所述代理网关中每个进程维护一份微服务的路由表，所述路由表包括所述API路由。

21.一种路由管理方法，其特征在于，应用于如权利要求1至20中任一项所述的代理网关，所述方法包括：

采用预设模式，从所述SDS获取API路由信息，所述预设模式包括拉取模式和推送模式；

根据所述API路由信息，动态更新路由表中所述微服务的API路由。

22.根据权利要求21所述的方法，其特征在于，所述采用预设模式，从所述SDS获取API路由信息，包括：

启动SDM线程，所述SDM线程用于采用所述预设模式，定时从所述SDS获取API路由信息。

23.根据权利要求22所述的方法，其特征在于，所述根据所述API路由信息，动态更新路由表中所述微服务的API路由，包括：

将从所述SDS获取的API路由信息与当前的路由表映像进行比较；

根据比较结果，动态更新路由表中所述微服务的API路由。

24.根据权利要求21所述的方法，其特征在于，在所述路由表中，从所述SDS获取的API路由信息对应的API路由，对应有动态标签。

25.一种路由管理装置，其特征在于，应用于如权利要求1至20中任一项所述的代理网关，所述装置包括：

获取模块，用于采用预设模式，从所述SDS获取API路由信息，所述预设模式包括拉取模式和推送模式；

更新模块，用于根据所述API路由信息，动态更新路由表中所述微服务的API路由。

26.一种代理网关，其特征在于，包括：

存储器，用于存储程序指令；

处理器，用于执行所述程序指令来实现如权利要求21至24中任一项所述的路由管理方法。

27.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现如权利要求21至24中任一项所述的路由管理方法。