CN115695537A - 实现服务网格适配传统微服务注册中心的方法、系统和装置 - Google Patents

Abstract

本发明涉及一种实现服务网格适配传统微服务注册中心的方法和系统，该方法包括：响应于接收到来自服务网格边车的微服务应用实例的服务注册请求，将服务注册请求转发到对应的注册中心，并建立和维护传统微服务模型与云原生微服务模型之间的对应关系。响应于接收到来自注册中心的服务发现数据，依据传统微服务模型与云原生微服务模型之间的对应关系将注册中心提供的传统微服务模型的服务发现数据转换为云原生微服务模型的服务发现数据，并将云原生服务模型的服务发现数据发送给发起服务发现请求的微服务应用实例。由此，无需对注册中心的运行逻辑进行修改，即可让传统微服务架构下的微服务应用实例在云原生平台中进行服务注册和服务发现。

Description

实现服务网格适配传统微服务注册中心的方法、系统和装置

技术领域

本发明涉及云原生技术领域，尤其涉及一种实现服务网格适配传统微服务注册中心的系统、方法、装置、处理器及其计算机可读存储介质。

背景技术

微服务架构是指一种通过组合多个微服务应用实例来构建业务系统的架构风格，微服务应用是指构成该业务系统的各个小型的服务，即一些协同工作、小而自治的服务，服务的功能具体由微服务应用实例来实现。

云原生(Cloud Native)是一种构建和运行应用程序的方法。Cloud表示应用程序位于云中，而不是传统的数据中心；Native表示应用程序从设计之初就考虑到云的环境，是在云环境中土生土长的应用程序。由于云原生在速度、安全、自愈、容错、故障隔离、可视化、弹性扩展等方面的优势，越来越多的企业开始将业务系统由传统微服务架构转换为云原生微服务架构。

目前，大多数是企业采用同时部署两个注册中心的方案来实现传统微服务架构下的注册中心适配云原生微服务架构，也就是在使用云原生注册中心的同时保留传统微服务架构下的注册中心，并通过信息同步机制让两个注册中心中存储的服务注册信息保持同步。但由于云原生注册中心和传统微服务架构下的注册中心所存储的服务注册信息不同，云原生注册中心存储的服务注册信息中添加了多种云原生属性的信息，例如网络类型、服务地域信息等，而传统微服务架构下的注册中心并没有定义这些云原生属性的信息，因此将传统微服务架构下的注册中心存储的服务注册信息同步至云原生注册中心会损害部分云原生能力。

因此，如何以低成本、高质量的方式将传统微服务架构的业务系统转换为云原生微服务架构，实现业务系统的云原生改造是一项亟待解决的技术问题。

发明内容

基于此，有必要针对上述技术问题，提供一种实现服务网格适配传统微服务注册中心的方法、系统、装置、处理器和存储介质。

第一方面，提供一种实现服务网格适配传统微服务注册中心的方法，所述方法包括：

响应于接收到来自服务网格边车的微服务应用实例的服务注册请求，将所述服务注册请求转发到对应的注册中心，并从所述服务网格边车收集微服务应用实例的访问信息，以及根据微服务应用实例的服务注册信息和所述访问信息建立和维护传统微服务模型与云原生微服务模型之间的对应关系；其中，所述服务注册请求中包括所述服务注册信息；

响应于接收到来自服务网格边车的服务发现请求，将所述服务发现请求转发到待发现的微服务应用实例对应的注册中心；其中，所述服务发现请求中包括所述待发现的微服务应用实例的标识信息；

响应于接收到来自注册中心的服务发现数据，依据传统微服务模型与云原生微服务模型之间的对应关系将所述注册中心提供的传统微服务模型的服务发现数据转换为云原生微服务模型的服务发现数据，并将所述云原生服务模型的服务发现数据发送给发起服务发现请求的微服务应用实例；其中，所述云原生微服务模型的服务发现数据中包括所述待发现的微服务应用的访问信息。

在所述接收到来自服务网格边车的微服务应用实例的服务注册请求之后，所述方法还包括：对所述服务注册请求根据注册中心的类型采用对应的访问协议进行解码处理；解析经过解码处理后的所述服务注册请求，以得到所述微服务应用实例的服务注册信息；相应地，所述将所述云原生服务模型的服务发现数据发送给发起服务发现请求的微服务应用实例，具体为：根据注册中心对应的访问协议对所述云原生微服务模型的服务发现数据进行编码处理，并将经过编码后得到的服务发现数据发送给发起服务发现请求的微服务应用实例。

所述根据所述服务注册请求和所述访问信息建立和维护传统微服务模型与云原生微服务模型之间的对应关系，具体为：根据所述微服务应用实例的服务注册信息和所述微服务应用实例的访问信息建立和维护服务模型映射仓；其中，服务模型映射仓以映射表的形式记录传统微服务模型与云原生微服务模型之间的对应关系；相应地，所述依据传统微服务模型与云原生微服务模型之间的对应关系将所述注册中心提供的传统微服务模型的服务发现数据转换为云原生微服务模型的服务发现数据，具体为：依据所述服务模型映射仓中的映射表将所述注册中心提供的传统微服务模型的服务发现数据转换为云原生微服务模型的服务发现数据。

所述依据所述服务模型映射仓中的映射表将所述注册中心提供的传统微服务模型的服务发现数据转换为云原生微服务模型的服务发现数据，包括：根据所述服务模型映射仓中的映射表对传统微服务模型的服务发现数据进行重新包装处理，以转换成所述云原生微服务模型的服务发现数据；其中，重新包装的内容包括服务地址、服务地域信息和服务网络定义。

所述方法还包括：将微服务应用实例的服务注册信息写入云原生API-Server；从所述云原生API-Server获取微服务应用实例的服务信息；其中，所述微服务应用实例的服务信息包括微服务应用实例的标签信息。

第二方面，提供一种实现服务网格适配传统微服务注册中心的系统，所述系统包括：

服务网格控制中心，用于根据服务网格的实际需求，管理服务网格的治理策略；

服务网格边车，用于拦截微服务应用实例的服务注册请求或者服务发现请求，并将所述服务注册请求或者服务发现请求转发到注册中心适配器，以及执行所述服务网格的治理能力；

注册中心适配器，用于接收并解析微服务应用实例的服务注册请求或者服务发现请求；其中，

所述注册中心适配器在接收所述服务注册请求时还用于从所述服务网格边车收集微服务应用实例的访问信息，并根据微服务应用实例的服务注册信息和所述访问信息建立和维护传统微服务模型与云原生微服务模型之间的对应关系；以及将所述服务注册请求转发到对应的注册中心；其中，所述服务注册请求中包括所述服务注册信息；

所述注册中心适配器在接收所述服务发现请求时还用于将所述服务发现请求转发到对应的注册中心；以及根据各个服务模型之间的对应关系将所述注册中心提供的传统微服务模型的服务发现数据转换为云原生微服务模型的服务发现数据，并将所述云原生服务模型的服务发现数据发送给发起服务发现请求的微服务应用。

较佳地，所述注册中心适配器包括：

协议解码模块，用于对所述服务注册请求或者所述服务发现请求根据注册中心的类型采用对应的访问协议进行解码处理；并将经过解码处理后的所述服务注册请求发送至服务注册控制模块，和/或将经过解码处理后的所述服务发现请求发送至对应的注册中心；

服务注册控制模块，与所述协议解码模块相连接，用于解析经过解码处理后的所述服务注册请求，将所述服务注册请求转发到对应的注册中心；并从所述服务注册请求中解析出所述服务注册信息；以及从所述服务网格边车收集所述访问信息，并根据所述服务注册信息和所述访问信息建立和维护服务模型映射仓；其中，所述服务模型映射仓以映射表的形式记录所述传统微服务模型与所述云原生微服务模型之间的对应关系；

