CN113726662A - 一种微服务路由及管理系统插件 - Google Patents

Abstract

一种微服务路由及管理系统插件，包括：微服务上报组件，用于对应用的启动进行监听，并在监听到应用启动时将微服务映射路径、微服务访问类型、微服务内容统一解析并封装为统一对象，并将对象上报；路由管理组件，用于提供暴露接口接收来自上报的对象，获取对象中的信息，根据获取的信息生成路由定义信息，并将路由定义信息存入Redis；网关组件，用于从Redis获取路由定义信息，并根据路由定义信息，生成路由以刷新路由，并更新到本地二级缓存中；本地二级缓存，用于缓存网关组件生成的路由，并用于在Redis不可用时，直接向gateway路由定位器提供用于加载的路由。与程序轻耦合，可插拔，解决服务注册、路由管理，能高效灵活的实现路由服务局部动态刷新问题。

Description

一种微服务路由及管理系统插件

技术领域

本发明属于计算机技术领域，尤其涉及一种微服务路由及管理系统插件。

背景技术

随着分布式项目的不断开发，微服务越来越多，各个微服务的接口也越来越多，调用越来越复杂。对这些接口的访问和一些功能，比如权限控制、流量控制、访问日志等，都需要统一网关来进行控制；而引入网关最基础的功能就是路由控制。由人工来控制这些路由显然是不合理的，这就需要开发可插拔的、可复用的、支持扩展的组件以提供这种支持，从而实现微服务路由的自动上报、集中管理、动态路由等功能。

目前，这方面的组件/插件存在以下缺陷：

1、不够组件化，如果有一处改动，代价比较大，且无法复用到其他项目；

2、实际业务中，路由刷新应该是少部分接口的操作，不会涉及到太多接口，这部分目前没有考虑按照微服务的分组模式来划分，以使得只要刷新就全部删除；并且网关服务一般是多实例运行，就意味着每次都要刷新路由，即使是刷新一两个，而每个网关实例都会把Redis中的路由信息全部删掉，然后再重建，显然没必要；

3、有些场景中路由操作依赖MQ的可靠性，经常会出现路由商店刷新路由，网关无响应的情况；

4、网关组件强依赖Redis，直接从Redis中加载路由，没有中间缓存，一旦Redis不可用，所有的路由将获取失败，将会对业务造成灾难性后果。

发明内容

针对上述相关现有技术不足，本发明提供一种微服务路由及管理系统插件，与程序轻耦合，可插拔，解决服务注册、路由，能高效灵活的实现路由服务局部动态刷新问题。

为了实现本发明的目的，拟采用以下方案：

一种微服务路由及管理系统插件，其特征在于，包括：

微服务上报组件，用于对应用的启动进行监听，并在监听到应用启动时将微服务映射路径、微服务访问类型、微服务内容统一解析并封装为统一对象，并将对象上报；

路由管理组件，用于提供一个暴露接口接收来自各个微服务上报组件上报的对象，并通过调用业务逻辑对上报的对象进行持久化处理，并用于通过服务刷新或全部刷新以获取对象中的信息，并根据获取的信息生成路由定义信息，并将路由定义信息存入Redis数据库；

网关组件，用于从Redis数据库获取路由定义信息，并根据路由定义信息，生成路由以刷新路由，并更新到本地二级缓存中；

本地二级缓存，用于缓存网关组件生成的路由，并用于在Redis数据库不可用时，直接向gateway路由定位器提供用于加载的路由；

所述Redis数据库连接至gateway路由定位器，Redis数据库订阅topic以从gateway路由定位器获取路由刷新事件并经常存储，以供网关组件获取。

网关组件，还用于根据预设时间间隔对服务存储介质进行扫描，以对服务存储介质中服务路由信息进行同步，通过识别是否新增服务，将路由信息和具体莹莹对应的服务信息数据进行封装，并对应更新到本地的缓存介质中。

其中，服务存储介质其实就是网关组件内部的缓存，或者说是Redis数据库为一级缓存，则其就是继Redis数据库后的二级缓存，即前面提及的本地二级缓存，它是网管组件内的缓存，存储的数据与Redis数据库里的一致。

本地的缓存介质就是网关服务内部的缓存。文中其它处称为二级缓存其实就是因为Redis数据库是第一层内存，即本地的缓存介质为Redis数据库。

