基于gateway网关实时生效的动态路由方法与流程

本实施例属于网络管理领域，尤其涉及基于gateway网关实时生效的动态路由方法。

背景技术：

随着微服务体系架构设计的流行，微服务网关的重要性越来越突出，主要体现在对后端众多微服务api的统一管理、访问控制、路由和负载均衡、日志记录以及服务间调用的监控等方面。目前网关路由规则的配置主要使用配置文件和从数据库读取两种方式，这两种方式的缺点主要体现在如下几方面：

1)路由规则事先在配置文件或数据库中写死，网关启动时，加载配置规则，实现对现有服务或系统的路由和负载均衡。但是随着业务复杂度的增长，路由规则的变化也将呈现不确定性，需要每次修改配置文件或数据库中的路由规则，并重启网关服务，这对系统的稳定性和可用性带来了非常大的挑战。

2)针对以上静态路由的缺点，市面上已有的动态路由解决方案主要是将网关本身作为微服务和业务微服务一同注册到注册中心，例如eurea，网关从注册中心获取各业务微服务实例进行路由。这种架构设计对于同构技术能够做到很好应用，但是对于异构甚至有灰度发布需求的场景，就很难满足。

技术实现要素：

为了解决现有技术中存在的缺点和不足，本实施例提出了基于gateway网关实时生效的动态路由方法，能够不影响网关系统的灵活性，能够满足异构系统的接入和灰度发布的要求，以应对企业日益复杂的业务和性能需求。

具体的，本实施例提出的基于gateway网关实时生效的动态路由方法，所述动态路由方法包括：

控制第一组件经第二组件从注册配置中心处获取相关元数据信息；

控制第一组件接收终端发出的服务请求，基于获取到的相关元数据信息将服务请求传输至第三组件，令第三组件基于预存储的服务实例将接收到的服务请求转发至后端服务体系中的具体服务器进行请求响应；

其中，所述相关元数据信息包括不同服务请求与异构系统的对应关系。

可选的，所述动态路由方法包括：

控制第三组件向注册配置中心发送服务注册请求；

从注册配置中心处接收基于注册请求发送的服务实例；

其中，所述服务实例包括不同服务请求与服务器的对应关系。

可选的，所述相关元数据信息包括不同服务请求与异构系统的对应关系。

可选的，所述动态路由方法还包括：

控制第一组件根据预存储的不同服务请求与异构系统的对应关系将接收到的服务请求转发至异构系统体系中的异构系统。

可选的，所述动态路由方法还包括：

定时监测后端服务体系中服务器的变化情况；

如果服务器出现变化，则将变化信息发送至注册配置中心进行变更注册。

本实施例提供的技术方案带来的有益效果是：

解决了网关在不重启的情况下，实现了网关路由规则的热加载，保证了网关的稳定性和可用性，满足实际生产中的业务和性能需求；同时另外一方面也解除了网关对接异构系统时需要强依赖某个组件(如注册中心)的限制，实现路由规则的灰度发布，进一步增强了网关灵活性、实用性和系统安全性。

附图说明

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

图1为本申请实施例提出的基于gateway网关实时生效的动态路由方法的流程示意图；

图2为本申请实施例提出的异构系统体系的结构示意图；

图3为本申请实施例提出的后端服务体系的结构示意图。

具体实施方式

为使本实施例的结构和优点更加清楚，下面将结合附图对本实施例的结构作进一步地描述。

实施例一

针对目前市面上主流网关加载路由策略的弊端，主要有：1)网关路由规则写死，无法动态加载，新配置路由规则如果要生效，需要重新启动网关服务，对系统稳定性和可用性造成极大隐患；2)强制使用服务注册中心，与网关进行强制绑定，无法在异构系统下使用，无法做到灰度发布，对系统侵入性较强，灵活性不够。

本实施例着力以解决以上两个问题为出发点，保障在不重启网关情况下，即实现网关路由规则的热加载，同时不影响网关系统的灵活性，能够满足异构系统的接入和灰度发布的要求，以应对企业日益复杂的业务和性能需求

具体的，本实施例提出的基于gateway网关实时生效的动态路由方法，如图1所示，所述动态路由方法包括：