服务模型映射仓，与所述服务注册控制模块相连接，用于接收所述服务注册控制模块发出的所述服务注册信息和所述访问信息，并以映射表的形式记录所述传统微服务模型与所述云原生微服务模型之间的相互对应关系，以供服务发现适配模块使用；

服务发现适配模块，与所述服务模型映射仓相连接，用于根据所述服务模型映射仓中的映射表将所述注册中心提供的传统微服务模型的服务发现数据转换为云原生微服务模型的服务发现数据，并将所述云原生微服务模型的服务发现数据发送给协议编码模块进行编码处理；以及

协议编码模块，与所述服务发现适配模块相连接，用于根据注册中心对应的访问协议对所述云原生微服务模型的服务发现数据进行编码处理，并将经过编码后得到的服务发现数据发送给发起服务发现请求的微服务应用实例。

尤佳地，所述系统还支持云原生架构和传统架构的混合部署，具体为：

传统架构中的微服务应用实例发起服务注册请求，通过网关访问注册中心，由注册中心根据服务注册请求对微服务应用实例进行注册；

云原生架构中的微服务应用实例发起服务注册请求，通过注册中心适配器对服务注册请求进行适配，以建立传统微服务模型与云原生微服务模型之间的对应关系，再由注册中心根据服务注册请求对微服务应用实例进行注册。

第三方面，提供一种实现服务网格适配传统微服务注册中心的处理的处理器，所述处理器被配置成执行计算机可执行指令，所述计算机可执行指令被所述处理器执行时，用于实现上述的实现服务网格适配传统微服务注册中心的方法的各个步骤。

第四方面，该计算机可读存储介质，其上存储有计算机程序，所述计算机程序可被处理器执行以实现上述的实现服务网格适配传统微服务注册中心的方法的各个步骤。

上述实现服务网格适配传统微服务注册中心的系统、方法、装置、处理器及其计算机可读存储介质，在服务注册时，将待注册的微服务应用实例发出的服务注册请求转发至传统微服务架构下的注册中心，并基于从服务注册请求中获得的微服务应用实例的服务注册信息和从服务网格边车收集的微服务应用实例的访问信息，建立和维护传统微服务模型与云原生微服务模型之间的对应关系。在服务发现时，将发起服务发现请求的微服务应用实例发出的服务发现请求转发至传统微服务架构下的注册中心，并依据在待发现的微服务应用实例的服务注册时建立的传统微服务模型与云原生微服务模型之间的对应关系，将传统微服务架构下的注册中心提供的传统微服务模型的服务发现数据转换为云原生微服务模型的服务发现数据，以及将云原生服务模型的服务发现数据发送给发起服务发现请求的微服务应用实例。由此，实现了无需对传统微服务架构下的注册中心的运行逻辑进行修改，即无需对该注册中心的源代码进行修改，即可将传统微服务架构下的业务系统迁移至云原生平台，且传统微服务应用实例可以在云原生平台中进行服务注册和服务发现。

附图说明

图1为现有技术采用一个注册中心实现传统微服务架构的业务系统上云的示意图。

图2为现有技术采用两个注册中心实现传统微服务架构的业务系统上云的示意图。

图3为传统微服务架构与云原生微服务架构的比较示意图。

图4为本发明实施例提出的实现服务网格适配传统微服务注册中心的方法的流程示意图。

图5为本发明实施例提出的实现服务网格适配传统微服务注册中心的系统的结构示意图。

图6为服务网格控制中心对服务网格边车进行管理的逻辑示意图。

图7为注册中心适配器的一个示例的结构示意图。

图8为微服务应用实例对应的服务网格边车的一个示例的结构示意图。

图9为云原生API-Server与注册中心适配器同步信息的逻辑示意图。

图10为多注册中心混合部署架构的示意图。

图11为传统微服务应用实例与云原生微服务应用实例通过云原生基础网络设施进行直接通信的效果示意图。

图12为本发明实现服务网格适配传统微服务注册中心的装置的内部结构图。

具体实施方式

为了能够更清楚地描述本发明的技术内容，下面结合具体实施例来进行进一步的描述。

在详细说明根据本发明的实施例前，应该注意到的是，在下文中，术语“包括”、“包含”或任何其他变体旨在涵盖非排他性的包含，由此使得包括一系列要素的过程、方法、物品或者设备不仅包含这些要素，而且还包含没有明确列出的其他要素，或者为这种过程、方法、物品或者设备所固有的要素。

注册中心是微服务架构的业务系统的核心，用于存储微服务应用实例的服务注册信息，服务注册信息包括微服务应用实例的访问地址。微服务应用实例可以通过访问注册中心获取业务系统中要访问的微服务应用实例的访问地址，并使用获取的访问地址对要访问的微服务应用实例进行访问。可见，注册中心是微服务架构的核心组件，在将已有的传统微服务架构的业务系统转换为云原生微服务架构时，让已有的传统微服务架构下的注册中心适配云原生微服务架构成为极为关键的一步。

也就是说，注册中心中记载的服务注册信息相当于微服务应用实例的″通讯录″，用于记录微服务应用实例和访问地址的映射关系。微服务应用实例在启动时，将自身的访问地址等服务注册信息以服务注册请求的形式发送到注册中心，注册中心存储这些服务注册信息。发起服务发现请求的微服务应用实例可以通过访问注册中心查询要访问的微服务引用实例的访问地址，并通过查询到的访问地址访问要访问的微服务应用实例。

现有技术中，从传统的微服务架构转向云原生微服务架构，已有的注册中心迁移方案主要分为以下两类：

第一种方案，如图1所示，采用一个注册中心：对传统微服务架构下的注册中心进行改造，让传统微服务架构下的注册中心适配云原生服务模型，在传统微服务应用实例无感知的情况下将传统微服务应用实例移植到云原生平台。具体而言，借助边车对请求的拦截能力，在传统微服务应用实例发出的服务注册请求的请求头中加入该微服务应用实例的工作负载和命名空间信息，用以标注该微服务应用实例在云原生平台(比如Kubernetes集群，Kubernetes系统是一种开源的容器编排软件，用于管理云原生平台中多个主机中的容器组)中的属性，并基于这些属性获取该微服务应用实例在云原生平台中的其他属性信息。同时对传统微服务架构下的注册中心进行改造，使其同时支持云原生微服务应用实例和传统微服务应用实例。

由于云原生微服务架构的核心是将基础设施交由云原生平台实现，而微服务应用实例的注册和发现功能属于基础设施的范畴。因此，上述方案需要对原有的传统微服务架构进行全局改造并且需要对大量数据进行迁移，否则迁移到云原生平台的传统微服务应用实例将无法正常运转。这种方案相当于推倒已经建成的基础设施，新建一个基础设施，因此需要修改不同类型的传统微服务架构下的注册中心的源代码，需要维护不同版本的注册中心的运行，运维压力大、成本高。

第二种方案，如图2所示，采用两个注册中心：使用云原生注册中心的同时保留传统微服务架构下的注册中心，并通过信息同步机制让两个注册中心中存储的服务注册信息保持同步。典型的同步机制包括：采用外部微服务应用实例的方式将传统微服务应用实例向云原生注册中心进行暴露，由云原生注册中心对传统微服务应用实例进行识别；或者采用内部微服务应用实例的方式由云原生注册中心对迁移至云原生平台中的传统微服务应用实例进行纳管，由云原生注册中心将传统微服务应用实例的服务注册信息同步到迁移至云原生平台中的传统微服务架构下的注册中心。但是，由于云原生注册中心和传统微服务架构下的注册中心所存储的服务注册信息不同，云原生注册中心存储的服务注册信息中添加了多种云原生属性的信息，例如网络类型、服务地域信息等，而传统微服务架构下的注册中心并没有定义这些云原生属性的信息，所以将传统微服务架构下的注册中心存储服务注册信息同步至云原生注册中心会损害部分云原生能力，例如服务运行时的信息、治理能力、编排能力。

