CN116016667A - 一种云原生平台多种类型注册中心统一治理方法和系统 - Google Patents

Abstract

本申请提供了一种云原生平台多种类型注册中心统一治理方法和系统。当接收到指向目标微服务的第一查询请求，调用目标微服务所在的目标注册中心提供的原生接口，以获取目标微服务的服务注册信息；将目标微服务的服务注册信息转换为目标服务注册信息；其中，目标服务注册信息包含有第一服务属性集合和第二服务属性集合；第一类服务属性为所有类型的注册中心共同支持的服务属性，第二类服务属性为目标注册中心单独支持的服务属性；将目标服务注册信息作为第一查询请求的响应进行返回。由此，实现了将多种注册中心中存储的服务注册信息转换为目标服务注册信息，并使用统一的目标服务注册信息对查询请求进行响应，以实现对多种类型注册中心的统一治理。

Description

一种云原生平台多种类型注册中心统一治理方法和系统

技术领域

本申请涉及云原生技术领域，特别涉及一种云原生平台多种类型注册中心统一治理方法、系统、计算机可读存储介质和电子设备。

背景技术

在微服务体系中，根据作用不同，分为微服务提供者(RPC Server)、微服务消费者(RPC Client)、注册中心(Register)三种角色。其中，微服务提供者在启动时，将自身的服务注册信息注册并存储到注册中心，同时定期向注册中心发送心跳机制，以确保其存活状态；微服务消费者从注册中心获取微服务提供者的服务注册信息，并根据服务注册信息实现服务调用。

微服务技术是实现上述微服务体系的技术，在微服务技术发展过程中，出现了多种不同的微服务框架(如Spring Cloud、Dubbo等)，不同的微服务框架配套不同的注册中心(比如Eureka、Nacos、Zookeeper、Mesh等)，注册中心用于实现该微服务框架下的各种微服务的注册和发现。随着业务的不断发展和复杂化，企业通常会存在基于不同微服务框架的应用，也就需要接入多种类型的注册中心，此时，由于各微服务框架的底层架构不同，不同的注册中心使用的数据结构、访问协议、数据一致性实现方式、接口类型均不相同，进而导致不同的注册中心只能提供自己的治理方式，管理员在治理不同的注册中心时，没有统一的治理方式，只能逐个访问对应的注册中心平台进行操作，非常不方便。

实现统一治理的前提是将不同注册中心中的服务注册信息进行统一，然后对外提供统一的调用方式。为此，相关技术中通常通过以下途径解决：一是修改各个注册中心的源代码，使其存储的服务注册信息按照统一的数据结构进行编排，这样，就可以用统一的调用方式使用该服务注册信息；二是不修改注册中心的源代码，而是对注册中心生成的服务注册信息进行改写，也就是对服务注册过程中不同注册中心生成的不同数据结构的服务注册信息进行拦截，并将其改写成预先设置的编码结构的服务注册信息后重新存储到注册中心中，使服务消费者能够根据该编码以统一的方式对改写后的服务进行调用。

然而，一方面，上述两种方式均需要修改原注册中心的服务注册/调用流程，对原微服务体系形成入侵，改造成本高，在生产实践中的实施难度较大；另一方面，上述两种方式均从计算机程序识别和管理的角度对微服务注册流程进行改进，并未考虑到管理员对多种类型的注册中心的治理需求，也就是说，对于管理员而言，仍然没有办法通过统一治理的接口来对多种类型的注册中心纳管的微服务进行治理。

因此，需要提供一种针对上述现有技术不足的改进技术方案。

发明内容

本申请的目的在于提供一种云原生平台多种类型注册中心统一治理方法、系统、计算机可读存储介质和电子设备，以解决或缓解上述现有技术中存在的问题。

为了实现上述目的，本申请提供如下技术方案：

本申请提供了一种云原生平台多种类型注册中心统一治理方法，包括：

响应于接收到指向目标微服务的第一查询请求，调用所述目标微服务所在的目标注册中心提供的原生接口，以获取所述目标微服务的服务注册信息；所述目标注册中心为多种类型的注册中心中任一个；

将所述目标微服务的服务注册信息转换为目标服务注册信息；其中，所述目标服务注册信息包含有第一服务属性集合和第二服务属性集合；所述第一服务属性集合和所述第二服务属性集合分别是通过对第一类服务属性和第二类服务属性进行汇集后得到的；所述第一类服务属性为所有类型的所述注册中心共同支持的服务属性，所述第二类服务属性为目标注册中心单独支持的服务属性；

将所述目标服务注册信息作为所述第一查询请求的响应进行返回。

优选地，所述第一类服务属性通过以下步骤确定：

采集所有类型的注册中心存储的服务注册信息中包含的所有服务属性；

对不同类型的所述注册中心存储的服务注册信息中包含的服务属性进行比对；

响应于所有类型的所述注册中心存储的服务注册信息中都含有相同的服务属性，对所述相同的服务属性的字段进行统一，并将所述相同的服务属性的取值按照预设映射关系进行转换，以作为所述第一类服务属性。

优选地，在确定所述第一类服务属性的同时，所述第二类服务属性通过以下步骤确定：

响应于所述注册中心存储的服务注册信息中包含所述第一类服务属性以外的服务属性，将所述第一类服务属性以外的服务属性的字段和取值写入预先定义的封装字段中，并保持所述第一类服务属性以外的服务属性的字段和取值均不变，以作为所述第二类服务属性。

优选地，在将所述目标服务注册信息作为所述第一治理请求的响应进行返回之后，还包括：

将所述目标服务注册信息进行缓存；

响应于接收到指向目标微服务的第二查询请求，调用所述目标注册中心提供的原生接口以获取所述目标微服务的最后更新时间；

响应于所述目标微服务的最后更新时间与已缓存的所述目标服务注册信息所记载的更新时间匹配，将已缓存的所述目标服务注册信息作为所述第二查询请求的响应进行返回。

优选地，上述云原生平台多种类型注册中心统一治理方法还包括：

响应于所述目标微服务的运行状态发生变化，所述目标微服务向所述目标注册中心发送服务注册信息更新请求；

响应于所述目标注册中心存储的所述目标微服务的服务注册信息发生更新，基于更新后的所述服务注册信息对已缓存的所述目标服务注册信息进行更新。

优选地，所述基于更新后的所述服务注册信息对已缓存的所述目标服务注册信息进行更新，具体为：

根据所述服务注册信息中发生变化的服务属性的字段，确定所述目标服务注册信息中对应的服务属性的字段；

对所述服务注册信息中发生变化的服务属性的取值进行转换，并作为所述目标服务注册信息中对应的服务属性的取值。

优选地，在所述响应于接收到指向目标微服务的第一查询请求，调用所述目标微服务所在的目标注册中心提供的原生接口，以获取所述目标微服务的服务注册信息之前，所述方法还包括：

