CN112311869A - 多类型微服务注册中心管理系统及方法 - Google Patents

Abstract

本发明公开了一种多类型微服务注册中心管理系统，包括注册中心、各微服务注册中心和各应用服务，各应用服务与微服务注册中心的注册业务按照原协议保持通信，注册中心包括服务端和客户端，服务端用于提供服务信息和路由注册接口，缓存、分发服务和接口信息，服务端支持与客户端通信；客户端通过提供SDK，各微服务注册中心和各应用服务集成SDK与注册中心通信、上报或订阅信息。本发明通过注册中心将各应用服务与各微服务注册中心进行整合，能够实现服务监控、负载均衡及API路由的统一管理和维护，而且本发明注册中心不会干涉各应用服务与微服务注册中心原有的通信协议，无侵入性，耦合度低，便于对接，可以根据实际需求进行配置，使用灵活。

Description

多类型微服务注册中心管理系统及方法

技术领域

本发明涉及微服务注册中心管理技术领域，尤其涉及一种多类型微服务注册中心管理系统及方法。

背景技术

随着微服务技术的普及，在SpringCloud和Dubbo框架中都有自己的注册中心，如Eureka、Consul、Nacos、Zookeeper。注册中心是微服务架构中非常重要的一个组件，注册中心在微服务架构中主要起到了协调者的作用。例如注册中心一般包含如下几个功能：1)服务发现：服务注册/反注册、服务订阅/取消订阅和服务路由(可选)；2)服务配置：配置订阅和配置下发；3)服务健康检测。

目前市面上大多数公司使用的微服务架构有好几种，每个团队和项目使用的微服务架构都是不一样的，例如被普遍使用的SpringCloud和Dubbo这两种微服务架构，每种微服务架构都有自己的注册中心，因此每个团队或者项目都需要单独维护或者管理自己的注册中心，从而存在多类型的注册中心极难统一管理的问题，导致在提供第三方服务的时候，服务监控、负载均衡及Dubbo、API路由等管理就变得非常的艰难，无法实现多类型微服务注册中心的整合。

因此，如何对多类型微服务注册中心进行统一维护和管理，是现在亟待解决的问题。

发明内容

为了解决现有技术无法对多类型微服务注册中心进行统一维护和管理的问题。本发明的一个目的是提供一种多类型微服务注册中心管理系统，包括注册中心、各微服务注册中心和各应用服务，各应用服务与微服务注册中心的注册业务按照原协议保持通信，所述注册中心包括：

服务端，所述服务端用于提供服务信息和路由注册接口，缓存、分发服务和接口信息，服务端支持与客户端通信；以及

客户端，所述客户端通过提供SDK，各微服务注册中心和各应用服务集成SDK与注册中心通信、上报或订阅信息。

采用以上技术方案，所述注册中心包括公共组件，所述公共组件用于提供并维护基础指令，以及公共组件提供多种负载均衡策略，客户端在调用API时，从本地缓存获取对应列表，调用负载均衡策略获取目标地址进行服务调用。

采用以上技术方案，所述注册中心包括服务端核心组件，所述服务端核心组件用于缓存数据，以及在服务上下线时，服务端核心组件用于即时剔除、告警以及通知订阅者。

采用以上技术方案，所述服务端包括后端和前端两个模块：

后端提供客户端的注册接口、页面管理的注册服务、服务列表及负载均衡的配置、API列表及API接口；

前端通过调用API接口进行页面展示。

本发明的另一目的是提供一种多类型微服务注册中心管理方法，包括如下内容：

各应用服务与微服务注册中心的注册业务按照原协议保持通信；

部署服务端，提供服务信息和路由注册接口，缓存、分发服务和接口信息，服务端支持与客户端通信；

通过配置服务端地址，调用接口注册服务信息和路由信息，各微服务注册中心和各应用服务集成SDK与注册中心通信、上报或订阅信息。

采用以上技术方案，所述服务端包括后端和前端两个模块：

后端提供客户端的注册接口、页面管理的注册服务、服务列表及负载均衡的配置、API列表及API接口；

前端通过调用API接口进行页面展示。

采用以上技术方案，所述各微服务注册中心和各应用服务集成SDK与注册中心通信、上报或订阅信息包括：

客户端根据SDK包通过配置文件配置服务端地址、API路由管理包路径及订阅服务名称；