此外，如图3所示，在传统微服务架构下，微服务应用实例之间通信是将微服务应用实例实际的IP地址作为访问地址进行，而云原生微服务应用实例之间通信则是将云原生微服务应用的虚拟IP地址作为该微服务应用对应的多个微服务应用实例的访问地址。原因在于，云原生微服务应用实例会根据实际运行状况自动地快速变更服务部署，其实际的IP地址经常发生变化，而云原生微服务应用的虚拟IP地址则是长期不变的，因此云原生微服务应用实例之间通过虚拟IP地址进行相互访问，能够防止因实际IP地址发生变化而导致的微服务应用实例失联。

相应地，传统微服务架构下的注册中心仅存储了传统微服务应用实例的实际IP地址，并且在将传统微服务应用实例迁移至云原生平台后还是使用实际IP地址直接通讯，一旦传统微服务应用的部署发生变更，则会导致服务注册信息失效和微服务应用实例失联的情况。

基于此，本发明的技术方案提供了一种无侵入的实现服务网格适配传统微服务注册中心的方法和系统，借助服务网格边车对请求进行的拦截功能，无需对传统微服务架构下的微服务应用实例和注册中心进行更改，即可直接将传统架构下的微服务应用实例和注册中心迁移至云原生平台运行，并且让传统微服务应用实例在云原生平台中进行服务注册和服务发现。

本发明实施例提供一种实现服务网格适配传统微服务注册中心的方法。在将传统微服务架构下的微服务应用实例和注册中心迁移至云原生平台后，微服务应用实例只需按照传统微服务架构下的运行逻辑向注册中心发出服务注册请求或者服务发现请求，注册中心也只需按照传统微服务架构下的运行逻辑对收到的服务注册请求或者服务发现请求进行处理，对发出服务注册请求的微服务应用实例进行注册，向发出服务发现请求的微服务应用实例返回传统微服务模型的服务发现数据。也就是说，无需对传统微服务架构下的微服务应用实例和注册中心的源代码进行修改，在将微服务应用实例和注册中心迁移至云原生平台之后，微服务应用实例和注册中心可以按照传统微服务架构下的运行逻辑正常运行。

当微服务应用实例发起服务注册请求，服务注册请求经服务网格边车转发到注册中心适配器，注册中心适配器接收服务注册请求后除了要将服务注册请求转发到对应的注册中心以外，还需要从服务网格边车收集微服务应用实例的访问信息，并根据服务注册请求所包括的服务注册信息和访问信息建立和维护传统微服务模型与云原生微服务模型之间的对应关系。当微服务应用实例发起服务发现请求，服务发现请求经服务网格边车转发到注册中心适配器，注册中心适配器将该服务发现请求转发到对应的注册中心，依据传统微服务模型与云原生微服务模型之间的对应关系将注册中心提供的传统微服务模型的服务发现数据转换为云原生微服务模型的服务发现数据，并将云原生服务模型的服务发现数据发送给发起服务发现请求的微服务应用实例。

在一个实施例中，提供了一种实现服务网格适配传统微服务注册中心的方法，该方法的执行主体以注册中心适配器为例进行说明，即该方法可以通过在注册中心适配器运行的程序实现；其中，注册中心适配器可以是应用系统的组成部分，该应用系统的组成部分还可以包括：应用程序，该应用程序可以在注册中心适配器上运行。

具体的，如图4所示，该方法包括以下步骤：

步骤S100，响应于接收到来自服务网格边车的微服务应用实例的服务注册请求，将服务注册请求转发到对应的注册中心，并从服务网格边车收集微服务应用实例的访问信息，以及根据微服务应用实例的服务注册信息和访问信息建立和维护传统微服务模型与云原生微服务模型之间的对应关系。

其中，服务注册请求中包括服务注册信息。

需要说明的是，在以Kubernetes集群为代表的云原生平台中，微服务应用实例运行在容器中，云原生平台以容器组(Pod)为最小单位对微服务应用实例进行调度和管理，每个容器组包含一个或者多个容器。容器组内的多个容器共享网络资源和存储资源，包括共享相同的IP地址。

服务网格(Service Mesh)是一个专门处理服务通讯的基础设施，能够在云原生平台中的各种微服务应用实例组成的复杂拓扑结构中进行可靠的请求传输。简单来说，服务网格的控制面组件能够为每个微服务应用实例所在的容器组添加服务网格边车(边车容器)，服务网格边车中设置的服务网格代理组件能够对进出所在容器组的请求进行拦截和处理。

具体来说，云原生平台中的所有微服务应用实例在部署完成后，需要在对应的注册中心中进行注册，将该微服务应用实例的服务注册信息存储在对应的注册中心中，以便其他微服务应用实例通过访问注册中心的方式获取该微服务应用实例的服务注册信息，进而使用服务注册信息中的访问地址对该微服务应用实例进行访问。因此，微服务应用实例需要将服务注册信息以服务注册请求的形式发向对应的注册中心。

应当理解，在将传统微服务架构下的业务系统迁移至云原生平台时，可能会将多个传统微服务架构的业务系统迁移至同一个云原生平台，相应地，该云原生平台中就会出现一个云原生微服务注册中心和多个传统微服务架构下的注册中心，并且多个传统微服务架构下的注册中心可能属于不同类型，因此微服务应用实例需要向对应的注册中心发送服务注册请求。

基于前述说明可知，在传统微服务架构下，微服务应用实例之间通过实际IP地址进行相互访问，因此传统微服务应用实例向注册中心发出的服务注册请求中的访问地址为微服务应用实例的实际IP地址，传统微服务架构下的注册中心中存储的服务注册信息中该微服务应用实例的访问地址也就是该微服务应用实例的实际IP地址。在将传统微服务应用实例和传统微服务架构下的注册中心迁移至云原生平台后，无需对传统微服务应用实例和传统微服务架构下的注册中心的源代码进行修改，因此微服务应用实例仍将实际IP地址作为访问地址封装在服务注册请求中，发向对应的注册中心。

需要说明的是，在云原生平台中，微服务应用实例部署在容器组中，因此微服务应用实例的实际IP地址就是微服务应用实例所在容器组的IP地址，相应地，服务注册请求中包含的微服务应用实例的访问地址就是该微服务应用实例所在容器组的IP地址。

在云原生平台中部署的服务网格能够为微服务应用实例所在的容器组添加服务网格边车，相应地，服务网格边车能够对微服务应用实例发出的所有请求进行拦截。也就是说，微服务应用实例向注册中心发出的服务注册请求必须要经过服务网格边车。服务注册请求中包括微服务应用实例的服务名称、所在容器组的IP地址和微服务应用实例的等，比如：库存服务：192.168.169：9000或积分服务：192.168.183：9000等。服务网格边车对微服务应用实例发出的所有请求进行拦截后，从中识别出微服务应用实例发出的服务注册请求，将服务注册请求发送至注册中心适配器。比如可以根据请求的接收方进行识别，如果请求指向注册中心，即可确定该请求为服务注册请求。