响应于接收到对所有所述注册中心进行纳管的指令；

基于每个所述注册中心的访问地址和类型获取每个所述注册中心提供的原生接口信息；

基于所述注册中心的原生接口信息对所述注册中心进行纳管。

本申请实施例提供一种云原生平台多种类型注册中心统一治理系统，包括：

调用单元，配置为响应于接收到指向目标微服务的第一查询请求，调用所述目标微服务所在的目标注册中心提供的原生接口，以获取所述目标微服务的服务注册信息；所述目标注册中心为多种类型的注册中心中任一个；

转换单元，配置为将所述目标微服务的服务注册信息转换为目标服务注册信息；其中，所述目标服务注册信息包含有第一服务属性集合和第二服务属性集合；所述第一服务属性集合和所述第二服务属性集合分别是通过对第一类服务属性和第二类服务属性进行汇集后得到的；所述第一类服务属性为所有类型的所述注册中心共同支持的服务属性，所述第二类服务属性为目标注册中心单独支持的服务属性；

返回单元，配置为将所述目标服务注册信息作为所述第一查询请求的响应进行返回。

本申请实施例还提供一种计算机可读存储介质，其上存储有计算机程序，所述计算机程序为如上任一所述的云原生平台多种类型注册中心统一治理方法。

本申请实施例还提供一种电子设备，包括：存储器、处理器、以及存储在所述存储器中并可在所述处理器上运行的程序，所述处理器执行所述程序时实现如上任一所述的云原生平台多种类型注册中心统一治理方法。

有益效果：

本申请提供的技术方案中，在接收到指向目标微服务的第一查询请求时，调用目标微服务所在的目标注册中心提供的原生接口，以获取目标微服务的服务注册信息；将目标微服务的服务注册信息转换为目标服务注册信息；其中，目标服务注册信息包含有第一服务属性集合和第二服务属性集合；第一服务属性集合和第二服务属性集合分别是通过对第一类服务属性和第二类服务属性进行汇集后得到的；第一类服务属性为所有类型的注册中心共同支持的服务属性，第二类服务属性为目标注册中心单独支持的服务属性；将目标服务注册信息作为第一查询请求的响应进行返回。如此，通过调用目标注册中心提供的原生接口获取目标微服务的服务注册信息，并将其转换为格式统一的目标服务注册信息，无需对目标注册中心中存储的服务注册信息进行修改，即可实现对多种类型的注册中心的统一治理，相应地，管理员只需访问本申请提供的集中式微服务治理中心，即可对不同微服务框架下的微服务进行统一治理，从而降低了管理员的工作负担，提升了微服务治理的效率。

附图说明

构成本申请的一部分的说明书附图用来提供对本申请的进一步理解，本申请的示意性实施例及其说明用于解释本申请，并不构成对本申请的不当限定。其中：

图1为相关技术中微服务体系中各角色的相互关系示意图；

图2为相关技术中微服务框架与配套的注册中心之间对应关系的逻辑示意图；

图3为根据本申请的一些实施例提供的云原生平台多种类型注册中心统一治理方法的逻辑示意图；

图4为根据本申请的一些实施例提供的云原生平台多种类型注册中心统一治理方法的流程示意图；

图5为根据本申请的一些实施例提供的云原生平台多种类型注册中心统一治理系统的结构示意图；

图6为根据本申请的一些实施例提供的电子设备的结构示意图；

图7为根据本申请的一些实施例提供的电子设备的硬件结构图。

具体实施方式

下面将参考附图并结合实施例来详细说明本申请。各个示例通过本申请的解释的方式提供而非限制本申请。实际上，本领域的技术人员将清楚，在不脱离本申请的范围或精神的情况下，可在本申请中进行修改和变型。例如，示为或描述为一个实施例的一部分的特征可用于另一个实施例，以产生又一个实施例。因此，所期望的是，本申请包含归入所附权利要求及其等同物的范围内的此类修改和变型。

在以下描述中，所涉及的术语“第一/第二/第三”仅仅是区别类似的对象，不代表对对象的特定排序，可以理解地，“第一/第二/第三”在允许的情况下可以互换特定的顺序或先后次序，以使这里描述的本申请实施例能够以除了在这里图示或描述的以外的顺序实施。

为了便于理解本申请的技术方案，下面对相关技术进行说明。

在微服务体系通常包括三种角色：微服务提供者、微服务消费者、注册中心。其中，注册中心是核心组件，用于存储微服务的服务注册信息，比如位置数据、元数据、心跳数据等。此外，注册中心还记录了微服务与访问地址之间的映射关系，当服务消费者需要调用其他微服务时，先从注册中心获取需要调用的微服务的服务注册信息，并根据服务注册信息中包含的访问地址向该服务发起调用请求。可以理解，一个微服务可以调用其他微服务，也可以被其他微服务调用，也就是说，对同一个微服务，可以是微服务提供者，也可以是微服务消费者，或者同时获得微服务提供者和微服务消费者两种角色。

具体地，微服务体系中各角色的相互关系如图1所示，微服务提供者在服务启动时，将自身信息注册到注册中心，同时按照一定的时间间隔向注册中心发送心跳反馈信息，以提供其存活状态。注册中心用于保存微服务提供者的服务注册信息，并在微服务提供者的服务实例信息发生变化时，能够及时同步更新以避免微服务之间调用失败。微服务消费者在启动时通过注册中心订阅所要调用的微服务，以从注册中心获取该微服务的服务注册信息，并根据服务注册信息向该微服务发起调用请求，即与微服务提供者建立连接，同时将所获取的服务注册信息缓存到本地，以更新本地原先缓存的路由表。

由于各微服务框架的底层架构不同，不同的注册中心使用的数据结构、访问协议、数据一致性实现方式、接口类型均不相同。以数据结构为例，虽然各个注册中心所管理的服务注册信息中均包含服务状态这个属性，但是各个注册中心用于存储服务状态这个属性的字段和字段值却各不相同，比如在Eureka中用status字段记录服务状态，status取值为“UP”时表示服务正常运行，而在Mesh中用instanceStatus字段记录服务状态，instanceStatus取值为“STATUS_UP”时表示服务正常运行。由于不同的注册中心使用的数据结构、访问协议、数据一致性实现方式、接口类型均不相同，导致管理接口不同，管理员在管理不同的注册中心时，没有统一入口，只能逐个访问对应的注册中心平台进行操作，非常不方便，效率低下。