而且Redis数据库是实时第一响应操作的上层缓存，所以网关自身的缓存就称为了二级缓存。二者关系是Redis数据库第一时间响应上报服务变更等操作，同时网管在订阅或根据预设时间间隔来拉取Redis数据库的服务路由信息，然后会存到本地缓存一份。因为本地缓存可以保证高可用，在Redis数据库有问题时任然能用本地存储的路由信息继续支持服务路由，同时调用本地缓存的性能更高。

路由管理组件，还用于根据当前上报对象的微服务内容生成摘要信息并作为版本号，并进行预存，并用于对每次上报对象的摘要信息与预存的版本号进行匹配，若均无匹配结果，则继续执行对上报对象的处理，若有匹配信息，则表明版本号未更改，属于重复上报，放弃执行对上报对象的处理。

还包括基础工具组件，用于实现系统插件公共的异常编码及说明，公共请求参数对象的定义及标准化，对http服务中对象头格式的封装，对资源信息进行统一的加密、版本生成，对WEB容器内应用接口信息进行读取。

进一步，本地二级缓存属于基础工具组件的一部分。

本发明的有益效果在于：

1、本方案的插件，各应用直接导入依赖，通过默认的约定或配置实现微服务的API自动上报、路由的管理和动态刷新功能；

2、本方案的插件减少了链路，提高了可靠性；

3、通过封装通用插件，减少项目开发的重复功能开发，提高开发效率，提高可用性。

附图说明

图1示出了本申请实施例的插件结构框图。

图2示出了本申请实施例的微服务上报组件上报流程图。

图3示出了本申请实施例的路由管理组件执行流程图。

图4示出了本申请实施例的网关执行流程图。

具体实施方式

为使本发明实施例的目的、技术方案和优点更加清楚，下面结合附图对本发明的实施方式进行详细说明，但本发明所描述的实施例是本发明一部分实施例，而不是全部的实施例。

本申请实施例提供一种微服务路由及管理系统插件，如图1所示，包括微服务上报组件、路由管理组件、网关组件、本地二级缓存。

微服务上报组件用于把应用中的服务接口都发布到路由管理组件中去，所以需要实现对应用启动的监听，在应用启动就绪时触发服务的上报功能。具体做法是在组件中实现对WEB容器启动类的监听，在启动就绪时触发组件内的服务上报方法；其次上报服务方法需要实现对所有的微服务映射路径、微服务访问类型、微服务内容等参数进行统一的解析并且封装成统一对象，对象主要是描述了当前应用对应的服务明细信息，通过上报服务发送到路由管理组件。

路由管理组件提供一个暴露的接口，来接收上报和刷新路由信息，接口中的处理逻辑由核心的路由管理组件来具体实现，其中的实现包含了四个功能项实现：

资源管理：实现对资源的添加、删除、版本的生成等操作。

资源刷新：实现对所有的资源进行刷新及对特定资源按定向更新。

资源注册：实现对当前应用的所有服务信息注册，通过对应的版本号来核实当前应用的服务资源，如果版本号没有改变则视为资源无变更，将不会执行资源的重复上报。

三方资源套件的适配：在上述默认的资源管理实现中也扩展了当前市面上使用较为广泛的服务资源管理组件的支持，将Nacos、Redis的资源管理操作进行了统一封装，直接兼容在这些第三方组件的资源管理，本方法默认为上报至Redis中进行管理，作为第一层缓存存储。

本地二级缓存作为基础工具组件的一部分，实现当前应用的服务资源信息在本地缓存中的存储，应对在一级缓存如果出现问题时，依然能进行服务资源获取的能力。

基础工具组件为公共方法、公共参数、公共对象等统一提供的工具，具体实现功能如下：

统一异常：该功能实现整体组件公共的异常编码及说明。

统一请求上下文对象：实现组件中涉及的公共请求参数对象的定义及标准

对象转换：实现对http服务中对象头格式的封装功能。

加密：实现对资源信息提供统一的加密、版本生成等功能

Web容器访问工具：实现对WEB容器内应用接口等信息的基本读取公共方法抽象。

网关组件实现资源管理、同步，以及路由的动态刷新管理。

具体如下：订阅Redis 的topic，监听路由信息变更，所有变更调用网关资源管理的资源加载方法来进行本地缓存存储介质的数据同步。