注册中心适配器接收到来自服务网格边车的微服务应用实例的服务注册请求后，一方面，鉴于传统微服务架构下的注册中心迁移至云原生平台后，注册中心的源代码没有进行修改，可以直接对微服务应用实例发出的服务注册请求进行响应，对微服务应用实例的服务注册信息进行存储，因此注册中心适配器可以直接将服务注册请求转发给注册中心，不对服务注册请求进行处理，让注册中心按照传统微服务架构下的运行逻辑对服务注册请求进行响应。

另一方面，鉴于微服务应用实例将所在容器组的IP地址作为访问地址封装在服务注册请求中，注册中心存储的微服务应用实例的访问地址也是所在容器组的IP地址。而在云原生平台对容器组进行编排和调度过程中，会对容器组进行重新创建和重新调度，相应地，重新创建或者重新调度后的容器组的IP地址也将随之变化，并且云原生平台能够根据微服务应用实例的负载情况，动态调整每个微服务应用对应的微服务应用实例的数量，因此不适合对微服务应用实例的IP地址进行静态记录，而应采用动态的服务发现机制来实现微服务应用实例之间的相互感知。

基于此，本发明实施例中的注册中心适配器除了保证注册中心对访问地址进行静态记录以外，还需要引入动态的服务注册信息更新机制，以适配云原生平台的需求。基于前述说明可知，相比于传统微服务架构下的注册中心，云原生注册中心存储的服务注册信息中添加了多种云原生属性的信息，例如网络类型、服务地域信息等，而服务网格作为云原生平台中专门处理通信的基础设施，能够获取云原生平台中每个微服务应用实例的访问信息，包括微服务应用实例对应的微服务应用的虚拟IP地址，以及其它多种云原生属性的信息，并且服务网格将每个微服务应用实例相关的网络信息下发给所在容器组的服务网格边车中，以让微服务应用实例之间实现可靠的请求传输。

因此，本发明实施例中的注册中心适配器在接收到来自服务网格边车的微服务应用实例的服务注册请求后，还可以从服务网格边车收集该微服务应用实例的访问信息，从而补足了传统微服务架构下的服务注册信息所缺失的具有云原生属性的访问信息。

进一步地，将传统微服务架构下的注册中心的服务注册信息存储格式定义为传统微服务模型，将云原生注册中心的服务注册信息存储格式定义为云原生微服务模型，两种模型对应的信息项中都包括微服务应用实例所在容器组的IP地址，但云原生微服务模型对应的信息项中还包括云原生属性的访问信息，因此将传统微服务模型中对应的服务注册信息与从服务网格边车中收集到的具有云原生属性的访问信息进行信息汇聚，即可得到云原生微服务模型对应的服务注册信息。

基于此，注册中心适配器可以依据微服务应用实例的服务注册请求中所包括的服务注册信息和访问信息建立和维护传统微服务模型与云原生微服务模型之间的对应关系。

此外，基于前述说明可知，微服务应用实例将服务注册信息封装为服务注册请求发送给对应的注册中心。因此，注册中心适配器要从服务注册请求中获取服务注册信息，需要对服务注册请求进行解析。并且，由于不同类型的注册中心适配的访问协议不同，微服务应用实例需要采用注册中心对应的编码方式对服务注册请求进行编码处理，相应地，注册中心适配器在对服务注册请求进行解析前，还需要先采用注册中心对应的解码方式对服务注册请求进行解码处理。

也就是说，注册中心适配器在接收到来自服务网格边车的微服务应用实例的服务注册请求之后，该方法还包括：对服务注册请求根据注册中心的类型采用对应的访问协议进行解码处理，解析经过解码处理后的服务注册请求，以得到微服务应用实例的服务注册信息。

进一步地，在一些发明实施例中，传统微服务模型与云原生微服务模型之间的对应关系具体由注册中心适配器中的服务模型映射仓建立。也就是说，前述的根据服务注册请求和访问信息建立和维护传统微服务模型与云原生微服务模型之间的对应关系，具体为：根据微服务应用实例的服务注册信息和微服务应用实例的访问信息建立和维护服务模型映射仓。其中，服务模型映射仓以映射表的形式记录传统微服务模型与云原生微服务模型之间的对应关系。

可以理解，为了能够建立和维护传统微服务模型与云原生微服务模型之间的对应关系，本发明实施例在注册中心适配器中单独设置了服务模型映射仓这一模块，服务模型映射仓能够为不同的注册中心分别建立独立的映射表，每张映射表用于记载某个传统微服务架构下的注册中心对应的传统微服务模型的服务注册信息与云原生微服务模型的服务注册信息的对应关系。

步骤S200，响应于接收到来自服务网格边车的服务发现请求，将服务发现请求转发到待发现的微服务应用实例对应的注册中心。

其中，服务发现请求中包括待发现的微服务应用实例的标识信息。

基于前述说明可知，当某个微服务应用实例要访问另一个微服务应用实例时，需要访问要访问的微服务应用实例对应的注册中心，以获取要访问的微服务应用实例的访问地址，并使用获得的访问地址对要访问的微服务应用实例发出访问请求，这个过程又被称作服务发现。因此，本发明实施例将该微服务应用实例向注册中心发出的请求称作服务发现请求，将要访问的微服务应用实例称作待发现的微服务应用实例。

和前述对服务注册请求的处理过程相类似，微服务应用实例向待发现的微服务应用实例对应的注册中心发起服务发现请求，服务发现请求经过服务网格边车，服务网格边车识别出该请求指向某个注册中心，即可确定该请求为服务发现请求，将服务发现请求发送至注册中心适配器。

可以理解，在云原生平台中包括多个微服务架构下的注册中心的场景下，待发现的微服务应用实例的服务注册信息存储在对应的注册中心中，因此服务发现请求应当指向待发现的微服务应用实例对应的注册中心。

注册中心适配器接收到来自服务网格边车的微服务应用实例的服务发现请求，无需对服务发现请求进行处理，直接将服务发现请求转发至对应的注册中心，由注册中心按照传统微服务架构下的运行逻辑对服务发现请求进行响应，向注册中心适配器返回传统微服务模型的服务发现数据，也就是待发现的微服务应用实例的服务注册信息。

可以理解，服务发现请求中包括待发现的微服务应用实例的标识信息，注册中心只需根据该标识信息即可快速定位到该微服务应用实例的服务注册信息。

步骤S300，响应于接收到来自注册中心的服务发现数据，依据传统微服务模型与云原生微服务模型之间的对应关系将注册中心提供的传统微服务模型的服务发现数据转换为云原生微服务模型的服务发现数据，并将云原生服务模型的服务发现数据发送给发起服务发现请求的微服务应用实例。

其中，云原生微服务模型的服务发现数据中包括待发现的微服务应用实例的访问信息。

具体来说，注册中心按照传统微服务架构下的运行逻辑对服务发现请求进行响应，即会向注册中心适配器返回传统微服务模型的服务发现数据。为了能够让发起服务发现请求的微服务应用实例获取云原生微服务模型的服务发现数据，注册中心适配器在接收到来自注册中心的服务发现数据后，即依据传统微服务模型与云原生微服务模型之间的对应关系将注册中心提供的传统微服务模型的服务发现数据转换为云原生微服务模型的服务发现数据，再将转换后的云原生服务模型的服务发现数据发送给发起服务发现请求的微服务应用实例。

发起服务发现请求的微服务应用实例可以从云原生服务模型的服务发现数据中获得待发现的微服务应用实例对应的微服务应用的虚拟IP地址，以及其它多种云原生属性的信息。因此，发起服务发现请求的微服务应用实例可以通过访问该虚拟IP地址来对待发现的微服务应用实例进行访问，以及利用获得的云原生属性的信息，基于云原生基础网络设施实现各个微服务应用实例之间的相互通信。