相关技术提供的解决方案中，大多数是从方便计算机程序识别和管理的角度对微服务注册流程进行改进，其目标在于打破不同注册中心之间服务调用的壁垒，使得不同的注册中心所纳管的微服务能够以统一的方式相互调用，并未考虑到管理员对多种类型注册中心的统一治理需求。例如，在对服务注册信息进行改写时，一些技术先对服务注册过程进行拦截，然后从服务注册信息中选择若干个服务属性，比如访问IP地址、端口等，再按照一定的编码规则将其转换为统一服务编码，并将统一服务编码存储在服务注册表中，同时存储服务标识与统一服务编码之间的映射关系。这样，服务消费者调用该服务时或者管理员需要治理该服务时，需要根据服务请求中所携带的服务标识从映射关系中查找对应的统一服务编码，并对其进行解码，得到原服务注册信息，最后将原服务注册信息提供给服务消费者使用或者管理员。可以看出，上述过程是面向程序接口的统一，也就是说，计算机程序通过统一服务编码能够确定服务标识指向的服务注册信息，不仅干涉了各微服务与注册中心之间原有的通信协议，而且对于管理员而言，所面对的仍是解码后数据结构各异的原服务注册信息，仍没有统一治理的接口以方便管理员对多种类型的注册中心纳管的微服务进行治理。

为此，本申请提供一种云原生平台多种类型注册中心统一治理方法、系统、计算机可读存储介质和电子设备。通过将目标微服务的服务注册信息转换为包含第一服务属性集合和第二服务属性集合的目标服务注册信息，通过第一服务属性集合对所有类型的注册中心共同支持的服务属性进行抽取、汇集，将各注册中心单独支持的服务属性进行封装，最终将数据结构各异的服务注册信息转换成数据结构一致的目标服务注册信息，大大方便了管理员对多种类型注册中心的统一治理。并且，通过调用目标微服务所在的目标注册中心提供的原生API接口，以获取目标微服务的服务注册信息，使得目标微服务及其目标微服务的消费者对该过程完全无感知，不会干涉各方原有的通信协议，实现了无入侵的统一治理。

示例性方法

本申请实施例提供一种云原生平台多种类型注册中心统一治理方法，如图3、图4所示，该方法包括：

步骤S101、响应于接收到指向目标微服务的第一查询请求，调用目标微服务所在的目标注册中心提供的原生接口，以获取目标微服务的服务注册信息。

其中，目标注册中心为多种类型的注册中心中任一个。

微服务是将原本独立的系统拆分成多个微小型的服务，这些微小型的服务都在各自独立的进程中运行，微服务之间主要通过超文本传输协议(Hyper Text TransferProtocol，HTTP)进行协作。为了实现服务零中断，微服务通常部署有多个服务实例，也叫服务节点，多个服务实例中的每个服务实例可以看作是微服务的一个副本，各个服务实例提供相同的功能，共同对外提供服务。本申请实施例中，目标微服务可以是目标注册中心所纳管的任意一个微服务，目标微服务的服务注册信息可以包含目标微服务本身的信息，比如微服务的名称、微服务的虚拟IP地址等，也可以包含目标微服务对应的多个服务实例的信息，比如各个服务实例的访问地址和端口等。

本申请实施例提供的云原生平台多种类型注册中心统一治理方法中，多种类型的注册中心包括但不限于：Eureka、Consul、Zookeeper、Nacos等，这些注册中心通常作为微服务框架的重要组成模块，共同实现对微服务的治理。

为了便于理解，下面对微服务框架以及各种类型的注册中心进行详细说明。

微服务框架是一种部署微服务运行时所需的运行环境，因此，为了部署微服务，通常需要在云原生平台中先部署相应的微服务框架，以使得微服务可正常运行。常见的微服务框架有Spring Cloud、Dubbo等。一般来说，微服务框架不同，对应的注册中心类型也不同。

具体地，参见图2，微服务框架包括Spring Cloud、Dubbo等，应理解，微服务框架还包括不同的版本，比如，Dubbo常用的有2.x或3.x版本，简称Dubbo2/3。对于Spring Cloud框架下的微服务，通常采用Eureka作为其注册中心，Dobbo框架下的微服务常与Zookeeper配套使用，而Nacos注册中心则既可以对接Spring Cloud框架下的微服务，也可以对接Dubbo框架下的微服务。

不同的注册中心具有不同的特点，下面对各类型的注册中心进行分别介绍。

Eureka是Netflix开发的注册中心，其主要适用于通过Java语言实现的分布式系统，或者是与Java虚拟机(Java Virtual Machine，JVM)兼容的程序语言构建的系统。除Java系统外，Eureka服务端的服务治理机制也提供完备的RESTful的应用程序编程接口(Application Program Interface，API)，以将由Java语言之外的其他程序语言构建的微服务纳入到Eureka的服务治理体系中。

Eureka包含两个组件：Eureka服务端(Eureka Server)和Eureka客户端(EurekaClient)，其中，Eureka Server提供微服务注册服务，微服务对应的各个服务实例(也称为服务节点)启动后，会在Eureka Server中进行注册，这样Eureka Server中的服务注册表中将会存储所有微服务可用服务节点的信息。

Eureka Client是一个Java语言开发的客户端，用于与Eureka Server的交互，对于Java语言实现的微服务，Eureka Client能够方便对其进行管理，但是对于其他程序语言构建的微服务，则通过RESTful API纳入Eureka后，使用时再针对该微服务实现相应的Eureka Client，以使得该微服务能够与Eureka Server正常交互。

需要说明的是，为保证注册中心的高可用性，Eureka通常以集群方式部署。Eureka集群通常采用非主从架构(非Master/Slave架构)，因此集群中各个节点的角色一致，没有主节点、从节点之分，微服务注册、续约、消费、下线等过程所产生的数据写入集群任意一个节点后，再由该节点向集群内其他节点进行复制，以实现弱一致性同步。

Nacos是另一种类型的注册中心，其致力于发现、配置和管理微服务，能够快速、轻松构建云原生应用程序和微服务平台。具体来说，Nacos通过提供一组简单易用的特性集实现快速构建云原生应用程序和微服务平台，这些特性集包括：服务发现和服务健康监测、动态配置服务、动态DNS服务、服务及其元数据管理等。Nacos几乎支持对接所有微服务框架的微服务，比如，Dubbo/gRPC管理的微服务、Spring Cloud的RESTful API微服务或Kubernetes管理的微服务等。也就是说，Nacos对微服务框架具有广泛的支持能力，其能够与各种类型的微服务框架进行对接，并作为微服务框架的注册中心，为其提供服务注册、服务发现等功能。

ZooKeeper是一个分布式的、开放源码的分布式应用程序协调服务，是Google的Chubby一个开源的实现，是Hadoop和Hbase的重要组件，其能够为分布式应用提供一致性服务。ZooKeeper提供的功能包括：配置维护、域名服务、分布式同步、组服务等。在微服务项目开发中，ZooKeeper常与微服务框架Dubbo配合使用，作为Dubbo的注册中心，提供微服务注册、发现等能力。