服务启动成功后会自动连接到指定的服务端，向服务端注册本服务信息；

拉取订阅服务信息，并缓存订阅服务信息及API信息到本地；

开启服务心跳，维护服务间的心跳；

暴露服务的相关状态接口，方便服务端即时获取到服务信息进行监控告警。

采用以上技术方案，客户端在某个API具有注册发布的需求时，使用自定义注解，客户端扫描自定义注解后向服务端注册API信息。

采用以上技术方案，所述公共组件包括执行如下操作：

所述公共组件提供并维护基础指令，包括服务端拉取、推送、更新以及心跳的操作请求；

服务启动后会判断是否开启注册，在确定开启注册后，客户端扫描使用自定义注解对应的API信息；

所述公共组件提供多种负载均衡策略，客户端在调用API时，从本地缓存获取对应列表，调用负载均衡策略获取目标地址进行服务调用。

采用以上技术方案，所述服务端核心组件包括执行如下操作：

在客户端发生服务注册请求时，所述服务端核心组件将客户端的API和服务信息缓存到本地，并推送到集群服务，告知数据发生变更；

当有新的服务发生注册时，客户端维持服务心跳，并且在服务下线时，自动生成告警信息并进行推送，通知订阅者服务不可用，同时客户端即时更新本地缓存。

本发明的有益效果：本发明将各应用服务与各微服务注册中心通过SDK与注册中心建立长连接保持通信，通过注册中心将各应用服务与各微服务注册中心进行整合，能够实现服务监控、负载均衡及API路由的统一管理和维护，而且本发明注册中心不会干涉各应用服务与微服务注册中心原有的通信协议，无侵入性，耦合度低，便于对接，可以根据实际需求进行配置，使用灵活。

附图说明

图1是本发明实施例1一种多类型微服务注册中心管理系统的结构框图。

图2是本发明实施例1注册中心的结构框图。

图3是本发明实施例2一种多类型微服务注册中心管理方法的流程示意图。

图4是本发明实施例2中步骤103的流程示意图。

附图标记如下：1、注册中心；11、服务端；12、客户端；13、公共组件；14、服务端核心组件；2、微服务注册中心；3、应用服务。

具体实施方式

下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。

所述实施例的示例在附图中示出，其中自始至终相同或类似的标号表示相同或类似的元件或具有相同或类似功能的元件。下面通过参考附图描述的实施例是示例性的，旨在用于解释本发明，而不能理解为对本发明的限制。

实施例1

参照图1和图2所示，本发明实施例1提供一种多类型微服务注册中心管理系统，包括注册中心1、各微服务注册中心21和各应用服务3，各应用服务3与微服务注册中心21的注册业务按照原协议保持通信，注册中心1包括服务端11和客户端12，服务端11支持与客户端12通信，各微服务注册中心21和各应用服务3通过SDK与注册中心1通信、上报或订阅信息。具体的,服务端11用于提供服务信息和路由注册接口，缓存、分发服务和接口信息，用于支持与客户端12的通信；客户端12用于提供SDK，通过配置服务端11地址，调用接口注册服务信息和路由信息，用于实现各应用服务3与微服务注册中心21通过SDK与注册中心1通信。

示例地，参照图1所示，各微服务注册中心21有3个，3个微服务注册中心21分别为Eureka、Nacos和Zookeeper，其中Eureka注册有应用服务3A、应用服务3B和应用服务3C，Nacos注册有应用服务3C、应用服务3D和应用服务3E，还有Zookeeper注册有应用服务3G、应用服务3H和应用服务3I，这是各应用服务3与各微服务注册中心21原有的通信协议。本发明维持现状，将3个微服务注册中心21Eureka、Nacos和Zookeeper通过SDK与注册中心1建立长连接保持通信，同时应用服务3A、B、C、D、E、F、G、H、I通过SDK与注册中心1建立长连接保持通信。通过注册中心1将各应用服务3与各微服务注册中心21进行整合，能够实现服务监控、负载均衡及API路由的统一管理和维护，而且本发明注册中心1不会干涉各应用服务3与微服务注册中心21原有的通信协议，无侵入性，耦合度低，便于对接，可以根据实际需求进行配置，使用灵活。