具体地，和前述对服务注册请求的处理过程相类似，发起服务发现请求的微服务应用实例根据注册中心对应的访问协议也会对服务发现请求进行编码处理，因此要将云原生微服务模型的服务发现数据发送给发起服务发现请求的微服务应用实例，还需要根据注册中心对应的访问协议对云原生微服务模型的服务发现数据进行编码处理。也就是说，前述将云原生服务模型的服务发现数据发送给发起服务发现请求的微服务应用实例，具体为：根据注册中心对应的访问协议对云原生微服务模型的服务发现数据进行编码处理，并将经过编码后得到的服务发现数据发送给发起服务发现请求的微服务应用实例。

此外，本发明实施例在注册中心适配器中单独设置了服务模型映射仓这一模块，服务模型映射仓以映射表的形式记录传统微服务模型与云原生微服务模型之间的对应关系，和前述对服务注册请求的处理过程相对应，注册中心适配器在接收到来自注册中心的服务发现数据后，依据服务模型映射仓中的映射表将注册中心提供的传统微服务模型的服务发现数据转换为云原生微服务模型的服务发现数据。也就是说，前述的依据传统微服务模型与云原生微服务模型之间的对应关系将注册中心提供的传统微服务模型的服务发现数据转换为云原生微服务模型的服务发现数据，具体为：依据服务模型映射仓中的映射表将注册中心提供的传统微服务模型的服务发现数据转换为云原生微服务模型的服务发现数据。

进一步地，注册中心适配器在将传统微服务模型的服务发现数据转换为云原生微服务模型的服务发现数据时，需要对传统微服务模型的服务发现数据进行重新包装处理，将服务模型映射仓中的映射表中记载的微服务应用的虚拟IP地址，以及其它多种云原生属性的信息与传统微服务模型的服务发现数据一起进行重新包装处理，以得到云原生微服务模型的服务发现数据。也就是说，前述依据服务模型映射仓中的映射表将注册中心提供的传统微服务模型的服务发现数据转换为云原生微服务模型的服务发现数据，包括：根据服务模型映射仓中的映射表对传统微服务模型的服务发现数据进行重新包装处理，以转换成云原生微服务模型的服务发现数据。其中，重新包装的内容包括服务地址、服务地域信息和服务网络定义，服务地址是指微服务应用的虚拟IP地址，服务地域信息是指微服务应用实例所在的地域，服务网络定义是指微服务应用之间相互通信所使用的网络的配置。

作为本发明的优选实施方式，本发明的该实现服务网格适配传统微服务注册中心的方法在云原生架构和传统架构混合部署的场景下运行，所谓混合部署的场景，是指某个传统微服务架构下的业务系统，将注册中心和一部分传统微服务应用实例迁移至云原生平台，而剩余的传统微服务应用实例没有进行迁移，此时已经迁移至云原生平台中的传统微服务应用实例可以采用前述的方法完成服务注册和服务发现，而没有进行迁移的传统微服务应用实例则需要通过访问已经迁移至云原生平台中的传统微服务架构下的注册中心完成服务注册和服务发现。具体来说，对于没有迁移至云原生平台的传统微服务应用实例，无法直接对已经迁移至云原生平台中的传统微服务架构下的注册中心进行访问，需要先将服务注册请求或者服务发现请求发送给云原生平台的网关，再由云原生平台的网关对请求进行转发，将请求路由至注册中心。而对于已经迁移至云原生平台中的传统微服务应用实例，则可以直接向已迁移至云原生平台中的传统微服务架构下的注册中心发出服务注册请求或者服务发现请求。

也就是说，传统架构中的微服务应用实例发起服务注册请求，通过网关访问注册中心，由注册中心根据服务注册请求对微服务应用实例进行注册。云原生架构中的微服务应用实例发起服务注册请求，通过注册中心适配器对服务注册请求进行适配，以建立传统微服务模型与云原生微服务模型之间的对应关系，再由注册中心根据服务注册请求对微服务应用实例进行注册。其中，云原生架构中的微服务应用实例指的是已经迁移至云原生平台中的传统微服务应用实例。

作为本发明的优选实施方式，本发明的该实现服务网格适配传统微服务注册中心的方法还包括：将微服务应用实例的服务注册信息写入云原生API-Server；从云原生API-Server获取微服务应用实例的服务信息；其中，微服务应用实例的服务信息包括微服务应用实例的标签信息。

基于前述说明可知，和传统微服务架构下的注册中心相比，云原生注册中心除了存储有服务注册信息以外，还存储有包括微服务应用实例的访问信息在内的多种云原生属性的信息。此外，云原生属性的信息中具体包括微服务应用实例的服务信息。

需要说明的是，云原生平台采用了服务(Service)机制来实现对微服务应用实例的管理，服务机制能够将提供同一个服务的多个微服务应用实例进行聚合，并且提供统一的入口地址。也就是说，服务机制能够将聚合为同一个服务的多个微服务应用实例进行统一管理。

具体来说，云原生平台中的服务信息与服务相对应，通过为微服务应用实例标记某个服务信息，即可将该微服务应用实例与该服务信息对应的服务进行关联，从而实现对所有标记有该服务信息的微服务应用实例的聚合。

应当理解，云原生平台中的服务信息可以与单个服务相对应，也可以与多个服务相对应。如果云原生平台的服务信息与单个服务相对应，那么直接采用该服务的标识信息(比如该服务的名称、编号等)作为服务信息，也就是使用该服务的标识信息对多个微服务应用实例进行标记，即可实现对同一个服务对应的多个微服务应用实例的聚合。如果云原生平台的服务信息与多个服务相对应，则需要使用独立的标签信息作为服务信息，也就是使用标签信息对多个微服务应用实例进行标记，即可实现对多个服务对应的所有微服务应用实例的聚合。可以理解，在服务信息与多个服务相对应的情况下，能够借助统一的服务信息对多个服务对应的所有微服务应用实例进行统一管理。

此外，在某些特殊场景下，为了实现对云原生平台中的微服务应用实例的灵活管理，可以为云原生平台中任意的多个微服务应用实例标记相同的标签信息，以便对这些标记有相同标签信息的所有微服务应用实例进行统一管理。

在本发明实施例中，为了让迁移至云原生平台的传统微服务架构下的注册中心能够与云原生注册中心保持信息一致，由注册中心适配器不断向云原生API-Server同步新写入的服务注册信息，并且不断通过云原生API-Server获取相应的服务信息，来完善服务模型映射仓中存储的云原生微服务模型。

为了实现前述的实现服务网格适配传统微服务注册中心的方法，本发明实施例还提出了一种实现服务网格适配传统微服务注册中心的系统。

如图5所示，该实现服务网格适配传统微服务注册中心的系统，其中，该系统包括：

服务网格控制中心，用于根据服务网格的实际需求，管理服务网格的治理策略；

服务网格边车，用于拦截微服务应用的服务注册请求或者服务发现请求，并将服务注册请求或者服务发现请求转发到注册中心适配器，以及执行服务网格的治理能力；

注册中心适配器，用于接收并解析微服务应用中的服务注册请求或者服务发现请求；其中，注册中心适配器在接收服务注册请求时还用于从服务网格边车收集微服务应用的访问信息，并根据微服务应用实例的服务注册信息和访问信息建立和维护传统微服务模型与云原生微服务模型之间的对应关系；以及将服务注册请求转发到对应的注册中心；其中，服务注册请求中包括服务注册信息；