可以看出，以上介绍的各个注册中心由不同的企业主导开发，注册中心之间存在诸多差异，典型的比如接口类型、访问协议之间的差异。具体来说，访问协议是为实现微服务治理而在注册中心与各个微服务之间形成的通信协议。早期的分布式系统架构中，通常使用DNS协议作为微服务注册和发现的通信协议，但是，基于DNS协议的微服务注册和发现机制存在灵活性差、无法定制、端口及语言框架等问题，为解决上述问题，大型企业们开始主导开发新的注册中心，使得越来越多的基于“私有”协议的注册中心涌现了出来。由于各个注册中心由不同的企业主导开发，其工作方式和基本概念模式均不同，对微服务的开发和配置要求也不同，比如，有些注册中心需要集成特定的软件开发工具包(SoftwareDevelopment Kit，SDK)，有些注册中心在部署时需要完成指定的配置内容，这些差异无形中提高了微服务的开发技术门槛，也对开发人员提出了更高的技术要求，进而给企业使用微服务实现其业务系统带来了诸多挑战。

示例性地，Eureka、Zookeeper、Nacos在接口类型、数据一致性、访问协议的差异如表1所示，表1如下：

表1Eureka、Zookeeper、Nacos差异比较

从表1可以看出，Eureka、Zookeeper、Nacos三种注册中心均通过SDK对外提供接口。数据一致性方面，三种注册中心均基于分布式理论CAP实现。其中，CAP理论具体阐述了在一个分布式系统中，Consistency(一致性)、Availability(可用性)、PartitionTolerance(分区容错性)不能同时成立，即一个分布式系统的一致性C、可用性A、分区容错性P三个主要方面中，只能同时选择其中两个方面进行实现，通常分区容错性是必要的，因此常见的分布式系统可以是CP系统或者AP系统。表1中，Zookeeper是一种CP系统，Nacos可以是AP系统或者是CP系统，而Eureka则是AP系统。访问协议方面，Zookeeper和Eureka均采用TCP协议进行通信，而Nacos则采用HTTP协议。

正是由于不同类型的注册中心存在上述差异，导致各种类型的注册中心无法直接相互通信、相互融合。相关技术中，通过修改注册中心本身实现逻辑或者拦截注册中心的通信并进行服务注册信息改写的方式实现统一管理，然而，上述方法均对原微服务体系形成入侵。本申请实施例中，为了实现统一治理并且对原微服务体系无入侵，采用调用注册中心提供的原生接口(API接口)的方式获取服务注册信息。

具体来说，参见图3，云原生平台部署有集中式微服务治理中心，集中式微服务治理中心是面向管理员对多种注册中心进行统一治理而部署的组件，用于通过统一微服务注册中心集成平台的访问端点(Endpoint)调用各注册中心提供的原生API接口以获取多种类型注册中心的服务注册信息。也就是说，本申请实施例对不同种类的注册中心进行统一抽象封装，根据每个注册中心的特性，比如接口类型、数据一致性、访问协议等，在各种类型的注册中心的外围实现了统一的接口定义，形成统一微服务注册中心集成平台的访问端点，集中式微服务治理中心通过该访问端点获取不同种类的注册中心中的服务注册信息，从而实现对不同类型的微服务中心的统一纳管。

当集中式微服务治理中心接收到管理员对指向目标微服务的第一查询请求时，通过该访问端点调用目标微服务所在的目标注册中心提供的原生接口以获取目标微服务的服务注册信息。这里，目标注册中心可以是多种类型的注册中心中任一个，目标微服务可以是目标注册中心中任意一个微服务，也就是说，管理员无需切换即可通过集中式微服务治理中心对不同微服务中心中的任意微服务进行统一治理，并且不会干涉注册中心原有的通信，使得各个注册中心对此无感知。

本申请实施例中，目标注册中心相关的服务注册仍由微服务提供者与目标注册中心配合完成，只有接收到指向目标微服务的第一查询请求时，集中式微服务治理中心才会调用目标注册中心提供的原生接口获取目标微服务的服务注册信息，使得所获取的目标微服务的服务注册信息总是能够与目标注册中心所存储的服务注册信息保持一致，实现了微服务的自动注册和服务列表维护的同时，能够进行准实时的数据查询和数据同步。

应理解，管理员在发送指向目标微服务的第一查询请求之前，需要获取目标注册中心与目标微服务之间的对应关系，也就是先要对所有注册中心进行统一纳管，为此，一些实施例中，在响应于接收到指向目标微服务的第一查询请求，调用目标微服务所在的目标注册中心提供的原生接口，以获取目标微服务的服务注册信息之前，还包括：响应于接收到对所有注册中心进行纳管的指令；基于每个注册中心的访问地址和类型获取每个注册中心提供的原生接口信息；基于注册中心的原生接口信息对注册中心进行纳管。

具体地，在业务系统部署时，管理员能够获取所有的注册中心的类型、数量、部署方式、具体分布位置、访问地址等信息。集中式微服务治理中心初始化完成后，由管理员向集中式微服务治理中心发送对所有注册中心进行纳管的指令，集中式微服务治理中心接收到该指令，根据每个注册中心的访问地址和类型确定各注册中心的原生接口信息，也就是确定访问端点具体需要调用的原生API接口以及调用参数等，然后，基于每个注册中心的原生接口信息，通过访问端点向每个注册中心发出查询指令，以获取各个注册中心所纳管的部分或全部微服务列表，也就获取了各个注册中心与其纳管的微服务之间的对应关系，实现对注册中心的统一接入和纳管。

其中，查询指令可以是获取该注册中心的服务列表的指令或者获取注册中心的运行状态的指令，或者获取该注册中心的命名空间的指令，上述指令可以通过访问端点向每个注册中心同时发出，也可以是分别发出，本申请对此不做限定。此外，各个注册中心可以以集群方式部署，因此，注册中心的访问地址可以是集群中单个节点的访问地址，也可以是集群中多个节点的访问地址组成的集合，也就是说，本申请的访问端点可以用统一的方式基于多个节点的访问地址同时向注册中心的多个节点进行信息查询。

访问端点作为各类型的注册中心外围的统一接口，实现了对不同类型的注册中心的抽象封装，也就是针对不同类型的注册中心，访问端点进行了分别接入处理，以Eureka、Zookeeper、Nacos三种注册中心为例，其接入处理过程具体如下：

对于Nacos类型的注册中心，访问端点以Nacos类型的注册中心的访问地址作为参数，使用Nacos提供的原生开发API向注册中心发送查询指令，实现将Nacos注册中心中部分或者全部命名空间下的微服务统一纳管到集中式微服务治理中心。