其中注册中心1服务端包括后端和前端两个模块，后端提供客户端12的注册接口、页面管理的注册服务、服务列表及负载均衡的配置、API列表及API接口，负载均衡配置支持单个应用集群和注册中心1集群负载均衡；前端通过调用API接口进行页面展示，页面展示包括注册中心列表、服务管理和路由管理。当然服务端11还用于定时清除一些不可用服务，保证服务的可用性。

在本实施例的优选方案中，注册中心1包括公共组件13，该公共组件13用于提供并维护基础指令，例如服务端11拉取、推送、更新以及心跳的操作请求；该公共组件13还用于提供多种负载均衡策略，客户端12在调用API时，从本地缓存获取对应列表，调用负载均衡策略获取目标地址进行服务调用。还有在有自定义注解使用时，服务启动后会判断是否开启注册，在确定开启注册后，该公共组件13扫描对应的API信息。

还有注册中心1包括服务端核心组件14，服务端核心组件14用于缓存数据，以及在服务上下线时，用于即时剔除、告警以及通知订阅者。具体的，在客户端12发生服务注册请求时，服务端核心组件14将客户端12的API和服务信息缓存到本地，并推送到集群服务，告知数据发生变更；当有新的服务发生注册时，客户端12与该注册的服务维持心跳，并且在服务下线时，自动生成告警信息并进行推送，通知订阅者服务不可用，同时客户端12即时更新本地缓存。

实施例2

参照图3所示，本发明实施例2提供一种多类型微服务注册中心管理方法，包括如下内容：

在步骤101中，各应用服务3与微服务注册中心21的注册业务按照原协议保持通信。

具体的，各应用服务3与微服务注册中心21的注册业务按照原协议保持通信的示例如下：参照图2所示，各微服务注册中心21有3个，3个微服务注册中心21为Eureka、Nacos和Zookeeper，其中Eureka注册有应用服务3A、应用服务3B和应用服务3C，Nacos注册有应用服务3C、应用服务3D和应用服务3E，还有Zookeeper注册有应用服务3G、应用服务3H和应用服务3I。

在步骤102中，部署服务端11，由服务端11提供服务信息和路由注册接口，缓存、分发服务和接口信息，服务端11支持与客户端12通信。

在步骤103中，通过配置服务端11地址，调用接口注册服务信息和路由信息，各微服务注册中心21和各应用服务3集成SDK与注册中心1通信、上报或订阅信息。

具体的，参照图4所示，步骤103包括如下步骤：

在步骤103a中，客户端12根据SDK包通过配置文件配置服务端11地址、API路由管理包路径及订阅服务名称，客户端12在某个API具有注册发布的需求时，增加自定义注解；

在步骤103b中，服务启动成功后会自动连接到指定的服务端11，向服务端11注册本服务信息，在有自定义注解使用时，客户端12扫描自定义注解后向服务器11注册API信息；

在步骤103c中，拉取订阅服务信息，并缓存订阅服务信息及API信息到本地；

在步骤103d中，开启服务心跳，维护服务间的心跳，服务心跳利用Netty的IdleStateHandler保证服务的可用性；

在步骤103e中，暴露服务的相关状态接口，方便服务端11即时获取到服务信息进行监控告警。

在本实施例的优选方案中，公共组件13包括执行如下操作：公共组件13提供并维护基础指令，包括服务端11拉取、推送、更新以及心跳的操作请求；服务启动后会判断是否开启注册，在确定开启注册后，客户端12扫描使用自定义注解对应的API信息；公共组件13提供多种负载均衡策略，客户端12在调用API时，从本地缓存获取对应列表，调用负载均衡策略获取目标地址进行服务调用。

在本实施例的优选方案中，服务端核心组件14包括执行如下操作：在客户端12发生服务注册请求时，服务端核心组件14将客户端12的API和服务信息缓存到本地，并推送到集群服务，告知数据发生变更，其中数据缓存分为分布式缓存和应用缓存；当有新的服务发生注册时，客户端12会进行连接或监听，保证正式注册的服务可用，当正式注册的服务下线时，客户端12自动生成告警信息并进行推送。在客户端12维持的服务心跳断开后会即时剔除该服务，并且通知订阅者服务不可用，同时客户端12即时更新本地缓存。