注册中心适配器在接收服务发现请求时还用于将服务发现请求转发到对应的注册中心；以及根据各个服务模型之间的对应关系将注册中心提供的传统微服务模型的服务发现数据转换为云原生微服务模型的服务发现数据，并将云原生服务模型的服务发现数据发送给发起服务发现请求的微服务应用。

基于前述的实现服务网格适配传统微服务注册中心的方法的说明可知，要让注册中心适配器能够建立和维护传统微服务模型与云原生微服务模型之间的对应关系，就需要从服务网格边车接收服务注册请求，以及从服务网格边车收集微服务应用实例的访问信息。

如图6所示，服务网格边车作为服务网格的一个组件，由服务网格控制中心进行管理，因此服务网格控制中心能够向服务网格边车下发相应的配置信息，以实现对服务网格边车的治理。具体来说，服务网格控制中心能够向服务网格边车下发拦截和识别策略，将指向注册中心的请求识别为服务注册请求或者服务发现请求，将服务注册请求或者服务发现请求转发至注册中心适配器。

服务注册适配器接收到服务网格边车转发的请求后，对请求的类型进行进一步识别，如果识别出是服务注册请求，则需要从服务注册请求中获取服务注册信息，以及从服务网格边车收集访问信息，从而能够建立和维护传统微服务模型与云原生微服务模型之间的对应关系，并将服务注册请求转发至注册中心，如果识别出是服务发现请求，则直接将服务发现请求转发至注册中心。

注册中心接收到服务注册请求后，按照传统微服务架构下的运行逻辑对服务注册请求进行响应，也就是按照传统微服务模型对服务注册信息进行存储。注册中心接收到服务发现请求后，同样按照传统微服务架构下的运行逻辑对服务发现请求进行响应，也就是向注册中心适配器返回传统微服务模型的服务发现数据，由注册中心适配器依据传统微服务模型与云原生微服务模型之间的对应关系将注册中心提供的传统微服务模型的服务发现数据转换为云原生微服务模型的服务发现数据，并将云原生服务模型的服务发现数据发送给发起服务发现请求的微服务应用实例。

需要说明的是，目前服务网格边车的运行模式主要分为三大类：在同一台虚拟机中以程序方式运行微服务应用实例与服务网格边车、在云原生平台中以容器组形式并行运行、在云原生平台中以边缘容器模式运行，而本发明实施例中的服务网格边车和微服务应用实例采用并行模型运行，并行模式是服务网格架构下相对比较成熟的模式。

进一步地，为了降低技术方案的实现难度，本发明实施例可以复用边缘容器模式和插件模式来拓展服务网格边车的能力，具体可以用于扩展微服务应用实例之间的相互访问能力，以及向注册中心发送服务注册请求和服务发现请求的能力。

如图7所示，作为本发明的优选实施方式，注册中心适配器包括：

协议解码模块，用于对服务注册请求或者服务发现请求根据注册中心的类型采用对应的访问协议进行解码处理；并将经过解码处理后的服务注册请求发送至服务注册控制模块，和/或将经过解码处理后的服务发现请求发送至对应的注册中心；

服务注册控制模块，与协议解码模块相连接，用于解析经过解码处理后的服务注册请求，将服务注册请求转发到对应的注册中心；并从服务注册请求中解析出服务注册信息；以及从服务网格边车收集访问信息，并根据服务注册信息和访问信息建立和维护服务模型映射仓；其中，服务模型映射仓以映射表的形式记录传统微服务模型与云原生微服务模型之间的对应关系；

服务模型映射仓，与服务注册控制模块相连接，用于接收服务注册控制模块发出的服务注册信息和访问信息，并以映射表的形式记录传统微服务模型与云原生微服务模型之间的相互对应关系，以供服务发现适配模块使用；

服务发现适配模块，与服务模型映射仓相连接，用于根据服务模型映射仓中的映射表将注册中心提供的传统微服务模型的服务发现数据转换为云原生微服务模型的服务发现数据，并将云原生微服务模型的服务发现数据发送给协议编码模块进行编码处理；以及

协议编码模块，与服务发现适配模块相连接，用于根据注册中心对应的访问协议对云原生微服务模型的服务发现数据进行编码处理，并将经过编码后得到的服务发现数据发送给发起服务发现请求的微服务应用。

基于前述对实现服务网格适配传统微服务注册中心的系统的说明可知，注册中心适配器在整个系统的功能实现中发挥了重要作用。

需要从接收服务网格边车接收服务注册请求和服务发现请求，从服务网格边车收集微服务应用实例的访问信息，建立和维护传统微服务模型与云原生微服务模型之间的对应关系，将服务注册请求和服务发现请求转发至注册中心，以及将注册中心提供的传统微服务模型的服务发现数据转换为云原生微服务模型的服务发现数据，并将云原生服务模型的服务发现数据发送给发起服务发现请求的微服务应用实例。

为了能够实现上述功能，本发明实施例中的注册中心适配器可以由多个模块组成，由协议解码模块和协议编码模块直接与外部进行通信。应当理解，在生产实践中，传统微服务架构可以使用不同类型的注册中心，而不同类型的注册中心所使用的访问协议不同，例如Nacos(一种开源注册中心，致力于发现、配置和管理微服务)所使用的访问协议是HTTP协议(超文本传送协议)；Zookeeper(开放源码的分布式应用程序协调组件，为分布式应用提供一致性服务的软件)所使用的访问协议是TCP协议(Transmission ControlProtocol，一种面向连接的、可靠的、基于字节流的传输层通信协议)；Dubbo的访问协议是Dubbo协议(一种微服务开发框架，提供了RPC通信与微服务治理两大关键能力)，相应地，与注册中心适配的微服务应用实例所发出的服务注册请求或者服务发现请求也将使用对应的访问协议。为了能够让本发明实施例中的注册中心适配器能够适配各种类型的访问协议，注册中心适配器中的协议解码模块和协议编码模块需要能够根据注册中心的类型采用对应的访问协议进行解码处理和编码处理。也就是在接收到外部的请求时采用对应的访问协议对请求进行解码处理，在向外部发送数据前采用对应的访问协议对数据进行编码处理。

需要说明的是，协议解码模块除了需要对请求进行解码处理以外，还需要对解码后的请求的类型进行识别，并将解码后的服务注册请求发送至服务注册控制模块，将解码后的服务发现请求发送至注册中心。

此外，在接收到服务注册请求后，服务注册控制模块对服务注册请求进行解析，以获取服务注册信息，并基于服务注册信息和从服务网格边车收集到的访问信息建立和维护传统微服务模型与云原生微服务模型之间的对应关系，以及将服务注册请求发送给注册中心。

优选地，可以由服务模型映射仓以映射表的形式对传统微服务模型与云原生微服务模型之间的对应关系进行记录。也就是说，服务注册控制模块只需将服务注册信息和访问信息发送给服务模型映射仓，服务模型映射仓将按照预先的设置对传统微服务模型与云原生微服务模型之间的对应关系进行记录。

在接收到服务发现请求后，注册中心向注册中心适配器返回传统微服务模型的服务发现数据，由服务发现适配模块用于根据服务模型映射仓中的映射表将注册中心提供的传统微服务模型的服务发现数据转换为云原生微服务模型的服务发现数据，并将云原生微服务模型的服务发现数据发送给协议编码模块进行编码处理，再由协议编码模块将经过编码后得到的服务发现数据发送给发起服务发现请求的微服务应用。

优选地，服务发现适配模块将注册中心提供的传统微服务模型的服务发现数据转换为云原生微服务模型的服务发现数据，具体是根据服务模型映射仓中的映射表对微服务模型的服务发现数据进行重新包装处理，以转换成云原生微服务模型的服务发现数据；其中，云原生微服务模型的服务发现数据中包括待发现的微服务应用的访问信息。