对于Eureka类型的注册中心，访问端点以Eureka类型的注册中心的访问地址作为参数，通过Eureka提供的原生API接口，一次性将Eureka注册中心中的微服务整体纳管至集中式微服务治理中心。

在接入Zookeeper类型的注册中心时，访问端点以Zookeeper注册中心暴露的访问地址作为参数，通过Zookeeper的客户端SDK将Zookeeper作为注册中心纳管至集中式微服务治理中心。

从上述过程可以看出，集中式微服务治理中心对各类型的注册中心进行纳管时，访问端点通过各类型的注册中心提供的原生接口实现对不同类型的注册中心的接入，不会干涉微服务与各个注册中心之间原有的通信协议，也不会改变原有的服务注册、服务发现流程，无论是注册中心的服务端还是客户端，均无需进行任何调整，实现了无感知、无入侵的微服务统一接入和治理。

步骤S102、将目标微服务的服务注册信息转换为目标服务注册信息。

其中，目标服务注册信息包含有第一服务属性集合和第二服务属性集合；第一服务属性集合和第二服务属性集合分别是通过对第一类服务属性和第二类服务属性进行汇集后得到的；第一类服务属性为所有类型的注册中心共同支持的服务属性，第二类服务属性为目标注册中心单独支持的服务属性。

需要说明的是，目标微服务的服务注册信息包括多个服务属性，每个服务属性通常由键值对(key/value)表示，关键字key表示服务属性的名称，取值value用于表示服务属性的具体取值。

如前所述，不同的注册中心使用的数据结构并不相同，比如，相同的服务属性采用不同的键值对进行存储，或者内容相同的服务属性，其取值表达方式不同。而通过目标注册中心提供的原生接口获取的目标微服务的服务注册信息仍保留目标注册中心原有的数据结构，不利于管理员对其进行统一治理，因此，本申请实施例中，将目标微服务的服务注册信息转换为目标服务注册信息，使其具有统一的数据结构，以便管理员能够进行统一治理。具体来说，目标服务注册信息包括两类服务属性，分别是第一类服务属性和第二类服务属性，其中，第一类服务属性是所有类型的注册中心共同支持的服务属性，第二类服务属性是目标注册中心单独支持的服务属性，将目标微服务的服务注册信息中的第一类服务属性和第二类服务属性进行分别汇集，即可对应得到第一服务属性集合和第二服务属性集合。

进一步地，第一类服务属性通过以下步骤确定：采集所有类型的注册中心存储的服务注册信息中包含的所有服务属性；对不同类型的注册中心存储的服务注册信息中包含的服务属性进行比对；响应于所有类型的注册中心存储的服务注册信息中都含有相同的服务属性，对相同的服务属性的字段进行统一，并将相同的服务属性的取值按照预设映射关系进行转换，以作为第一类服务属性。

为了确定所有类型的注册中心共同支持的服务属性，本申请实施例中，首先将所有类型的注册中心存储的服务注册信息进行汇集，采集其中包含的所有服务属性，然后对采集到的服务属性进行比对，以抽取其中相同的内容。当确定所有类型的注册中心存储的服务注册信息中都含有某一相同的服务属性时，则对该相同的服务属性的字段进行统一，并将该相同的服务属性的取值按照预设映射关系进行转换，以作为第一类服务属性，以使得所有注册中心共同支持的服务属性能够以统一的数据结构返回，这样，管理员只需要熟悉一套服务属性的具体数据结构，就能够一目了然地理解其表达的含义，进而对其进行治理，减少了管理员的工作负担，提升了管理效率。

以前述Eureka和Mesh中的status字段和instanceStatus字段为例进行说明，鉴于Eureka和Mesh中status字段和instanceStatus字段都用于记录服务状态，本申请实施例将status字段和instanceStatus字段视作相同的服务属性，采用统一的status字段记录服务状态，并将取值“UP”和“STATUS_UP”统一转换为“working”来表示服务正常运行。

各种类型的注册中心还包括特有的服务属性，这些特有的服务属性是各种注册中心单独支持的服务属性，为保存数据的完整性，本申请实施例将其封装为第二类服务属性，具体地，在确定第一类服务属性的同时，第二类服务属性通过以下步骤确定：响应于注册中心存储的服务注册信息中包含第一类服务属性以外的服务属性，将第一类服务属性以外的服务属性的字段和取值写入预先定义的封装字段中，并保持第一类服务属性以外的服务属性的字段和取值均不变，以作为第二类服务属性。

应理解，在采集所有类型注册中心存储的服务注册信息所包含的所有服务属性之后，判断某个服务属性应归类为第一类服务属性还是第二类服务属性的过程是同时进行的，也就是说，对不同类型的注册中心存储的服务注册信息中包含的服务属性进行比对，在确定某个服务属性是所有类型注册中心共有的服务属性时，也就确认该服务属性可以作为第一类服务属性，同时排除了其是第二类服务属性的可能性，反之亦然。当某个服务属性是注册中心存储的服务注册信息中包含第一类服务属性以外的服务属性时，应将其作为第二类服务属性写入到预先定义的封装字段中，并保持该服务属性的字段和取值均不变。

需要说明的是，所有类型注册中心存储的服务注册信息所包含的所有服务属性仍是通过各个类型注册中心所提供的原生接口进行采集，具体通过注册中心的原生接口获取服务注册信息的方法参见前述步骤，在此不做一一赘述。

举例来说，Nacos类型的注册中心中存储的某微服务的服务注册信息包括name、namespace，以及dom、cacheMillis、useSpecifiedUrl、checksum、env、clusters等服务属性，其中Service的name、namespace为所有类型的注册中心中相同的服务属性，作为第一类服务属性，而dom、cacheMillis、useSpecifiedUrl、checksum、env、clusters等服务属性为Nacos类型的注册中心独有的服务属性，作为第二类服务属性。将Nacos类型的注册中心中存储的服务注册信息转换为目标服务注册信息后，数据结构如下所示：

本申请实施例中，通过对服务注册信息所包含的服务属性进行汇集、比对、统一和封装的过程，实现将目标微服务的服务注册信息转换为目标服务注册信息，从而形成了统一的数据结构，不仅有利于快速识别服务属性，更方便了管理员对服务注册信息的统一治理。同时，由于该过程仅涉及抽取、比对和封装操作，对计算资源消耗较低，相对于编码/解码等需要大量计算资源的操作而言，提高了计算效率。

步骤S103、将目标服务注册信息作为第一查询请求的响应进行返回。