同时，实现启动定时任务，按照一定时间间隔来对当前服务存储介质进行扫描，用来对服务存储介质中服务路由信息进行同步，识别新增服务还是老服务，将路由信息和具体应用对应的服务信息数据进行封装，最后更新或全部更新到本地的缓存介质中。

使用maven，在pom文件中引入组件依赖包，即可自动加载插件

<dependency>

<groupId>com.xnky.soft.utils</groupId>

<artifactId>micro-service-api-plugin</artifactId >

<version>${micro-service-api-plugin.version}</version>

</dependency>

插件运行流程：

微服务API上报流程，如图2所示，通过微服务上报组件，即图中的微服务，收集当前服务下的API向路由管理服务上报。

路由管理组件服务执行流程，如图2所示：

暴露端点接受各微服务的API服务上报请求。

API服务上报可能由于某些原因产生多次重复上报，路由管理服务接受上报时，会判断当前服务上报的内容较上次上报的变更情况。具体做法是每次上报会根据API服务内容生成摘要信息作为版本号，每次上报时比对版本号，如果版本号未更改，将不会调用接下来的步骤。当然也提供了强制上报方法，忽略版本号比对。

由于API服务可能会涉及到一些业务操作，比如需要持久化和启用禁用等状态管理，这部份需要业务自己实现，处理API服务信息；业务操作后，刷新路由。支持按服务刷新和全部刷新。路由刷新步骤。当调用路由刷新方法时，从业务方获取API服务，这部分交给业务方实现。获取API服务后，根据一定格式，存入Redis中。

网关组件执行流程，如图3所示，Gateway网关即为网关组件，自动导入基于Redis的动态路由组件，路由管理服务修改Redis中的路由数据，网关这边动态刷新路由。如果Redis突然不可用，由于有本地二级缓存，那么网关失灵之前缓存的路由不受影响。

本实例提供的插件使用灵活，不对代码进行强侵入，不需要上报的接口可以进行相应的注解配置；上报流程简单化、增强化，采用两层缓存的设计来提供应用高可用的支撑；开放一些持久化、服务接口发现等接口，帮助其它服务管理应用场景进行个性化的改造操作；可以兼容现有Nacos、Redis 组件；可插拔，方便组件的使用和去除。

以上仅为本发明的优选实施例，并不表示是唯一的或是限制本发明。本领域技术人员应理解，在不脱离本发明的范围情况下，对本发明进行的各种改变或同等替换，均属于本发明保护的范围。

Claims (4)

1.一种微服务路由及管理系统插件，其特征在于，包括：

微服务上报组件，用于对应用的启动进行监听，并在监听到应用启动时将微服务映射路径、微服务访问类型、微服务内容统一解析并封装为统一对象，并将对象上报；

路由管理组件，用于提供一个暴露接口接收来自各个微服务上报组件上报的对象，并通过调用业务逻辑对上报的对象进行持久化处理，并用于通过服务刷新或全部刷新以获取对象中的信息，并根据获取的信息生成路由定义信息，并将路由定义信息存入Redis数据库；

网关组件，用于从Redis数据库获取路由定义信息，并根据路由定义信息，生成路由以刷新路由，并更新到本地二级缓存中；

本地二级缓存，用于缓存网关组件生成的路由，并用于在Redis数据库不可用时，直接向gateway路由定位器提供用于加载的路由。

2.根据权利要求1所述的微服务路由及管理系统插件，其特征在于，所述Redis数据库连接至gateway路由定位器，Redis数据库订阅topic以从gateway路由定位器获取路由刷新事件并经常存储，以供网关组件获取。

3.根据权利要求2所述的微服务路由及管理系统插件，其特征在于，网关组件还用于根据预设时间间隔对本地二级缓存当前服务存储介质进行扫描，以对本地二级缓存中服务路由信息进行同步，通过识别是否新增服务，将路由信息和具体应用对应的服务信息数据进行封装，并对应更新到Redis数据库本地的缓存介质中。

4.根据权利要求1所述的微服务路由及管理系统插件，其特征在于，路由管理组件还用于根据当前上报对象的微服务内容生成摘要信息并作为版本号，并进行预存，并用于对每次上报对象的摘要信息与预存的版本号进行匹配，若均无匹配结果，则继续执行对上报对象的处理，若有匹配信息，则表明版本号未更改，属于重复上报，放弃执行对上报对象的处理。

Images