优选地，鉴于不同注册中心对服务的定义不同，相应地，不同注册中心适配的服务注册请求也不同，具体是数据结构和字段存在区别。目前可以将服务注册请求按粒度分为API粒度的服务注册请求和服务粒度的服务注册请求，服务注册控制模块对服务注册请求进行解析时，需要根据服务注册请求的结构使用不同的解析方式获取服务注册信息。

如图8所示，为本发明实施例提出的微服务应用实例对应的服务网格边车的一个示例的结构示意图，在实际应用当中，服务网格边车包括：

服务注册模块，用于微服务应用实例向注册中心请求注册时，将识别出的服务注册请求转发至注册中心适配器；

服务发现模块，用于微服务应用实例向注册中心请求服务发现数据时，将识别出的服务发现请求转发至注册中心适配器。

优选地，服务网格边车还具有服务发现、协议解析、启用服务治理策略、服务可观测性、服务通讯安全的服务网格治理能力。

如图9所示，该系统还包括云原生API-Server，注册中心适配器用于将微服务应用实例的服务注册信息写入云原生API-Server，以及从云原生API-Server获取微服务应用实例的服务信息；云原生API-Server用于接收注册中心适配器写入的微服务应用实例的服务注册信息，以及向注册中心适配器同步微服务应用实例的服务信息；其中，微服务应用实例的服务信息包括微服务应用实例的标签信息。

微服务应用实例的标签信息用于表征该微服务服务应用实例的业务类型，如积分服务、库存服务等，同一个微服务应用实例的标签信息可以为一个、两个或两个以上，如quota、step、mutex等。

在实际应用当中，如图10所示，作为本发明的优选实施方式，该系统还支持云原生架构和传统架构的混合部署，具体为：

传统架构中的微服务应用实例发起服务注册请求，通过网关访问注册中心，由注册中心根据服务注册请求对微服务应用实例进行注册；

云原生架构中的微服务应用实例发起服务注册请求，通过注册中心适配器对服务注册请求进行适配，以建立传统微服务模型与云原生微服务模型之间的对应关系，再由注册中心根据服务注册请求对微服务应用实例进行注册。

其中，传统架构中的微服务应用实例没有迁移至云原生平台中，即没有上云，因此无法直接对已经迁移至云原生平台中的传统微服务架构下的注册中心进行访问，需要通过云原生平台的网关才能将服务注册请求发送至对应的注册中心，由对应的注册中心按照传统架构中的运行逻辑进行响应，在注册中心中存储传统架构中的微服务应用实例的服务注册信息，无需注册中心适配器进行处理。

云原生架构中的微服务应用实例则是指已经迁移至云原生平台中的传统微服务应用实例，则可以直接采用本发明实施例提出的方法完成服务注册，此处不再赘述。

如图11所示，迁移至云原生平台中的传统微服务应用实例使用本发明实施例所提供的方案后，可以和云原生微服务应用实例一样通过云原生基础网络设施直接进行通信，而不再使用所在容器组的IP地址进行相互访问。

在一具体实施例中，微服务应用实例A需要访问微服务应用实例B时，先通过云原生基础网络设施获取微服务应用B的地址信息，然后由微服务应用B将请求发送至对应的微服务应用实例B。云原生微服务应用实例C需要访问微服务应用实例B时，同样可以通过云原生基础网络设施完成通信过程。

在一个实施例中，提供了一种实现服务网格适配传统微服务注册中心的装置，该装置可以是服务器，其内部结构图可以如图12所示。该计算机设备包括通过系统总线连接的处理器、存储器、网络接口和数据库。其中，该计算机设备的处理器用于提供计算和控制能力。该计算机设备的存储器包括非易失性存储介质、内存储器。该非易失性存储介质存储有操作系统、计算机程序和数据库。该内存储器为非易失性存储介质中的操作系统和计算机程序的运行提供环境。该计算机设备的数据库用于存储服务注册的数据。该计算机设备的网络接口用于与外部的终端通过网络连接通信。该计算机程序被处理器执行时以实现一种实现服务网格适配传统微服务注册中心的方法。

本领域技术人员可以理解，图12中示出的结构，仅仅是与本发明方案相关的部分结构的框图，并不构成对本发明方案所应用于其上的计算机设备的限定，具体的计算机设备可以包括比图中所示更多或更少的部件，或者组合某些部件，或者具有不同的部件布置。

在一个实施例中，提供了一种计算机设备，包括存储器和处理器，存储器存储有计算机程序，处理器执行计算机程序时实现上述各个方法实施例中的步骤。

在一个实施例中，提供了一种计算机可读存储介质，其上存储有计算机程序，计算机程序被处理器执行时实现上述各个方法实施例中的步骤。

流程图中或在此以其他方式描述的任何过程或方法描述可以被理解为，表示包括一个或更多个用于实现特定逻辑功能或过程的步骤的可执行指令的代码的模块、片段或部分，并且本发明的优选实施方式的范围包括另外的实现，其中可以不按所示出或讨论的顺序，包括根据所涉及的功能按基本同时的方式或按相反的顺序，来执行功能，这应被本发明的实施例所属技术领域的技术人员所理解。

应当理解，本发明的各部分可以用硬件、软件、固件或它们的组合来实现。在上述实施方式中，多个步骤或方法可以用存储在存储器中且由合适的指令执行装置执行的软件或固件来实现。

本技术领域的普通技术人员可以理解实现上述实施例方法携带的全部或部分步骤是可以通过程序来指令相关的硬件完成的，程序可以存储于一种计算机可读存储介质中，该程序在执行时，包括方法实施例的步骤之一或其组合。

上述提到的存储介质可以是只读存储器，磁盘或光盘等。

在本说明书的描述中，参考术语“一实施例”、“一些实施例”、“示例”、“具体示例”、或“实施例”等的描述意指结合该实施例或示例描述的具体特征、结构、材料或者特点包含于本发明的至少一个实施例或示例中。在本说明书中，对上述术语的示意性表述不一定指的是相同的实施例或示例。而且，描述的具体特征、结构、材料或者特点可以在任何的一个或多个实施例或示例中以合适的方式结合。

尽管上面已经示出和描述了本发明的实施例，可以理解的是，上述实施例是示例性的，不能理解为对本发明的限制，本领域的普通技术人员在本发明的范围内可以对上述实施例进行变化、修改、替换和变型。

采用了本发明的该实现服务网格适配传统微服务注册中心的系统、方法、装置、处理器及其计算机可读存储介质，在服务注册时，将待注册的微服务应用实例发出的服务注册请求转发至传统微服务架构下的注册中心，并基于从服务注册请求中获得的微服务应用实例的服务注册信息和从服务网格边车收集的微服务应用实例的访问信息，建立和维护传统微服务模型与云原生微服务模型之间的对应关系。在服务发现时，将发起服务发现请求的微服务应用实例发出的服务发现请求转发至传统微服务架构下的注册中心，并依据在待发现的微服务应用实例的服务注册时建立的传统微服务模型与云原生微服务模型之间的对应关系，将传统微服务架构下的注册中心提供的传统微服务模型的服务发现数据转换为云原生微服务模型的服务发现数据，以及将云原生服务模型的服务发现数据发送给发起服务发现请求的微服务应用实例。由此，实现了无需对传统微服务架构下的注册中心的运行逻辑进行修改，即无需对该注册中心的源代码进行修改，即可将传统微服务架构下的业务系统迁移至云原生平台，且传统微服务应用实例可以在云原生平台中进行服务注册和服务发现。