本申请实施例中，在获得数据结构统一的目标服务注册信息之后，将其作为第一查询请求的响应进行返回。这样，对于不同类型的注册中心，集中式微服务治理中心均能够得到数据结构统一的服务注册信息，实现对各注册中心所纳管的微服务全景可观测。当有新类型的注册中心需要接入时，由于数据结构的统一，管理员无需了解新类型的注册中心的服务注册信息的数据结构即可对其进行统一治理，不仅非常方便接入和纳管不同类型的注册中心，提高对不同种类的注册中心的兼容性，而且使管理员能够更加专注于业务管理，提升了管理效率。此外，本申请采用集中式微服务治理中心作为统一的入口对不同种类的注册中心进行统一治理，管理员在对不同类型的注册中心纳管的微服务进行治理时，无需逐个访问对应的注册中心平台进行操作，提升了运维效率，减轻了管理员的工作负担。

应理解，第一查询请求的响应可以以多种形式进行返回，比如写入到某个文件中，比如以统一消息的模式即时返回，或者用XML、JSON等格式返回，本申请对此不做限定。在获得第一查询请求的响应之后，还可以采用友好、统一的图形界面进行展示，以便管理员更清楚掌握目标微服务的各种服务属性信息以及各个服务节点的运行状况。

实际应用中，对目标微服务进行首次查询时，为保证目标微服务的服务注册信息与目标注册中心所存储的服务注册信息保持同步，需要通过目标注册中心提供的原生接口以获得存储在目标注册中心的服务注册信息。若后续管理员对目标微服务进行再次查询，则可以从如下两种方式中任选一种进行处理：第一种方式，采用与首次查询相同的方式，即调用目标注册中心提供的原生接口以获得存储在目标注册中心的服务注册信息；第二种方式，引入缓存机制以提高查询效率。

为此，本申请实施例中，在将目标服务注册信息作为第一治理请求的响应进行返回之后，还包括：将目标服务注册信息进行缓存；响应于接收到指向目标微服务的第二查询请求，调用目标注册中心提供的原生接口以获取目标微服务的最后更新时间；响应于目标微服务的最后更新时间与已缓存的目标服务注册信息所记载的更新时间匹配，将已缓存的目标服务注册信息作为第二查询请求的响应进行返回。

具体来说，在获得目标服务注册信息之后，将目标服务注册信息在集中式微服务治理中心的本地进行缓存，当再次接收到指向目标微服务的查询请求(第二查询请求)时，集中式微服务中心首先调用目标注册中心提供的原生接口获取目标微服务的最后更新时间，并将所获取目标微服务的最后更新时间与已缓存的目标服务注册信息中所记载的更新时间进行比对，只有在目标微服务的最后更新时间与已缓存的目标服务注册信息所记载的更新时间相同，也就是缓存之后目标微服务的服务注册信息并未发生变化的情况下，将已缓存的目标服务注册信息作为第二查询请求的响应进行返回，这样通过缓存可以跳过将目标微服务的服务注册信息转换为目标服务注册信息的步骤，进一步提升了查询效率。

应理解，当目标微服务的最后更新时间与已缓存的目标服务注册信息所记载的更新时间不相同，说明本地缓存的目标服务注册信息可能与注册中心所存储的服务注册信息存在差异，此时集中式微服务治理中心将通过目标注册中心提供的原生接口获取目标微服务的最新的服务注册信息，以将其进行转换目标服务注册信息，并将转换的结果作为第二查询请求的响应进行返回，以保证集中式微服务治理中心与所治理的各个类型的注册中心的数据同步。

应理解，上述通过缓存提升查询效率的实现方式，是在接收到指向目标微服务的查询请求，且目标微服务的最后更新时间与已缓存的目标服务注册信息所记载的更新时间不相同时，通过目标注册中心提供的原生接口获取目标微服务的最新的服务注册信息，来对已缓存的目标服务注册信息进行更新。如果长时间没有接收到指向目标微服务的查询请求，则长期不对已缓存的目标服务注册信息进行更新。

此外，本申请实施例还支持在目标微服务的运行状态发生变化时，对已缓存的目标服务注册信息进行同步更新。简单来说，生产实践中，目标微服务的运行状态可能会发生变化，比如微服务上线、下线等导致的状态变化，为保证运行状态变化后的目标微服务的服务注册信息与集中式微服务治理中心中本地缓存的目标服务注册信息相一致，一些实施例中，还包括：响应于目标微服务的运行状态发生变化，目标微服务向目标注册中心发送服务注册信息更新请求；响应于目标注册中心存储的目标微服务的服务注册信息发生更新，基于更新后的服务注册信息对已缓存的目标服务注册信息进行更新。

具体地，在目标微服务的运行状态发生变化时，目标微服务将会向目标注册中心发送服务注册信息更新请求，目标注册中心根据该服务注册信息更新请求，对目标微服务的服务注册信息进行更新，以保持目标注册中心所存储的目标微服务的运行状态与变化后的运行状态一致。集中式微服务治理中心对目标微服务的服务注册信息的变化情况进行监听，当检测到目标注册中心存储的目标微服务的服务注册信息发生更新，则基于更新后的服务注册信息对已缓存到集中式微服务治理中心本地的目标服务注册信息进行更新。

需要特别注意的是，由于对所有微服务的服务注册信息的变化情况进行监听将会消耗大量的计算资源，为此，本申请通过为微服务设置自动更新属性以指示是否对该微服务的服务注册信息的变化情况进行监听，也就是说，管理员可以将一些需要频繁访问的微服务设置为需要自动更新的微服务，这样，集中式微服务中心仅对该部分微服务在注册中心存储的服务注册信息的变化情况进行监听，并基于更新后的服务注册信息对已缓存的目标服务注册信息进行更新即可。

进一步地，基于更新后的服务注册信息对已缓存的目标服务注册信息进行更新，具体为：根据服务注册信息中发生变化的服务属性的字段，确定目标服务注册信息中对应的服务属性的字段；对服务注册信息中发生变化的服务属性的取值进行转换，并作为目标服务注册信息中对应的服务属性的取值。

基于前述说明可知，本申请实施例中的目标服务注册信息包含有第一服务属性集合和第二服务属性集合。第一类服务属性通过对相同的服务属性的字段进行统一，并将相同的服务属性的取值按照预设映射关系进行转换后生成，第二类服务属性通过将第一类服务属性以外的服务属性的字段和取值写入预先定义的封装字段中，并保持第一类服务属性以外的服务属性的字段和取值均不变生成，因此对于不同类的服务属性需要采用不同的更新方式。

对于第一类服务属性，先确定发生变化的服务属性的字段对应的服务属性的字段，再将变化后的服务属性的取值按照预设映射关系进行转换，作为对应的服务属性的取值。

对于第二类服务属性，则只需直接确定发生变化的服务属性的字段对应的服务属性的字段，并将变化后的服务属性的取值直接作为对应的服务属性的取值。