11、控制第一组件经第二组件从注册配置中心处获取相关元数据信息；

12、控制第一组件接收终端发出的服务请求，基于获取到的相关元数据信息将服务请求传输至第三组件，令第三组件基于预存储的服务实例将接收到的服务请求转发至后端服务体系中的具体服务器进行请求响应；

其中，所述相关元数据信息包括不同服务请求与异构系统的对应关系，还包括确定服务请求中所必须的请求参数以及对服务请求进行转发的必要参数类型。

在实施中，从图1看到，本实施例关键的组件有第一组件hy-component-1、第二组件hy-component-2、第二组件hy-component-3。因此要实现本实施例的功能和能力，必须部署以上三个关键性组件。组件hy-component-1用于处理终端发送的请求，组件hy-component-1通过组件hy-component-2从注册配置中心获取相关元数据信息，组件hy-component-3负责内部微服务体系的功能路由，组件hy-component-3具体运作规则来自于注册配置中心。以上三个关键组件加上注册配置中心成功实现了网关的热加载和对接异构系统的能力。

第三组件hy-component-3必须与第二组件hy-component-2以及注册配置中心配置使用，具体运作模式基于第三组件hy-component-3接收第二组件hy-component-2的请求，根据注册配置中心规则，进行内部服务路由转发。

可选的，所述动态路由方法包括：

控制第三组件向注册配置中心发送服务注册请求；

从注册配置中心处接收基于注册请求发送的服务实例；

其中，所述服务实例包括不同服务请求与服务器的对应关系。

在实施中，第三组件用于实现将第一组件接收的到服务请求转发至对应的后端服务体系中具体服务器的过程转发。为了实现准确的转发，需要第三组件从注册配置中心处获取基于服务注册请求所接收到的服务实例。进而根据接收到的服务实例对后续服务请求进行转发。

可选的，所述动态路由方法还包括：

控制第一组件根据预存储的不同服务请求与异构系统的对应关系将接收到的服务请求转发至异构系统体系中的异构系统。

在实施中，如图2提出的异构系统体系的结构示意图所示，第一组件将接收到的服务请求根据预存储的对应关系转发至包括异构系统a、异构系统b、异构系统c、异构系统d的异构系统体系中具体的异构系统处，在异构系统完成服务请求的响应后，将得到的结果按原路径返回值发送服务请求的用户。

可选的，所述动态路由方法还包括：

定时监测后端服务体系中服务器的变化情况；

如果服务器出现变化，则将变化信息发送至注册配置中心进行变更注册。

在实施中，如图3提出的后端服务体系的结构示意图所示，如果包括服务器a、服务器b、服务器c、服务器d在内的后端服务体系中出现了结构变化，例如某台服务器崩溃或新增了服务器，此时借助定时监测服务器变化情况的方式就可以在第一时间已发送变化信息至注册配置中心的方式完成注册配置中心内后端服务体系的备份，从而满足接下来服务请求的正常响应。

本实施例成功解决了网关在不重启的情况下，实现了网关路由规则的热加载，保证了网关的稳定性和可用性，满足实际生产中的业务和性能需求；同时另外一方面也解除了网关对接异构系统时需要强依赖某个组件(如注册中心)的限制，实现路由规则的灰度发布，进一步增强了网关灵活性、实用性和系统安全性。

本实施例已实际投入到了企业的生产环境中，由于实现了网关的热加载、不强制依赖某特定组件以及灰度发布的功能，真正做到了性能和灵活性双重效果。具体效果如下几个方面，

1)从经济上讲，能够很好的对接企业中一些重要的，但是改造难度系数较大的系统，降低了企业改造旧系统成本，减少整个系统所需要依赖组件数量，降低运维成本；

2)从技术上讲，能够很好的兼容和集成开源社区中某些具有价值和前瞻性的技术项目，对推动提升企业运用先进技术的能力，具有重要的现实意义。

上述实施例中的各个序号仅仅为了描述，不代表各部件的组装或使用过程中的先后顺序。

以上所述仅为本实施例的实施例，并不用以限制本实施例，凡在本实施例的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本实施例的保护范围之内。