在此说明书中，本发明已参照其特定的实施例作了描述。但是，很显然仍可以作出各种修改和变换而不背离本发明的精神和范围。因此，说明书和附图应被认为是说明性的而非限制性的。

Claims (10)

1.一种实现服务网格适配传统微服务注册中心的方法，其特征在于，所述方法包括以下步骤：

响应于接收到来自服务网格边车的微服务应用实例的服务注册请求，将所述服务注册请求转发到对应的注册中心，并从所述服务网格边车收集微服务应用实例的访问信息，以及根据微服务应用实例的服务注册信息和所述访问信息建立和维护传统微服务模型与云原生微服务模型之间的对应关系；其中，所述服务注册请求中包括所述服务注册信息；

响应于接收到来自服务网格边车的服务发现请求，将所述服务发现请求转发到待发现的微服务应用实例对应的注册中心；其中，所述服务发现请求中包括所述待发现的微服务应用实例的标识信息；

响应于接收到来自注册中心的服务发现数据，依据传统微服务模型与云原生微服务模型之间的对应关系将所述注册中心提供的传统微服务模型的服务发现数据转换为云原生微服务模型的服务发现数据，并将所述云原生服务模型的服务发现数据发送给发起服务发现请求的微服务应用实例；其中，所述云原生微服务模型的服务发现数据中包括所述待发现的微服务应用实例的访问信息。

2.根据权利要求1所述的实现服务网格适配传统微服务注册中心的方法，其特征在于，在所述接收到来自服务网格边车的微服务应用实例的服务注册请求之后，所述方法还包括：

对所述服务注册请求根据注册中心的类型采用对应的访问协议进行解码处理；

解析经过解码处理后的所述服务注册请求，以得到所述微服务应用实例的服务注册信息；

相应地，所述将所述云原生服务模型的服务发现数据发送给发起服务发现请求的微服务应用实例，具体为：

根据注册中心对应的访问协议对所述云原生微服务模型的服务发现数据进行编码处理，并将经过编码后得到的服务发现数据发送给发起服务发现请求的微服务应用实例。

3.根据权利要求2所述的实现服务网格适配传统微服务注册中心的方法，其特征在于，所述根据所述服务注册请求和所述访问信息建立和维护传统微服务模型与云原生微服务模型之间的对应关系，具体为：

根据所述微服务应用实例的服务注册信息和所述微服务应用实例的访问信息建立和维护服务模型映射仓；其中，服务模型映射仓以映射表的形式记录传统微服务模型与云原生微服务模型之间的对应关系；

相应地，所述依据传统微服务模型与云原生微服务模型之间的对应关系将所述注册中心提供的传统微服务模型的服务发现数据转换为云原生微服务模型的服务发现数据，具体为：

依据所述服务模型映射仓中的映射表将所述注册中心提供的传统微服务模型的服务发现数据转换为云原生微服务模型的服务发现数据。

4.根据权利要求3所述的实现服务网格适配传统微服务注册中心的方法，其特征在于，所述依据所述服务模型映射仓中的映射表将所述注册中心提供的传统微服务模型的服务发现数据转换为云原生微服务模型的服务发现数据，包括：

根据所述服务模型映射仓中的映射表对传统微服务模型的服务发现数据进行重新包装处理，以转换成所述云原生微服务模型的服务发现数据；其中，重新包装的内容包括服务地址、服务地域信息和服务网络定义。

5.根据权利要求1所述的实现服务网格适配传统微服务注册中心的方法，其特征在于，所述方法还包括：

将微服务应用实例的服务注册信息写入云原生API-Server；

从所述云原生API-Server获取微服务应用实例的服务信息；其中，所述微服务应用实例的服务信息包括微服务应用实例的标签信息。

6.一种实现服务网格适配传统微服务注册中心的系统，其特征在于，所述系统包括：

服务网格控制中心，用于根据服务网格的实际需求，管理服务网格的治理策略；

服务网格边车，用于拦截微服务应用实例的服务注册请求或者服务发现请求，并将所述服务注册请求或者服务发现请求转发到注册中心适配器，以及执行所述服务网格的治理能力；

注册中心适配器，用于接收微服务应用实例的服务注册请求或者服务发现请求；其中，

所述注册中心适配器在接收所述服务注册请求时还用于从所述服务网格边车收集微服务应用实例的访问信息，并根据微服务应用实例的服务注册信息和所述访问信息建立和维护传统微服务模型与云原生微服务模型之间的对应关系；以及将所述服务注册请求转发到对应的注册中心；其中，所述服务注册请求中包括所述服务注册信息；

所述注册中心适配器在接收所述服务发现请求时还用于将所述服务发现请求转发到对应的注册中心；以及根据各个服务模型之间的对应关系将所述注册中心提供的传统微服务模型的服务发现数据转换为云原生微服务模型的服务发现数据，并将所述云原生服务模型的服务发现数据发送给发起服务发现请求的微服务应用实例。

7.根据权利要求6所述的实现服务网格适配传统微服务注册中心的系统，其特征在于，所述注册中心适配器包括：

协议解码模块，用于对所述服务注册请求或者所述服务发现请求根据注册中心的类型采用对应的访问协议进行解码处理；并将经过解码处理后的所述服务注册请求发送至服务注册控制模块，和/或将经过解码处理后的所述服务发现请求发送至对应的注册中心；

服务注册控制模块，与所述协议解码模块相连接，用于解析经过解码处理后的所述服务注册请求，将所述服务注册请求转发到对应的注册中心；并从所述服务注册请求中解析出所述服务注册信息；以及从所述服务网格边车收集所述访问信息，并根据所述服务注册信息和所述访问信息建立和维护服务模型映射仓；其中，所述服务模型映射仓以映射表的形式记录所述传统微服务模型与所述云原生微服务模型之间的对应关系；

服务模型映射仓，与所述服务注册控制模块相连接，用于接收所述服务注册控制模块发出的所述服务注册信息和所述访问信息，并以映射表的形式记录所述传统微服务模型与所述云原生微服务模型之间的相互对应关系，以供服务发现适配模块使用；

服务发现适配模块，与所述服务模型映射仓相连接，用于根据所述服务模型映射仓中的映射表将所述注册中心提供的传统微服务模型的服务发现数据转换为云原生微服务模型的服务发现数据，并将所述云原生微服务模型的服务发现数据发送给协议编码模块进行编码处理；以及

协议编码模块，与所述服务发现适配模块相连接，用于根据注册中心对应的访问协议对所述云原生微服务模型的服务发现数据进行编码处理，并将经过编码后得到的服务发现数据发送给发起服务发现请求的微服务应用实例。

8.根据权利要求6或7所述的实现服务网格适配传统微服务注册中心的系统，其特征在于，所述系统还支持云原生架构和传统架构的混合部署，具体为：

传统架构中的微服务应用实例发起服务注册请求，通过网关访问注册中心，由注册中心根据服务注册请求对微服务应用实例进行注册；

云原生架构中的微服务应用实例发起服务注册请求，通过注册中心适配器对服务注册请求进行适配，以建立传统微服务模型与云原生微服务模型之间的对应关系，再由注册中心根据服务注册请求对微服务应用实例进行注册。

9.一种用于实现服务网格适配传统微服务注册中心的处理的处理器，其特征在于，所述处理器被配置成执行计算机可执行指令，所述计算机可执行指令被所述处理器执行时，用于实现权利要求1至5中任一项所述的实现服务网格适配传统微服务注册中心的方法的各个步骤。

10.一种计算机可读存储介质，其特征在于，其上存储有计算机程序，所述计算机程序可被处理器执行以实现权利要求1至5中任一项所述的实现服务网格适配传统微服务注册中心的方法的各个步骤。

Images