本申请实施例中，根据服务注册信息中发生变化的服务属性的字段，确定目标服务注册信息中对应的服务属性的字段，以对发生变化的服务属性的取值进行转换，从而无需对已缓存的目标服务注册信息进行全面更新，仅需基于发生变化的服务属性的字段在已缓存的目标服务注册信息中快速定位对应的服务属性的字段，并对对应的服务属性的取值进行更新，极大减小了需要进行更新的数据量，提升了对已缓存的目标服务注册信息的更新效率。

综上所述，本申请中，在接收到指向目标微服务的第一查询请求时，调用目标微服务所在的目标注册中心提供的原生接口，以获取目标微服务的服务注册信息；目标注册中心为多种类型的注册中心中任一个；将目标微服务的服务注册信息转换为目标服务注册信息；其中，目标服务注册信息包含有第一服务属性集合和第二服务属性集合；第一服务属性集合和第二服务属性集合分别是通过对第一类服务属性和第二类服务属性进行汇集后得到的；第一类服务属性为所有类型的注册中心共同支持的服务属性，第二类服务属性为目标注册中心单独支持的服务属性；将目标服务注册信息作为第一查询请求的响应进行返回。如此，通过调用目标注册中心提供的原生接口获取目标微服务的服务注册信息，并将其转换为格式统一的目标服务注册信息，无需对目标注册中心中存储的服务注册信息进行修改，即可实现对多种类型的注册中心的统一治理，相应地，管理员只需访问本申请提供的集中式微服务治理中心，即可对不同微服务框架下的微服务进行统一治理，从而降低了管理员的工作负担，提升了微服务治理的效率。

本申请实施例中，通过对云原生平台中不同类型的注册中心的不同类型接口进行封装，并提供一整套完善的、能够兼容多种类型的注册中心的接入方法，使管理员可以非常方便的治理多种类型的注册中心，及纳管不同类型的注册中心的微服务。

本申请实施例中，通过将多种类型的注册中心提供的原生接口获取微服务的服务注册信息，并将所有类型的注册中心共同支持的服务属性汇集成第一服务属性集合，将各个类型的注册中心单独支持的服务属性封装成第二服务属性集合，从而对不同类型的注册中心中的微服务实现统一的微服务发现和统一展示。

示例性系统

本申请实施例还提供一种云原生平台多种类型注册中心统一治理系统，如图5所示，该系统包括多个网关实例，多个网关实例位于不同的命名空间中，系统包括：调用单元501、转换单元502和返回单元503。其中：

调用单元501，配置为响应于接收到指向目标微服务的第一查询请求，调用目标微服务所在的目标注册中心提供的原生接口，以获取目标微服务的服务注册信息。

其中，目标注册中心为多种类型的注册中心中任一个。

转换单元502，配置为将目标微服务的服务注册信息转换为目标服务注册信息。

其中，目标服务注册信息包含有第一服务属性集合和第二服务属性集合；第一服务属性集合和第二服务属性集合分别是通过对第一类服务属性和第二类服务属性进行汇集后得到的；第一类服务属性为所有类型的注册中心共同支持的服务属性，第二类服务属性为目标注册中心单独支持的服务属性。

返回单元503，配置为将目标服务注册信息作为第一查询请求的响应进行返回。

本申请实施例提供的云原生平台多种类型注册中心统一治理系统，能够实现上述任一实施例提供的云原生平台多种类型注册中心统一治理方法的流程、步骤，并达到相同的技术效果，在此不再一一赘述。

示例性设备

图6为根据本申请的一些实施例提供的电子设备的结构示意图；如图6所示，该电子设备包括：

一个或多个处理器601；

计算机可读介质，可以配置为存储一个或多个程序602，一个或多个处理器601执行一个或多个程序602时，实现如下步骤：响应于接收到指向目标微服务的第一查询请求，调用目标微服务所在的目标注册中心提供的原生接口，以获取目标微服务的服务注册信息；目标注册中心为多种类型的注册中心中任一个；将目标微服务的服务注册信息转换为目标服务注册信息；其中，目标服务注册信息包含有第一服务属性集合和第二服务属性集合；第一服务属性集合和第二服务属性集合分别是通过对第一类服务属性和第二类服务属性进行汇集后得到的；第一类服务属性为所有类型的注册中心共同支持的服务属性，第二类服务属性为目标注册中心单独支持的服务属性；将目标服务注册信息作为第一查询请求的响应进行返回。

图7为根据本申请的一些实施例提供的电子设备的硬件结构；如图7所示，该电子设备的硬件结构可以包括：处理器701、通信接口702、计算机可读介质703和通信总线704。

其中，处理器701、通信接口702、计算机可读存储介质703通过通信总线704完成相互间的通信。

可选地，通信接口702可以为通信模块的接口，如GSM模块的接口。

其中，处理器701具体可以配置为：响应于接收到指向目标微服务的第一查询请求，调用目标微服务所在的目标注册中心提供的原生接口，以获取目标微服务的服务注册信息；目标注册中心为多种类型的注册中心中任一个；将目标微服务的服务注册信息转换为目标服务注册信息；其中，目标服务注册信息包含有第一服务属性集合和第二服务属性集合；第一服务属性集合和第二服务属性集合分别是通过对第一类服务属性和第二类服务属性进行汇集后得到的；第一类服务属性为所有类型的注册中心共同支持的服务属性，第二类服务属性为目标注册中心单独支持的服务属性；将目标服务注册信息作为第一查询请求的响应进行返回。