本发明的有益效果：本发明通过注册中心将各应用服务与各微服务注册中心进行整合，能够实现服务监控、负载均衡及API路由的统一管理和维护，而且本发明注册中心不会干涉各应用服务与微服务注册中心原有的通信协议，无侵入性，耦合度低，便于对接，可以根据实际需求进行配置，使用灵活。

以上所述实施例仅是为充分说明本发明而所举的较佳的实施例，本发明的保护范围不限于此。本技术领域的技术人员在本发明基础上所作的等同替代或变换，均在本发明的保护范围之内。本发明的保护范围以权利要求书为准。

Claims (10)

1.一种多类型微服务注册中心管理系统，其特征在于：包括注册中心、各微服务注册中心和各应用服务，各应用服务与微服务注册中心的注册业务按照原协议保持通信，所述注册中心包括：

服务端，所述服务端用于提供服务信息和路由注册接口，缓存、分发服务和接口信息，服务端支持与客户端通信；以及

客户端，所述客户端通过提供SDK，各微服务注册中心和各应用服务集成SDK与注册中心通信、上报或订阅信息。

2.如权利要求1所述的多类型微服务注册中心管理系统，其特征在于：所述注册中心包括公共组件，所述公共组件用于提供并维护基础指令，以及公共组件提供多种负载均衡策略，客户端在调用API时，从本地缓存获取对应列表，调用负载均衡策略获取目标地址进行服务调用。

3.如权利要求1所述的多类型微服务注册中心管理系统，其特征在于：所述注册中心包括服务端核心组件，所述服务端核心组件用于缓存数据，以及在服务上下线时，服务端核心组件用于即时剔除、告警以及通知订阅者。

4.如权利要求1所述的多类型微服务注册中心管理系统，其特征在于：所述服务端包括后端和前端两个模块：

后端提供客户端的注册接口、页面管理的注册服务、服务列表及负载均衡的配置、API列表及API接口；

前端通过调用API接口进行页面展示。

5.一种多类型微服务注册中心管理方法，其特征在于：包括如下内容：

各应用服务与微服务注册中心的注册业务按照原协议保持通信；

部署服务端，提供服务信息和路由注册接口，缓存、分发服务和接口信息，服务端支持与客户端通信；

通过配置服务端地址，调用接口注册服务信息和路由信息，各微服务注册中心和各应用服务集成SDK与注册中心通信、上报或订阅信息。

6.如权利要求5所述的多类型微服务注册中心管理方法，其特征在于：所述服务端包括后端和前端两个模块：

后端提供客户端的注册接口、页面管理的注册服务、服务列表及负载均衡的配置、API列表及API接口；

前端通过调用API接口进行页面展示。

7.如权利要求5所述的多类型微服务注册中心管理方法，其特征在于：所述各微服务注册中心和各应用服务集成SDK与注册中心通信、上报或订阅信息包括：

客户端根据SDK包通过配置文件配置服务端地址、API路由管理包路径及订阅服务名称；

服务启动成功后会自动连接到指定的服务端，向服务端注册本服务信息；

拉取订阅服务信息，并缓存订阅服务信息及API信息到本地；

开启服务心跳，维护服务间的心跳；

暴露服务的相关状态接口，方便服务端即时获取到服务信息进行监控告警。

8.如权利要求7所述的多类型微服务注册中心管理方法，其特征在于：客户端在某个API具有注册发布的需求时，使用自定义注解，客户端扫描自定义注解后向服务端注册API信息。

9.如权利要求5所述的多类型微服务注册中心管理方法，其特征在于：所述公共组件包括执行如下操作：

所述公共组件提供并维护基础指令，包括服务端拉取、推送、更新以及心跳的操作请求；

服务启动后会判断是否开启注册，在确定开启注册后，客户端扫描使用自定义注解对应的API信息；

所述公共组件提供多种负载均衡策略，客户端在调用API时，从本地缓存获取对应列表，调用负载均衡策略获取目标地址进行服务调用。

10.如权利要求5所述的多类型微服务注册中心管理方法，其特征在于：所述服务端核心组件包括执行如下操作：

在客户端发生服务注册请求时，所述服务端核心组件将客户端的API和服务信息缓存到本地，并推送到集群服务，告知数据发生变更；

当有新的服务发生注册时，客户端维持服务心跳，并且在服务下线时，自动生成告警信息并进行推送，通知订阅者服务不可用，同时客户端即时更新本地缓存。

Images