处理器701可以是通用处理器，包括中央处理器(central processing unit，简称CPU)、网络处理器(Network Processor，简称NP)等，还可以是数字信号处理器(DSP)、专用集成电路(ASIC)、现成可编程门阵列(FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。可以实现或者执行本申请实施例中的公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。

本申请实施例的电子设备以多种形式存在，包括但不限于：

(1)移动通信设备：这类设备的特点是具备移动通信功能，并且以提供话音、数据通信为主要目标。这类终端包括：智能手机(例如：iPhone)、多媒体手机、功能性手机，以及低端手机等。

(2)超移动个人计算机设备：这类设备属于个人计算机的范畴，有计算和处理功能，一般也具备移动上网特性。这类终端包括：PDA、MID和UMPC设备等，例如iPad。

(3)便携式娱乐设备：这类设备可以显示和播放多媒体内容。该类设备包括：音频、视频播放器(例如：iPod)，掌上游戏机，电子书，以及智能玩具和便携式车载导航设备。

(4)服务器：提供计算服务的设备，服务器的构成包括处理器、硬盘、内存、系统总线等，服务器和通用的计算机架构类似，但是由于需要提供高可靠的服务，因此在处理能力、稳定性、可靠性、安全性、可扩展性、可管理性等方面要求较高。

(5)其他具有数据交互功能的电子装置。

需要指出，根据实施的需要，可将本申请实施例中描述的各个部件/步骤拆分为更多部件/步骤，也可以将两个或多个部件/步骤或者部件/步骤的部分操作组合成新的部件/步骤，以实现本申请实施例的目的。

上述根据本申请实施例的方法可在硬件、固件中实现，或者被实现为可存储在记录介质(诸如CD ROM、RAM、软盘、硬盘或磁光盘)中的软件或计算机代码，或者被实现通过网络下载的原始存储在远程记录介质或非暂时机器存储介质中并将被存储在本地记录介质中的计算机代码，从而在此描述的方法可被存储在使用通用计算机、专用处理器或者可编程或专用硬件(诸如ASIC或FPGA)的记录介质上的这样的软件处理。可以理解，计算机、处理器、微处理器控制器或可编程硬件包括可存储或接收软件或计算机代码的存储组件(例如，RAM、ROM、闪存等)，当软件或计算机代码被计算机、处理器或硬件访问且执行时，实现在此描述的云原生平台多种类型注册中心统一治理方法。此外，当通用计算机访问用于实现在此示出的方法的代码时，代码的执行将通用计算机转换为用于执行在此示出的方法的专用计算机。

本领域普通技术人员可以意识到，结合本文中所公开的实施例描述的各示例的单元及方法步骤，能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和涉及约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请实施例的范围。

需要说明的是，本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于设备及系统实施例而言，由于其基本相似于方法实施例，所以描述得比较简单，相关之处参见方法实施例的部分说明即可。

以上所描述的设备及系统实施例仅仅是示意性的，其中作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元提示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。

以上所述仅为本申请的优选实施例，并不用于限制本申请，对于本领域的技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本申请的保护范围之内。

Claims (10)

1.一种云原生平台多种类型注册中心统一治理方法，其特征在于，包括：

响应于接收到指向目标微服务的第一查询请求，调用所述目标微服务所在的目标注册中心提供的原生接口，以获取所述目标微服务的服务注册信息；所述目标注册中心为多种类型的注册中心中任一个；

将所述目标微服务的服务注册信息转换为目标服务注册信息；其中，所述目标服务注册信息包含有第一服务属性集合和第二服务属性集合；所述第一服务属性集合和所述第二服务属性集合分别是通过对第一类服务属性和第二类服务属性进行汇集后得到的；所述第一类服务属性为所有类型的所述注册中心共同支持的服务属性，所述第二类服务属性为目标注册中心单独支持的服务属性；

将所述目标服务注册信息作为所述第一查询请求的响应进行返回。

2.根据权利要求1所述的云原生平台多种类型注册中心统一治理方法，其特征在于，所述第一类服务属性通过以下步骤确定：

采集所有类型的注册中心存储的服务注册信息中包含的所有服务属性；

对不同类型的所述注册中心存储的服务注册信息中包含的服务属性进行比对；

响应于所有类型的所述注册中心存储的服务注册信息中都含有相同的服务属性，对所述相同的服务属性的字段进行统一，并将所述相同的服务属性的取值按照预设映射关系进行转换，以作为所述第一类服务属性。

3.根据权利要求2所述的云原生平台多种类型注册中心统一治理方法，其特征在于，在确定所述第一类服务属性的同时，所述第二类服务属性通过以下步骤确定：

响应于所述注册中心存储的服务注册信息中包含所述第一类服务属性以外的服务属性，将所述第一类服务属性以外的服务属性的字段和取值写入预先定义的封装字段中，并保持所述第一类服务属性以外的服务属性的字段和取值均不变，以作为所述第二类服务属性。

4.根据权利要求1所述的云原生平台多种类型注册中心统一治理方法，其特征在于，在将所述目标服务注册信息作为所述第一治理请求的响应进行返回之后，还包括：

将所述目标服务注册信息进行缓存；

响应于接收到指向目标微服务的第二查询请求，调用所述目标注册中心提供的原生接口以获取所述目标微服务的最后更新时间；

响应于所述目标微服务的最后更新时间与已缓存的所述目标服务注册信息所记载的更新时间匹配，将已缓存的所述目标服务注册信息作为所述第二查询请求的响应进行返回。

5.根据权利要求4所述的云原生平台多种类型注册中心统一治理方法，其特征在于，还包括：

响应于所述目标微服务的运行状态发生变化，所述目标微服务向所述目标注册中心发送服务注册信息更新请求；

响应于所述目标注册中心存储的所述目标微服务的服务注册信息发生更新，基于更新后的所述服务注册信息对已缓存的所述目标服务注册信息进行更新。

6.根据权利要求5所述的云原生平台多种类型注册中心统一治理方法，其特征在于，所述基于更新后的所述服务注册信息对已缓存的所述目标服务注册信息进行更新，具体为：

根据所述服务注册信息中发生变化的服务属性的字段，确定所述目标服务注册信息中对应的服务属性的字段；

对所述服务注册信息中发生变化的服务属性的取值进行转换，并作为所述目标服务注册信息中对应的服务属性的取值。

7.根据权利要求1-6中任一项所述的云原生平台多种类型注册中心统一治理方法，其特征在于，在所述响应于接收到指向目标微服务的第一查询请求，调用所述目标微服务所在的目标注册中心提供的原生接口，以获取所述目标微服务的服务注册信息之前，所述方法还包括：

响应于接收到对所有所述注册中心进行纳管的指令；

基于每个所述注册中心的访问地址和类型获取每个所述注册中心提供的原生接口信息；

基于所述注册中心的原生接口信息对所述注册中心进行纳管。

8.一种云原生平台多种类型注册中心统一治理系统，其特征在于，包括：

调用单元，配置为响应于接收到指向目标微服务的第一查询请求，调用所述目标微服务所在的目标注册中心提供的原生接口，以获取所述目标微服务的服务注册信息；所述目标注册中心为多种类型的注册中心中任一个；

转换单元，配置为将所述目标微服务的服务注册信息转换为目标服务注册信息；其中，所述目标服务注册信息包含有第一服务属性集合和第二服务属性集合；所述第一服务属性集合和所述第二服务属性集合分别是通过对第一类服务属性和第二类服务属性进行汇集后得到的；所述第一类服务属性为所有类型的所述注册中心共同支持的服务属性，所述第二类服务属性为目标注册中心单独支持的服务属性；

返回单元，配置为将所述目标服务注册信息作为所述第一查询请求的响应进行返回。

9.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，所述计算机程序被处理器执行时，实现权利要求1-7任一所述的云原生平台多种类型注册中心统一治理方法。

10.一种电子设备，其特征在于，包括：存储器、处理器、以及存储在所述存储器中并可在所述处理器上运行的程序，所述处理器执行所述程序时实现如权利要求1-7任一所述的云原生平台多种类型注册中心统一治理方法。

Images