CN115378993B - 支持命名空间感知的服务注册与发现的方法和*** - Google Patents

Abstract

本发明涉及一种支持命名空间感知的服务注册与发现的方法和***，在服务注册时通过使用待注册服务的特征信息生成待注册服务的服务标识信息，并使用待注册服务的服务标识信息向服务注册中心注册待注册服务，同时将待注册服务的服务标识信息和虚拟服务地址以三元组数据的形式进行存储；在服务发现时使用待调用服务的特征信息从预设存储区域获取待调用服务对应的三元组数据，并使用三元组数据中的虚拟服务地址代替注册数据中服务所在容器组的IP地址作为待调用服务的访问地址。由此，在将传统微服务迁移至容器云平台时，无需对服务注册和服务发现的代码逻辑结构进行改动，有效降低了传统微服务迁移至容器云平台的复杂度，实现业务***的平滑迁移。

Description

支持命名空间感知的服务注册与发现的方法和***

技术领域

本发明涉及计算机领域，具体涉及一种支持命名空间感知的服务注册与发现的方法和***。

背景技术

在微服务架构的业务***的演进过程中，传统微服务架构的业务***通常运行在虚拟机或者裸金属服务器中，不同虚拟机或者裸金属服务器的底层资源管理都是相对独立的，无法对底层资源进行统一的调度、部署、编排，也就无法实对底层资源的弹性调度。

随着云原生技术的快速发展，越来越多的企业选择将传统微服务架构的业务***迁移至容器云平台，尤其是随着以Kubernetes为代表的容器编排技术和以Istio为代表的服务网格技术的普及，使得容器云平台更加适合微服务架构的业务***的部署和运行。

在企业将传统微服务架构的业务***迁移至容器云平台时，由于传统微服务架构与服务网格架构存在一定的技术架构差异，导致业务***的迁移需要进行一定的适配性开发和改造，使得业务***的迁移难度较大，工作量较高。

因此，亟需一种将传统微服务架构的业务***平滑迁移至容器云平台的技术方案。

发明内容

有鉴于现有技术的上述缺陷，本申请实施例基于服务网格技术提供的支持命名空间感知的服务注册与发现的方法和***，通过对实现传统微服务技术架构向服务网格架构迁移的关键技术进行改进，实现平滑迁移，使得在无需对业务***的服务注册和服务发现的代码逻辑结构的前提下，将传统微服务架构的业务***平滑迁移至服务网格***中，并继续让服务注册中心保持原先的运行逻辑。

第一方面，本申请实施例提供了一种基于服务网格的支持命名空间感知的服务注册方法，所述方法运行在容器云平台中，待注册服务部署在所述容器云平台中的第一容器组中，所述方法包含以下步骤：

响应于接收到所述第一容器组发出的第一服务注册请求，对所述第一服务注册请求进行解析；

响应于所述第一服务注册请求包含所述待注册服务的特征信息，使用所述待注册服务的特征信息生成所述待注册服务的服务标识信息；所述待注册服务的服务标识信息用于标识所述待注册服务，所述待注册服务的服务标识信息中包含所述待注册服务的命名空间信息；

使用所述待注册服务的服务标识信息向服务注册中心注册所述待注册服务；所述服务注册中心用于存储所述待注册服务的注册数据；

响应于所述待注册服务在所述服务注册中心注册成功，使用所述待注册服务的特征信息生成所述待注册服务对应的三元组数据，并将所述三元组数据存储至指定存储区域；所述三元组数据包括所述待注册服务的服务标识信息和所述待注册服务的虚拟服务地址。

可选的，所述第一容器组包括业务容器和边车容器，所述待注册服务部署在所述业务容器中，

在所述响应于接收到所述第一容器组发出的第一服务注册请求，对所述第一服务注册请求进行解析之前，所述方法还包括：

所述边车容器对所述业务容器发出的第二服务注册请求进行拦截，并使用所述待注册服务的特征信息将所述第二服务注册请求封装为所述第一服务注册请求。

可选的，在所述边车容器对所述业务容器发出的第二服务注册请求进行拦截之前，所述方法还包括：

所述边车容器从服务网格管理平台获取所述待注册服务的配置信息；所述配置信息包括识别信息和所述待注册服务的命名空间信息，所述识别信息用于从所述业务容器发出的请求中识别出所述第二服务注册请求。

可选的，已注册服务对应的三元组数据包括所述已注册服务的运行状态，所述方法还包括：

从所述已注册服务接收心跳数据包；

响应于所述心跳数据包超时，将所述已注册服务对应的三元组数据中所述已注册服务的运行状态标记为异常。

可选的，所述方法还包括：

通过所述容器云平台的统一访问接口监听所述第一容器组的运行状态；

响应于所述第一容器组处于异常状态，将所述待注册服务对应的三元组数据删除。

第二方面，本申请实施例还提供了一种基于服务网格的支持命名空间感知的服务发现方法，所述方法运行在容器云平台中，发起调用的服务部署在所述容器云平台中的第二容器组中，所述方法包含以下步骤：

响应于接收到所述第二容器组发出的第一服务调用请求，对所述第一服务调用请求进行解析；

响应于所述第一服务调用请求包含待调用服务的特征信息，从服务注册中心获取所有服务的注册数据，以及使用所述待调用服务的特征信息，从预设存储区域获取所述待调用服务对应的三元组数据；在所述注册数据中，各所述服务所在容器组的IP地址为各所述服务的访问地址，所述待调用服务对应的三元组数据由所述待调用服务注册时生成，所述待调用服务对应的三元组数据包括所述待调用服务的服务标识信息和虚拟服务地址；

使用所述待调用服务的服务标识信息与所述所有服务的注册数据进行匹配；

响应于所述待调用服务的服务标识信息与所述注册数据匹配成功，使用所述待调用服务的虚拟服务地址代替所述待调用服务所在容器组的IP地址，作为所述待调用服务的访问地址，并将所述待调用服务的访问地址返回给所述发起调用的服务。

第三方面，本申请实施例还提供了一种基于服务网格的支持命名空间感知的服务注册***，所述服务注册***部署在容器云平台中，所述容器云平台中包括第一容器组，所述第一容器组内部署有待注册服务；所述服务注册***包括：

第一解析模块，用于在接收到所述第一容器组发出的第一服务注册请求时，对所述第一服务注册请求进行解析；

第一生成模块，用于在所述第一服务注册请求包含所述待注册服务的特征信息时，使用所述待注册服务的特征信息生成所述待注册服务的服务标识信息；所述待注册服务的服务标识信息用于标识所述待注册服务，所述待注册服务的服务标识信息中包含所述待注册服务的命名空间信息；

注册模块，用于使用所述待注册服务的服务标识信息向所述服务注册中心注册所述待注册服务；所述服务注册中心用于存储所述待注册服务的注册数据；

第二生成模块，用于在所述待注册服务在所述服务注册中心注册成功时，使用所述待注册服务的特征信息生成所述待注册服务对应的三元组数据；所述三元组数据包括所述待注册服务的服务标识信息和所述待注册服务的虚拟服务地址；

存储模块，用于将所述三元组数据存储至指定存储区域。

可选的，所述第一容器组包括业务容器和边车容器，所述待注册服务部署在所述业务容器中，所述服务注册***还包括拦截封装模块，所述拦截封装模块部署在所述边车容器中，所述拦截封装模块用于在所述第一解析模块接收到所述第一容器组发出的第一服务注册请求，对所述第一服务注册请求进行解析之前，对所述业务容器发出的第二服务注册请求进行拦截，并使用所述待注册服务的特征信息将所述第二服务注册请求封装为所述第一服务注册请求。

可选的，所述拦截封装模块包括获取单元，所述获取单元用于在所述拦截封装模块对所述业务容器发出的第二服务注册请求进行拦截之前，从服务网格管理平台获取所述待注册服务的配置信息；所述配置信息包括识别信息和所述待注册服务的命名空间信息，所述识别信息用于从所述业务容器发出的请求中识别出所述第二服务注册请求。

可选的，已注册服务对应的三元组数据包括所述已注册服务的运行状态，所述服务注册***还包括标记模块，所述标记模块用于从所述已注册服务接收心跳数据包；在所述心跳数据包超时时，将所述已注册服务对应的三元组数据中所述已注册服务的运行状态标记为异常。

可选的，所述服务注册***还包括删除模块，用于通过所述容器云平台的统一访问接口监听所述第一容器组的运行状态；在所述第一容器组处于异常状态时，将所述待注册服务对应的三元组数据删除。

第四方面，本申请实施例还提供了一种基于服务网格的支持命名空间感知的服务发现***，所述服务发现***部署在容器云平台中，所述容器云平台中包括第二容器组；所述第二容器组内部署有发起调用的服务；所述服务发现***包括：

第二解析模块，用于在接收到所述第二容器组发出的第一服务调用请求时，对所述第一服务调用请求进行解析；

获取模块，用于在所述第一服务调用请求包含待调用服务的特征信息时，从服务注册中心获取所有服务的注册数据，以及使用所述待调用服务的特征信息，从预设存储区域获取所述待调用服务对应的三元组数据；在所述注册数据中，各所述服务所在容器组的IP地址为各所述服务的访问地址，所述待调用服务对应的三元组数据由所述待调用服务注册时生成，所述待调用服务对应的三元组数据包括所述待调用服务的服务标识信息和虚拟服务地址；

匹配模块，用于使用所述待调用服务的服务标识信息与所述所有服务的注册数据进行匹配；

替换模块，用于在所述待调用服务的服务标识信息与所述注册数据匹配成功时，将所述待调用服务的虚拟服务地址代替所述待调用服务所在容器组的IP地址，作为所述待调用服务的访问地址；

返回模块，用于将所述待调用服务的访问地址返回给所述发起调用的服务。

第五方面，本申请实施例还提供了一种计算机可读存储介质，其上存储有可执行指令，所述可执行指令在被机器执行时使实现第一方面或者第二方面所提供的方法。

第六方面，本申请实施例还提供了一种电子设备，其中存储有计算机程序，该计算机程序被处理器执行时实现第一方面或者第二方面所提供的方法。

可见，在上述技术方案中提出了一种基于服务网格技术实施的支持命名空间感知的服务注册及服务发现的方法及***，在服务注册时通过使用待注册服务的特征信息生成待注册服务的服务标识信息，并使用待注册服务的服务标识信息向服务注册中心注册待注册服务，同时将待注册服务的服务标识信息和虚拟服务地址以三元组数据的形式进行存储；在服务发现时使用待调用服务的特征信息从预设存储区域获取待调用服务对应的三元组数据，并使用三元组数据中的虚拟服务地址代替注册数据中服务所在容器组的IP地址作为待调用服务的访问地址。由此，实现了将传统微服务迁移至容器云平台时，无需对业务***的服务注册和服务发现的代码逻辑结构进行改动，有效降低了传统微服务架构的业务***迁移至容器云平台的复杂度，让传统微服务架构的业务***能够平滑迁移至容器云平台，也降低了传统微服务架构的业务***迁移的研发成本和业务***的运维难度。

附图说明

以下将结合附图对本发明的构思、具体结构及产生的技术效果作进一步说明，以充分地了解本发明的目的、特征和效果。

图1为服务网格的结构示意图；

图2为传统微服务架构***的一个示例的运行原理图；

图3为基于容器云平台的服务网格的一个示例的运行原理图；

图4为本申请实施例提出的一种基于服务网格的支持命名空间感知的服务注册方法的流程示意图；

图5为本申请实施例提出的另一种基于服务网格的支持命名空间感知的服务注册方法的流程示意图；

图6为本申请实施例提出的又一种基于服务网格的支持命名空间感知的服务注册方法的流程示意图；

图7为本申请实施例所提出的基于服务网格的支持命名空间感知的服务注册方法的一个示例的逻辑示意图；

图8为本申请根据一示例性实施例示出的源负载控制器从服务网格管理平台获取配置信息的流程示意图；

图9为本申请根据一示例性实施例示出的声明式API配置的相关代码的截图；

图10为本申请根据一示例性实施例示出的服务注册适配控制器对服务注册请求进行劫持的逻辑示意图；

图11为本申请根据一示例性实施例示出的服务注册适配控制器进行服务注册和三元组数据存储的流程示意图；

图12为本申请根据一示例性实施例示出的服务数据存储控制器对三元组数据进行更新的逻辑示意图；

图13为本申请根据一示例性实施例示出的服务数据存储控制器对三元组数据进行更新的流程示意图；

图14为本申请实施例提出的一种基于服务网格的支持命名空间感知的服务发现方法的流程示意图；

图15为本申请实施例提出的另一种基于服务网格的支持命名空间感知的服务发现方法的流程示意图；

图16为本申请实施例提出的又一种基于服务网格的支持命名空间感知的服务发现方法的流程示意图；

图17为本申请实施例所提出的基于服务网格的支持命名空间感知的服务发现方法的一个示例的逻辑示意图；

图18为本申请根据一示例性实施例示出的服务注册适配控制器进行服务发现的流程示意图；

图19为本申请实施例提出的一种基于服务网格的支持命名空间感知的服务注册***的结构示意图；

图20为本申请实施例提出的一种基于服务网格的支持命名空间感知的服务发现***的结构示意图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述。本领域技术人员应当理解的是，所描述的实施例是本发明一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域技术人员可以进行任何适当的修改或变型，从而获得的所有其它实施例。

须知，本说明书所附图式所绘示的结构、比例、大小等，均仅用以配合说明书所揭示的内容，以供熟悉此技术的人士了解与阅读，并非用以限定本发明可实施的限定条件，故不具技术上的实质意义，任何结构的修饰、比例关系的改变或大小的调整，在不影响本发明所能产生的功效及所能达成的目的下，均应仍落在本发明所揭示的技术内容得能涵盖的范围内。

随着企业业务发展，用户量与日俱增，传统单体架构的业务***逐渐臃肿，维护成本升高，性能和可维护性的提升到达瓶颈，开始采用传统微服务架构部署业务***。

在传统微服务架构下，业务***被拆解为若干个微服务应用，组成一个分布式***，各个微服务应用之间互相调用。为了确保业务***的性能和可用性，微服务应用通常会部署多个实例，并设置有服务注册中心来对业务***中的所有微服务应用进行注册，服务注册中心中记载了业务***中的所有微服务应用、每个微服务应用的所有实例、每个微服务应用的访问地址等信息。

传统微服务架构的业务***通常运行在虚拟机或者裸金属服务器中，不同虚拟机或者裸金属服务器的底层资源管理都是相对独立的，无法对底层资源进行统一的调度、部署、编排，也就无法实对底层资源的弹性调度。

随着云原生技术的快速发展，越来越多的企业选择将传统微服务架构的业务***迁移至容器云平台，尤其是随着以Kubernetes为代表的容器编排技术和以Istio为代表的服务网格技术的普及，使得容器云平台更加适合微服务架构的业务***的部署和运行。

具体来说，Kubernetes***是以Kubernetes为核心引擎的容器集群管理***，是能够为容器化的应用提供部署运行、资源调度、服务发现和动态伸缩等覆盖分布式***全生命周期运行和管理的云原生平台，能够实现应对高可用、高并发场景的底层资源弹性伸缩管理，因此许多企业开始尝试将传统微服务架构的业务***迁移至以Kubernetes集群为代表的容器云平台。

在云原生场景下，业务***由数百个微服务应用构成，并且微服务服务之间一直在频繁地动态相互调用。云原生场景下微服务应用的动态性也导致各个微服务实例的状态在不断地发生变化，由此对微服务应用的治理也提出了更加精细的管理要求。

为了满足云原生场景下对微服务应用的治理的精细化管理要求，一种基于容器云平台的新型微服务架构***——服务网格技术开始出现。服务网格是一个专门处理微服务应用实例之间通讯的基础设施层，其在传统微服务架构的基础上，抽象出一个基础设施层，以将微服务***中的数据面控制从业务***中剥离出来，无需在业务***内开发相关的数据面控制逻辑(例：对数据的限流、熔断、监控、鉴权等)，从而极大提升了业务***的开发生产效率。

服务网格技术的核心思想是为每个微服务应用实例设置一个轻量级的代理模块，由代理模块负责微服务应用实例的数据转发控制(例：对数据的限流、熔断、监控、鉴权等)，并且由其确保端对端的性能和可靠性。图1为服务网格的结构图，如图1所示，各个大矩形框中靠近左侧颜色较深的方块为微服务应用实例，各个大矩形框中靠近右侧颜色较浅的方块为Sidecar Proxy(边车模块，即代理模块，就如边车连接着摩托车一样，类似地服务网格架构中，边车模块是连接到微服务应用实例并且为其扩展或者增强功能)，微服务应用实例之间通过Sidecar Proxy进行通信，整个业务***的内部通信形成图中的网络连线，图1中的边车模块与网络连线组合后就形成了Service Mesh(即服务网格)。

使用服务网格架构进行业务***的开发可以让开发人员聚焦业务层面，无需关注微服务应用在技术层面的实现，从而降低业务***开发的技术门槛。

因此，越来越多的企业开始将传统微服务架构的业务***迁移至容器云平台，并采用服务网格架构进行微服务应用的部署。然而由于传统微服务架构和服务网格架构在技术架构上存在一定的差异，使得在将业务***迁移至Kubernetes集群为代表的容器云平台时，需要对业务***进行大量的适配性开发及改造，这极大地增加了业务***的迁移难度。

简单来说，按照容器云平台对资源隔离的要求，需要为业务***中的每个微服务应用配置命名空间和访问控制策略，而传统微服务架构中的服务注册中心并不支持配置命名空间和访问控制策略。

命名空间是一种对资源作用域范围的抽象，其作用在以Kubernetes集群为代表的容器云平台中，是对被管理的资源进行分类、筛选和管理的组织机制，当容器云平台中存在多个同名的资源对象时，可以通过命名空间进行隔离和区分。

具体来说，在传统微服务架构中，所有微服务应用实例在统一平面上进行寻址，没有基于命名空间的逻辑隔离机制，而容器云平台需要对资源进行隔离，相应地设置有基于命名空间机制的访问控制策略，要让业务***能够适配容器云平台的命名空间机制和访问控制策略，就要让业务***抛弃传统微服务架构中的服务注册中心，转而使用容器云平台的服务发现机制，这需要对业务***的服务注册和服务发现的代码逻辑结构进行大量修改。

此外，在云原生场景下，通常需要在同一个容器云平台中部署多个环境，比如可以将容器云平台划分为研发环境、测试环境、生产环境，并在每个环境中部署相同的业务***。容器云平台的命名空间机制可以将多个环境进行逻辑隔离，将不同环境中的业务***中相同名称的微服务应用实例进行区分，而传统微服务架构由于缺少基于命名空间的逻辑隔离机制，要在不同环境中部署业务***，就需要在容器云平台的不同命名空间下部署单独的服务注册中心，为该命名空间下的业务***提供服务注册和服务发现功能，增加了整个***的资源消耗。

为了解决现有生产实践中业务***迁移过程中存在的缺陷，申请人对传统微服务架构和容器云平台中的服务网格架构进行了深入分析。

如图2所示，传统微服务架构一般采用自发现模式，即客户端模式，每个微服务应用实例集成有服务注册中心对应的客户端，整个微服务应用实例之间的调用过程分为三个步骤：

步骤一、服务注册。每个微服务应用实例通过客户端连接服务注册中心，将本微服务应用实例的信息(比如访问地址、实例状态、提供的服务接口等信息)在服务注册中心中进行注册，并且与服务注册中心之间进行心跳保持(以便服务注册中心判断该微服务应用实例的状态)。

步骤二、服务发现。发起调用的微服务应用实例连接注册服务中心，查询和获取被调用的微服务应用实例的相关信息。

步骤三、服务调用。发起调用的微服务应用实例获取被调用的微服务应用实例的相关信息后，根据被调用的微服务应用实例的访问地址，连接被调用的微服务应用实例，进行微服务应用实例的调用通信。

如图3所示，在容器云平台中，所有微服务应用实例都被部署在容器组(Pod)中，以容器的形式运行。Pod是容器云平台进行调度的最小单位，由一个或者多个容器组成，同一个Pod中的所有容器共享存储、网络和命名空间，以及如何运行的规范。同一个Pod中的所有容器被一起安排和调度，并运行在共享的上下文中。对于具体微服务应用实例而言，Pod是它们的逻辑主机，Pod包含业务相关的多个业务容器。

在服务网格架构下，Pod中的所有微服务应用实例的网络数据都将被边车容器拦截，并且由边车容器中的数据网关进行封装、解封、转发等操作。

数据网关作为连接微服务应用实例和服务注册中心的必经之路，能够拦截微服务应用实例发出的网络数据并进行转发，能够与服务网格架构下的控制面进行通信，并通过控制面获取所在Pod的命名空间信息。

进一步地，图3中的watch表示监控，gRPC中的RPC是Remote Procedure Call的简称，中文叫远程过程调用，gRPC是由***开发的一个高性能、通用的开源RPC框架，主要面向移动应用开发且基于HTTP/2协议标准而设计，同时支持大多数流行的编程语言，gRPC基于HTTP/2协议传输。

基于对传统微服务架构和容器云平台中的服务网格架构的了解，本申请实施例提出了基于服务网格的支持命名空间感知的服务注册与发现的方法和***，实现将传统微服务架构的业务***平滑迁移至容器云平台中，并让业务***中的微服务应用实例能够适配服务网格架构。

为了便于说明，后文将微服务应用实例简称为服务。

基于前述说明可知，整个服务调用过程分为三个步骤：服务注册、服务发现和服务调用。在服务调用步骤中发起调用的服务可以根据被调用的服务的访问地址直接连接被调用的服务，因此整个服务调用过程的关键是让发起调用的服务获知被调用的服务的访问地址，而这正是服务注册和服务发现步骤所要实现的目的。

为了能够清楚地说明本申请实施例所提出的基于服务网格的支持命名空间感知的服务注册与发现的方法和***是如何让发起调用的服务获知被调用的服务的访问地址的，下面将对服务注册方法和服务发现方法的步骤进行分别说明。

图4为本申请实施例提出的一种基于服务网格的支持命名空间感知的服务注册方法的流程示意图。如图4所示，本申请实施例提出的一种基于服务网格的支持命名空间感知的服务注册方法，运行在容器云平台中，容器云平台包括第一容器组，第一容器组包括业务容器和边车容器，待注册服务部署在业务容器中，该方法包含以下步骤：

步骤S101，响应于接收到第一容器组发出的第一服务注册请求，对第一服务注册请求进行解析。

可以理解，服务注册过程即为待注册服务将自身的信息在服务注册中心进行注册的过程，待注册服务部署在第一容器组的业务容器中，因此待注册服务向服务注册中心发出的服务注册请求即为第一容器组发出的第一服务注册请求。

本申请实施例将容器云平台中的所有待注册服务进行分类，一类是需要使用命名空间机制的待注册服务，另一类则是无需使用命名空间机制的待注册服务。对于无需使用命名空间机制的待注册服务，可以和在传统微服务架构一样，直接将第一服务注册请求转发至服务注册中心，第一服务注册请求中不包含任何特征信息。而对于需要使用命名空间机制的待注册服务，第一服务注册请求包含有特征信息。

具体来说，本申请实施例对于需要使用命名空间机制的待注册服务，第一服务注册请求中包含有特征信息。对第一服务注册请求进行解析，即可判断该第一服务注册请求中是否包含待注册服务的特征信息，如果包含待注册服务的特征信息，则需要对该第一服务注册请求进行进一步处理。如果不包含任何特征信息，则直接将第一服务注册请求转发至服务注册中心。

步骤S102，响应于第一服务注册请求包含待注册服务的特征信息，使用待注册服务的特征信息生成待注册服务的服务标识信息。

其中，待注册服务的服务标识信息用于标识待注册服务，待注册服务的服务标识信息中包含待注册服务的命名空间信息。

具体来说，待注册服务的特征信息用于标识是否需要对第一服务注册请求进行进一步处理，特征信息可以以第一服务注册请求的Header头信息的形式存在。对第一服务注册请求进行解析后，根据第一服务注册请求的Header头信息是否包含特征信息，来判断是否需要对第一服务注册请求进行进一步处理。

比如说，特征信息可以是特定的字符串，比如dsmsp，当第一服务注册请求的Header头信息中包含dsmsp时，则确定需要对第一服务注册请求进行进一步处理。

对第一服务注册请求进行进一步处理具体为使用待注册服务的特征信息生成待注册服务的服务标识信息。

基于前述说明可知，在云原生场景下，通常需要在同一个容器云平台中部署多个环境，并在每个环境中部署相同的业务***，这就可能在同一个容器云平台中出现多个相同名称的服务，难以区分和识别，无法在同一个服务注册中心中进行注册。因此需要使用待注册服务的特征信息生成待注册服务的服务标识信息，作为待注册服务在整个容器云平台中的唯一标识。

需要特别说明的是，本申请实施例中第一服务注册请求的特征信息还包括待注册服务的命名空间信息，即第一容器组所属的命名空间以及相关信息。对第一服务注册请求进行解析即可从中分离出待注册服务的命名空间等相关信息，进而能够使用命名空间等相关信息生成的服务标识信息代替服务名称对待注册服务进行重新标识。

比如说，待注册服务的服务名称为abc，命名空间为ns01，工作负载为dep01，负载代理为ser01，那么按照预先设置的规则(即服务标识信息＝dsmsp::[NameSpace]::[Workload]::[Service]::[AppName])，生成的服务标识信息为dsmsp::ns01::deploy01::ser01::abc。使得待注册服务的服务标识信息中以特征信息参数的形式保留了待注册服务的命名空间以及相关信息。

步骤S103，使用待注册服务的服务标识信息向服务注册中心注册待注册服务。

其中，服务注册中心用于存储待注册服务的注册数据。

需要说明的是，由于本申请实施例要将传统微服务架构的业务***平滑迁移至容器云平台，因此直接将传统微服务架构的服务注册中心直接部署在容器云平台中，并使用步骤S102中生成的待注册服务的服务标识信息向服务注册中心注册待注册服务，服务注册中心采用传统微服务架构下相同的服务注册方式，将待注册服务的服务标识信息和第一服务注册请求中的其它数据信息，即待注册服务的注册信息，存储在服务注册中心中，以完成待注册服务的注册。

应当理解，在将传统微服务架构的业务***迁移至容器云平台后，对于不需要使用命名空间机制进行逻辑隔离的服务，其服务注册请求不含特征信息，也就无需生成对应的服务标识信息，直接使用服务名称在服务注册中心进行注册即可。

步骤S104，响应于待注册服务在服务注册中心注册成功，使用待注册服务的特征信息生成待注册服务对应的三元组数据，并将三元组数据存储至指定存储区域。

其中，三元组数据是指以三类数据字段(比如待注册服务所在节点名称、待注册服务的服务标识信息、待注册服务的服务名称)构成唯一索引的数据集合，三元组数据包括待注册服务的服务标识信息和待注册服务的虚拟服务地址。

表1为本申请实施例所提出的三元组数据的一个示例。

表1

表1注解：

HostName字段：由容器云平台的域名、命名空间、服务名称组成；

IPAddr+Port字段:由微服务应用实例的Cluster IP+TargetPort端口信息组成；

InstanceID字段：由命名空间+所在节点+服务名称组成；

Status字段：表示微服务应用实例的状态，当微服务应用实例发生异常或下线则为down，微服务应用实例正常则为up。

如表1所示，在三元组数据结构中，以三类数据字段构成该数据集合的唯一索引，所有类型的数据字段的值用于存储待注册服务的相关数据信息。

基于前述说明可知，在传统微服务架构中，服务发出的服务注册请求中包含服务的访问地址，而当业务***迁移至容器云平台之后，由于服务部署在容器组，第一服务注册请求中包含的服务的访问地址即为第一容器组的访问地址。

以Kubernetes***为代表的容器编排引擎能够进行服务的自动化部署和扩缩容，会导致服务的实际访问地址与服务注册中心中存储的访问地址不符。具体来说，待注册服务在注册时使用第一容器组的访问地址向服务注册中心进行注册，但容器云平台对服务进行重新调度之后，会将服务调度至其他容器组，而使得服务的实际访问地址发生变化。

为了解决这一问题，本申请实施例在待注册服务注册成功之后，根据待注册服务的服务标识信息和待注册服务的虚拟服务地址(ClusterIP)进行绑定，并以三元组数据的形式存储至指定存储区域。

需要说明的是，ClusterIP是一个虚拟IP地址，用于不同微服务应用对应的微服务应用实例之间相互访问，同一个微服务应用对应的所有微服务应用实例可共用同一个ClusterIP。

举例来说，鉴于本段说明涉及到微服务应用和微服务应用实例两个概念，为避免概念混淆，不再使用服务代替微服务应用实例进行说明。微服务应用A的实例为A1和A2，微服务应用B的实例为B1和B2，微服务应用A对应的ClusterIP为192.168.1.1，微服务应用B对应的ClusterIP为192.168.1.2，那么如果微服务应用实例A1要调用微服务应用B，则向微服务应用B对应的ClusterIP(192.168.1.2)发送调用请求，由微服务应用B的负载均衡组件根据微服务应用实例B1和B2的负载情况，将调用请求转发至微服务应用实例B1。也就是说，即便微服务应用实例A1不知道微服务应用实例B1的访问地址，仍可以通过微服务应用B对应的ClusterIP将调用请求发送至微服务应用实例B1，且微服务应用实例A1只要能够调用微服务应用B的任一实例即可满足需求。

基于此，本申请实施例将待注册服务的服务标识信息和第一容器组的访问地址作为待注册服务的注册数据，存储在服务注册中心中，而又将待注册服务的服务标识信息和待注册服务的ClusterIP以三元组数据的形式存储至指定存储区域，在服务发现和服务调用时，向发起调用的服务提供待调用服务的ClusterIP，以便发起调用的服务能够通过ClusterIP顺利访问待调用的服务。既保证了对注册服务中心的无侵入，即无需让注册服务中心增加动态感知服务的实际访问地址发生变化并动态更新注册数据的机制，降低注册服务中心与容器云平台的耦合性，又解决了容器云平台中服务的实际访问地址与服务注册中心中存储的访问地址不符的问题。

此外，如果待注册服务在服务注册中心注册失败，则结束待注册服务的本次注册，待注册服务可重新发起服务注册请求。

综上所述，本申请实施例所提出的一种基于服务网格的支持命名空间感知的服务注册方法，在接收到第一容器组发出的第一服务注册请求时，对第一服务注册请求进行解析。在第一服务注册请求包含待注册服务的特征信息时，使用待注册服务的特征信息生成待注册服务的服务标识信息，并使用待注册服务的服务标识信息向服务注册中心注册待注册服务。在待注册服务在服务注册中心注册成功时，使用待注册服务的特征信息生成待注册服务对应的三元组数据，并将三元组数据存储至指定存储区域。由此，实现了在将传统微服务架构的业务***迁移至容器云平台时，无需对业务***的服务注册和服务发现的代码逻辑结构进行改动，也无需对服务注册中心的服务注册机制进行修改，实现了业务***的平滑迁移。

进一步地，为了让本申请实施例中的第一服务注册请求中能够包含待注册服务的特征信息，本申请实施例提出了另一种基于服务网格的支持命名空间感知的服务注册方法，图5为本申请实施例提出的另一种基于服务网格的支持命名空间感知的服务注册方法的流程示意图。如图5所示，该方法运行在容器云平台中，待注册服务部署在容器云平台中的第一容器组中，第一容器组包括业务容器和边车容器，待注册服务部署在业务容器中，该方法包括：

步骤S201，边车容器对业务容器发出的第二服务注册请求进行拦截，并使用待注册服务的特征信息将第二服务注册请求封装为第一服务注册请求。

基于前述对服务网格架构的说明可知，服务网格技术为每个服务设置一个轻量级的代理模块，由代理模块负责服务的数据转发控制。本申请实施例中的第一容器组的边车容器中设置有代理模块，能够对第一容器组的业务容器中的待注册服务发出的第二服务注册请求进行拦截。

其中，第二服务注册请求为待注册服务在传统微服务架构下发出的服务注册请求，由于传统微服务架构下没有命名空间机制，因此将待注册服务迁移至容器云平台之后，第二服务注册请求中不包含待注册服务的命名空间信息等特征信息。

为了能够根据特征信息生成待注册服务的服务标识信息，并使用待注册服务的服务标识信息在服务注册中心进行注册，本申请实施例中的边车容器对第二服务注册请求进行解封，并结合待注册服务的特征信息对第二服务注册请求中的数据信息进行重新封装，以将待注册服务的特征信息添加至服务注册请求中，得到第一服务注册请求。

步骤S202，响应于接收到第一容器组发出的第一服务注册请求，对第一服务注册请求进行解析。

步骤S203，响应于第一服务注册请求包含待注册服务的特征信息，使用待注册服务的特征信息生成待注册服务的服务标识信息。

步骤S204，使用待注册服务的服务标识信息向服务注册中心注册待注册服务。

步骤S205，响应于待注册服务在服务注册中心注册成功，使用待注册服务的特征信息生成待注册服务对应的三元组数据，并将三元组数据存储至指定存储区域。

需要说明的是，对上述实施例中的步骤S101-步骤S104的解释说明，也适用于本申请实施例中的步骤S202-步骤S205，此处不再赘述。

由此，本申请实施例所提出的另一种基于服务网格的支持命名空间感知的服务注册方法，借助服务网格架构的边车容器，对待注册服务发出的第二服务注册请求进行拦截，并通过解封和重新封装的形式将待注册服务的特征信息添加至服务注册请求中，使得第一服务注册请求中包含待注册服务的命名空间信息。

进一步地，为了让边车容器能够对第二服务注册请求进行识别和拦截，本申请实施例提出了又一种基于服务网格的支持命名空间感知的服务注册方法，图6为本申请实施例提出的又一种基于服务网格的支持命名空间感知的服务注册方法的流程示意图。如图6所示，该方法运行在容器云平台中，待注册服务部署在容器云平台中的第一容器组中，第一容器组包括业务容器和边车容器，待注册服务部署在业务容器中，该方法包括：

步骤S301，边车容器从服务网格管理平台获取待注册服务的配置信息。

其中，配置信息包括识别信息和待注册服务的命名空间信息，识别信息用于从业务容器发出的请求中识别出第二服务注册请求。

识别信息具体包括访问地址信息、协议信息和策略信息，访问地址信息用于标识注册服务中心的访问地址、访问端口、接口名称、参数等，协议信息用于定义边车容器需要拦截的第二服务注册请求所使用的通信协议类型，例如http、dubbo-rpc、rmi、hessian等，策略信息用于定义边车容器识别出第二服务注册请求后，对第二服务注册请求进行处理的规则策略。

可以理解，边车容器能够对业务容器发出的所有请求进行转发控制，从中识别出第二服务注册请求并进行拦截，为了提升识别效率，本申请实施例预先为边车容器配置了对第二服务注册请求进行识别的策略，具体是根据请求所指向的访问地址和请求所使用的通信协议类型，识别出该请求为待注册服务发出的第二服务注册请求。

此外，边车容器还可以从服务网格管理平台获取待注册服务的虚拟服务地址，并在步骤S302中将待注册服务的虚拟服务地址和待注册服务的特征信息一并添加至第一服务注册请求中。在步骤S303中对第一服务注册请求进行解析时，从第一服务注册请求中分离出待注册服务的虚拟服务地址，以在步骤S306中将待注册服务的虚拟服务地址以三元组数据的形式存储至指定存储区域。

应当理解，服务网格管理平台运行在容器云平台中，是在服务网格架构下提供相关服务网格治理能力的平台。服务网格管理平台能够以无代码侵入的方式实现容器云平台中服务进行治理，容器云平台管理员可以通过服务网格管理平台的控制界面实现对服务的纳管、服务的注册与发现、服务治理、服务监控等功能进行配置。因此，边车容器可以从服务网格管理平台获取注册服务中心的访问地址、待注册服务的命名空间信息以及容器云平台管理员设定的通信协议类型、对第二服务注册请求进行处理的规则策略。

此外，如果待注册服务的命名空间信息发生变化，边车容器也可以从服务网格管理平台获取变化后的命名空间信息。

步骤S302，边车容器对业务容器发出的第二服务注册请求进行拦截，并使用待注册服务的特征信息将第二服务注册请求封装为第一服务注册请求。

步骤S303，响应于接收到第一容器组发出的第一服务注册请求，对第一服务注册请求进行解析。

步骤S304，响应于第一服务注册请求包含待注册服务的特征信息，使用待注册服务的特征信息生成待注册服务的服务标识信息。

步骤S305，使用待注册服务的服务标识信息向服务注册中心注册待注册服务。

步骤S306，响应于待注册服务在服务注册中心注册成功，使用待注册服务的特征信息生成待注册服务对应的三元组数据，并将三元组数据存储至指定存储区域。

需要说明的是，对上述实施例中的步骤S201-步骤S205的解释说明，也适用于本申请实施例中的步骤S302-步骤S306，此处不再赘述。

由此，实现了容器云平台管理员使用服务网格管理平台配置对第二服务注册请求的识别和拦截规则，以及对第二服务注册请求进行处理的规则策略，由边车容器从服务网格管理平台获取待注册服务的配置信息，对第二服务注册请求进行识别、拦截和处理。

进一步地，为了能够对已注册服务的运行状态进行实时监测，前述所有实施例中的未注册服务注册成功后即成为已注册服务，已注册服务对应的三元组数据包括已注册服务的运行状态，前述所有实施例提出的方法还包括：

步骤S401，从已注册服务接收心跳数据包。

步骤S402，响应于心跳数据包超时，将已注册服务对应的三元组数据中已注册服务的运行状态标记为异常。

基于前述对传统微服务架构下的服务注册的说明可知，服务需要与服务注册中心之间进行心跳保持，以便服务注册中心判断该服务的运行状态。

因此本申请实施例也需要从已注册服务接收心跳数据包，一旦心跳数据包超时，则需要对三元组数据中记载的已注册服务的运行状态进行更新，将运行状态标记为异常。

此外，由于在容器云平台中，所有服务部署在容器组中，当容器组出现异常时，部署其中的服务也将无法正常运行，因此前述所有实施例提出的方法还包括：

步骤S501，通过容器云平台的统一访问接口监听第一容器组的运行状态。

步骤S502，响应于第一容器组处于异常状态，将待注册服务对应的三元组数据删除。

具体地，可以通过容器云平台的统一访问接口(比如Kubernetes集群的API-Server组件)对容器云平台中的所有容器组的运行状态进行监听，当监听到第一容器组处于异常状态时，第一容器组中的待注册服务已无法被正常调用，可以将待注册服务对应的三元组数据删除。

需要说明的是，当出现心跳数据包超时的情况，可能是因为已注册服务发生故障，无法正常运行，也可能是因为网络通信故障，导致心跳数据包丢失，因此只需在三元组数据中将已注册服务的运行状态标记为异常，同时通过容器云平台的统一访问接口进一步对已注册服务所在的容器组的运行状态进行验证。

而如果通过容器云平台的统一访问接口监听到第一容器组的运行状态为异常，则可以确认第一容器组中的待注册服务已无法被正常调用，可以将待注册服务对应的三元组数据删除，以节省存储资源。

为了更加清楚地说明本申请实施例所提出的上述方法，下面进行举例说明。图7为本申请实施例所提出的基于服务网格的支持命名空间感知的服务注册方法的一个示例的逻辑示意图，如图7所示，容器云平台中部署有第一容器组、服务注册***、服务网络控制器、服务网关配置控制器、服务网格管理平台，服务注册***包括服务注册适配控制器、服务注册中心、服务数据存储控制器，服务注册适配控制器又具体包括服务注册适配模块和服务状态适配模块，本申请实施例所提出的上述方法步骤主要由服务注册适配控制器执行。第一容器组包括业务容器和边车容器，服务A部署在业务容器中，源负载控制器部署在边车容器中。

如图8所示，容器云平台管理员首先在服务网格管理平台中设定服务注册请求的通信协议类型，以及对服务注册请求进行处理的规则策略，由服务网关配置控制器周期性地从服务网格管理平台查询服务注册中心的访问地址、需要拦截的请求所使用通信协议类型、服务A的命名空间信息、服务A的ClusterIP，并根据这些信息中的相关参数组合成适配容器云平台的声明式API配置，以及调用服务网格控制器来执行该声明式API配置，将相关参数通过管理数据通道下发到源负载控制器，声明式API配置的相关代码如图9所示。源负载控制器在启动时，即根据接收到的相关参数进行初始化配置，在运行时按照配置参数对服务A发出的服务注册请求进行识别、拦截和处理，并将源负载控制器的状态信息通过管理数据通道定期同步至服务网格管理平台。

需要说明的是，由于服务网格管理平台和源负载控制器之间不能直接进行通信，并且运行机制也不一样，因此对源负载控制器的配置管理、下发、控制工作需要由服务网关配置控制器来承担。

继续参考图7，部署在第一容器组的业务容器中的服务A启动时，将主动向服务注册中心发出服务注册请求，部署在第一容器组的边车容器中的源负载控制器根据预先配置的服务注册中心的访问地址和通信协议类型等信息识别出该请求的类型为服务注册请求，即对该服务注册请求进行拦截，并对服务注册请求进行解封和重新封装，以将服务A的命名空间信息、所在节点信息等特征信息，以及服务A的ClusterIP加入该服务注册请求，并将特定字符串写入服务注册请求的Header头信息。

源负载控制器在完成对服务注册请求的重新封装后，即将服务注册请求发送至服务注册中心。如图10所示，服务注册适配控制器中的服务注册适配模块对发向服务注册中心的服务注册请求进行劫持，并对服务注册请求进行解析，从中分离出服务A的命名空间信息、所在节点信息等特征信息，以及服务A的ClusterIP，并根据服务注册请求的Header头信息判断是否需要根据服务A的命名空间等特征信息为服务A生成新的id。

如图11所示，如果服务注册请求的Header头信息包含特定字符串，则按照预先设置的规则，使用特征信息生成服务A的新id，并为从服务注册请求中分离出的服务A的命名空间等特征信息和服务A的ClusterIP，与服务A的新id之间建立映射关系，以及使用服务A的新id在服务注册中心进行注册。如果服务注册请求的Header头信息不含特定字符串，则直接使用服务A的服务名称在服务注册中心进行注册。

在使用服务A的新id在服务注册中心成功注册后，服务注册适配控制器将服务A的命名空间等特征信息和服务A的ClusterIP与服务A的新id之间的映射关系转发至服务数据存储控制器，由服务数据存储控制器将这些信息以三元组数据的形式在内存中进行缓存。考虑到服务A的这些信息经常发生变化，因此可以不对这些信息进行数据持久化处理。

如图12所示，服务数据存储控制器在将服务A对应的三元组数据以内存的形式进行存储后，持续通过容器云平台的统一接口实时监测服务A所在的第一容器组的运行状态，一旦监测到第一容器组处于异常状态，立即对内存中服务A对应的三元组数据进行删除。

进一步地，考虑到容器云平台中的容器组由Deployment进行部署，且由Deployment部署的对象数量庞大，本申请实施例采用定时轮询(默认轮询间隔为1分钟)的方式三元组数据进行更新。

如图13所示，通过容器云平台的统一接口获取Deployment部署的所有对象，生成Deployment对象列表，将三元组数据依次与Deployment对象列表进行比对，如果该三元组数据无法在Deployment对象列表找到，说明该三元组数据已经过期，删除该三元组数据，如果该三元组数据可以在Deployment对象列表找到，则根据容器组的运行状态，对三元组数据进行更新。

继续参考图7，部署在第一容器组的服务A在服务注册中心成功注册后，周期性地持续向服务注册中心发送心跳数据包，服务注册适配控制器中的服务状态适配模块对发向服务注册中心的心跳数据包进行劫持和检测，一旦检测到心跳数据包超时，即调用服务数据存储控制器将内存中服务A对应的三元组数据中记载的服务A的状态标记为异常，并通过容器云平台的统一接口主动查询服务A所在的第一容器组的运行状态是否异常，如果第一容器组处于异常状态，立即对内存中服务A对应的三元组数据进行删除。

图14为本申请实施例提出的一种基于服务网格的支持命名空间感知的服务发现方法的流程示意图。如图14所示，本申请实施例提出的一种基于服务网格的支持命名空间感知的服务发现方法，该方法运行在容器云平台中，发起调用的服务部署在容器云平台中的第二容器组中，该方法包括以下步骤：

步骤S601，响应于接收到第二容器组发出的第一服务调用请求，对第一服务调用请求进行解析。

基于前述说明可知，整个服务调用过程分为服务注册、服务发现和服务调用三个步骤。通过服务注册可以让待注册服务的访问地址存储在服务注册***中，通过服务发现可以让发起调用的服务从服务注册***中获取待调用服务的访问地址，以在服务调用时对待调用服务实现调用通信。

应当理解，在服务发现阶段，部署在第一容器组中待调用服务已成功在服务注册中心完成注册，使得部署在第二容器组中的服务能够对待调用服务进行服务发现，因此发起调用的服务向服务注册中心发出的服务调用请求即为第二容器组发出的第一服务调用请求。

基于前述说明可知，如果待调用服务没有使用命名空间机制，则待调用服务直接使用服务名称在服务注册中心进行了注册。相应地，在对待调用服务进行服务发现时，第一服务调用请求中不包含任何特征信息。而如果待调用服务使用了命名空间机制，则待调用服务使用了服务标识信息在服务注册中心进行了注册。相应地，在对待调用服务进行服务发现时，第一服务调用请求中包含有特征信息。

具体来说，本申请实施例对于使用了命名空间机制的待调用服务，第一服务调用请求中包含有特征信息。对第一服务调用请求进行解析，即可判断该第一服务调用请求中是否包含待调用服务的特征信息，如果包含待调用服务的特征信息，则需要对该第一服务调用请求进行进一步处理。如果不包含任何特征信息，则直接将第一服务调用请求转发至服务注册中心。

步骤S602，响应于第一服务调用请求包含待调用服务的特征信息，从服务注册中心获取所有服务的注册数据，以及使用待调用服务的特征信息，从预设存储区域获取待调用服务对应的三元组数据。

和服务注册方法相类似，特征信息可以以第一服务调用请求的Header头信息的形式存在。对第一服务调用请求进行解析后，根据第一服务调用请求的Header头信息是否包含特征信息，来判断是否需要从第一服务调用请求中分离出待调用服务的命名空间等特征信息。

应当理解，在服务注册过程中，对于使用了命名空间机制的待调用服务，使用了服务标识信息在服务注册中心进行了注册，并以三元组数据的形式将待调用服务的服务标识信息和虚拟服务地址在指定存储区域进行存储。相应地，服务注册中心存储有待调用服务的注册数据，该注册数据中待调用服务的访问地址为所在容器组的IP地址，三元组数据中包括待调用服务的服务标识信息和虚拟服务地址。

也就是说，在注册数据中，各服务所在容器组的IP地址为各服务的访问地址，待调用服务对应的三元组数据由待调用服务注册时生成，待调用服务对应的三元组数据包括待调用服务的服务标识信息和虚拟服务地址。

本申请实施例可以通过服务注册中心提供的访问接口获取所有服务的注册数据，并从中检索出待调用服务的注册数据。

基于前述说明可知，三元组数据是指以三类数据字段(比如待调用服务所在节点名称、待调用服务的服务标识信息、服务名称)构成唯一索引的数据集合，而待调用服务的服务标识信息是在待调用服务注册时使用特征信息生成的，而服务标识信息中又以特征信息参数的形式保留了待调用服务的特征信息。因此可以使用待调用服务的命名空间等特征信息在预设存储区域中存储的所有三元组数据中检索出待调用服务对应的三元组数据。而待调用服务对应的三元组数据包括待调用服务的服务标识信息，从而获得待调用服务的服务标识信息。

步骤S603，使用待调用服务的服务标识信息与所有服务的注册数据进行匹配。

由于待调用服务使用服务标识信息在服务注册中心进行注册，待调用服务的注册数据中包含对应的服务标识信息，因此可以直接使用待调用服务的服务标识信息与所有服务的注册数据进行匹配。

步骤S604，响应于待调用服务的服务标识信息与注册数据匹配成功，使用待调用服务的虚拟服务地址代替待调用服务所在容器组的IP地址，作为待调用服务的访问地址，并将待调用服务的访问地址返回给发起调用的服务。

应当理解，待调用服务的注册数据中除了有访问地址以外，还包括其它的数据信息，因此本申请实施例仅将待调用服务的访问地址由所在容器组的IP地址替换为虚拟服务地址，对于其它的数据信息不做变动。在完成对访问地址的替换后，就将待调用服务的注册数据返回给发起调用的服务。

基于前述说明可知，向发起调用的服务提供待调用服务的虚拟服务地址(ClusterIP)，能够让发起调用的服务能够通过ClusterIP顺利访问待调用的服务。既保证了对注册服务中心的无侵入，即无需让注册服务中心增加动态感知服务的实际访问地址发生变化并动态更新注册数据的机制，降低注册服务中心与容器云平台的耦合性，又解决了容器云平台中服务的实际访问地址与服务注册中心中存储的访问地址不符的问题。

综上所述，本申请实施例所提出的一种基于服务网格的支持命名空间感知的服务发现方法，在接收到第二容器组发出的第一服务调用请求时，对第一服务调用请求进行解析。在第一服务调用请求包含待调用服务的特征信息时，从服务注册中心获取所有服务的注册数据，以及使用待调用服务的特征信息，从预设存储区域获取待调用服务对应的三元组数据。并使用待调用服务的服务标识信息与所有服务的注册数据进行匹配，在待调用服务的服务标识信息与注册数据匹配成功时，使用待调用服务的虚拟服务地址代替待调用服务所在容器组的IP地址，作为待调用服务的访问地址，并将待调用服务的访问地址返回给发起调用的服务。由此，实现了在将传统微服务架构的业务***迁移至容器云平台时，无需对业务***的服务注册和服务发现的代码逻辑结构进行改动，也无需对服务注册中心的服务发现机制进行修改，实现了业务***的平滑迁移。

进一步地，为了让本申请实施例中的第一服务调用请求中能够包含待调用服务的特征信息，本申请实施例提出了另一种基于服务网格的支持命名空间感知的服务发现方法，图15为本申请实施例提出的另一种基于服务网格的支持命名空间感知的服务发现方法的流程示意图。如图15所示，该方法运行在容器云平台中，发起调用的服务部署在容器云平台中的第二容器组中，第二容器组包括业务容器和边车容器，发起调用的服务部署在业务容器中，该方法包括：

步骤S701，边车容器对业务容器发出的第二服务调用请求进行拦截，并使用待调用服务的特征信息将第二服务调用请求封装为第一服务调用请求。

和服务注册方法相类似，本申请实施例中的第二容器组的边车容器中也设置有代理模块，能够对第二容器组的业务容器中的发起调用的服务发出的第二服务调用请求进行拦截。

其中，第二服务调用请求为发起调用的服务在传统微服务架构下发出的服务调用请求，由于传统微服务架构下没有命名空间机制，因此将发起调用的服务迁移至容器云平台之后，第二服务调用请求中不包含待调用服务的命名空间信息等特征信息。

为了能够使用待调用服务的特征信息，从预设存储区域获取待调用服务对应的三元组数据，本申请实施例中的边车容器对第二服务调用请求进行解封，并结合待调用服务的特征信息对第二服务调用请求中的数据信息进行重新封装，以将待调用服务的特征信息添加至服务调用请求中，得到第一服务调用请求。

步骤S702，响应于接收到第二容器组发出的第一服务调用请求，对第一服务调用请求进行解析。

步骤S703，响应于第一服务调用请求包含待调用服务的特征信息，从服务注册中心获取所有服务的注册数据，以及使用待调用服务的特征信息，从预设存储区域获取待调用服务对应的三元组数据。

步骤S704，使用待调用服务的服务标识信息与所有服务的注册数据进行匹配。

步骤S705，响应于待调用服务的服务标识信息与注册数据匹配成功，使用待调用服务的虚拟服务地址代替待调用服务所在容器组的IP地址，作为待调用服务的访问地址，并将待调用服务的访问地址返回给发起调用的服务。

需要说明的是，对上述实施例中的步骤S601-步骤S604的解释说明，也适用于本申请实施例中的步骤S702-步骤S705，此处不再赘述。

由此，本申请实施例所提出的另一种基于服务网格的支持命名空间感知的服务发现方法，借助服务网格架构的边车容器，对发起调用的服务发出的第二服务调用请求进行拦截，并通过解封和重新封装的形式将待调用服务的特征信息添加至服务调用请求中，使得第一服务调用请求中包含待调用服务的命名空间信息。

进一步地，为了让边车容器能够对第二服务调用请求进行识别和拦截，本申请实施例提出了又一种基于服务网格的支持命名空间感知的服务发现方法，图16为本申请实施例提出的又一种基于服务网格的支持命名空间感知的服务发现方法的流程示意图。如图16所示，该方法运行在容器云平台中，发起调用的服务部署在容器云平台中的第二容器组中，第二容器组包括业务容器和边车容器，发起调用的服务部署在业务容器中，该方法包括：

步骤S801，边车容器从服务网格管理平台获取所有服务的配置信息。

其中，配置信息包括识别信息和所有服务的命名空间信息，识别信息用于从业务容器发出的请求中识别出第二服务调用请求。

可以理解，由于本申请实施例允许发起调用的服务对容器云平台中的其他所有服务进行调用，因此需要边车容器预先从服务网格管理平台获取所有服务的配置信息。

基于前述说明可知，存在部分服务没有使用命名空间机制，也就无法从服务网格管理平台获取这些服务的识别信息和命名空间信息。

和服务注册方法相类似，识别信息具体包括访问地址信息、协议信息和策略信息，访问地址信息用于标识注册服务中心的访问地址、访问端口、接口名称、参数等，协议信息用于定义边车容器需要拦截的第二服务调用请求所使用的通信协议类型，例如http、dubbo-rpc、rmi、hessian等，策略信息用于定义边车容器识别出第二服务调用请求后，对第二服务调用请求进行处理的规则策略。

可以理解，边车容器能够对业务容器发出的所有请求进行转发控制，从中识别出第二服务调用请求并进行拦截，为了提升识别效率，本申请实施例预先为边车容器配置了对第二服务调用请求进行识别的策略，具体是根据请求所指向的访问地址和请求所使用的通信协议类型，识别出该请求为发起调用的服务发出的第二服务调用请求。

此外，边车容器还可以从服务网格管理平台获取所有服务的url地址信息，并在步骤S802中根据第二服务调用请求中的服务url地址信息，确定第二服务调用请求指向待调用服务，从而从所有服务的特征信息中确定待调用服务的特征信息，添加至第一服务调用请求中。

步骤S802，边车容器对业务容器发出的第二服务调用请求进行拦截，并使用待调用服务的特征信息将第二服务调用请求封装为第一服务调用请求。

步骤S803，响应于接收到第二容器组发出的第一服务调用请求，对第一服务调用请求进行解析。

步骤S804，响应于第一服务调用请求包含待调用服务的特征信息，从服务注册中心获取所有服务的注册数据，以及使用待调用服务的特征信息，从预设存储区域获取待调用服务对应的三元组数据。

步骤S805，使用待调用服务的服务标识信息与所有服务的注册数据进行匹配。

步骤S806，响应于待调用服务的服务标识信息与注册数据匹配成功，使用待调用服务的虚拟服务地址代替待调用服务所在容器组的IP地址，作为待调用服务的访问地址，并将待调用服务的访问地址返回给发起调用的服务。

需要说明的是，对上述实施例中的步骤S701-步骤S705的解释说明，也适用于本申请实施例中的步骤S802-步骤S806，此处不再赘述。

由此，实现了容器云平台管理员使用服务网格管理平台配置对第二服务调用请求的识别和拦截规则，以及对第二服务调用请求进行处理的规则策略，由边车容器从服务网格管理平台获取所有服务的配置信息，对第二服务调用请求进行识别、拦截和处理。

为了更加清楚地说明本申请实施例所提出的上述方法，下面进行举例说明。图17为本申请实施例所提出的基于服务网格的支持命名空间感知的服务发现方法的一个示例的逻辑示意图，如图17所示，容器云平台中部署有第一容器组、第二容器组、服务注册***、服务网络控制器、服务网关配置控制器、服务网格管理平台，服务注册***包括服务注册适配控制器、服务注册中心、服务数据存储控制器，服务注册适配控制器又具体包括服务注册适配模块和服务状态适配模块，本申请实施例所提出的上述方法步骤主要由服务注册适配控制器执行。第一容器组和第二容器组都包括业务容器和边车容器，服务A和服务B分别部署在第一容器组和第二容器组的业务容器中，源负载控制器部署在第一容器组和第二容器组的边车容器中。

容器云平台管理员首先在服务网格管理平台中设定服务调用请求的通信协议类型，以及对服务调用请求进行处理的规则策略，由服务网关配置控制器周期性地从服务网格管理平台查询服务注册中心的访问地址、需要拦截的请求所使用通信协议类型、所有服务的命名空间信息，并根据这些信息中的相关参数组合成适配容器云平台的声明式API配置，以及调用服务网格控制器来执行该声明式API配置，将相关参数通过管理数据通道下发到第二容器组的边车容器中的源负载控制器。第二容器组的边车容器中的源负载控制器在启动时，即根据接收到的相关参数进行初始化配置，在运行时按照配置参数对服务B发出的服务调用请求进行识别、拦截和处理，并将源负载控制器的状态信息通过管理数据通道定期同步至服务网格管理平台。

部署在第二容器组的业务容器中的服务B向服务注册中心发出对服务A的服务调用请求，部署在第二容器组的边车容器中的源负载控制器根据预先配置的服务注册中心的访问地址和通信协议类型等信息识别出该请求的类型为服务调用请求，即对该服务调用请求进行拦截，并对服务调用请求进行解封和重新封装，根据服务调用请求中的服务url地址信息确定该服务调用请求指向服务A，将服务A的命名空间信息、所在节点信息等特征信息加入该服务调用请求，并将特定字符串写入服务调用请求的Header头信息。

源负载控制器在完成对服务调用请求的重新封装后，即将服务调用请求发送至服务注册中心。服务注册适配控制器中的服务注册适配模块对发向服务注册中心的服务调用请求进行劫持，并对服务调用请求进行解析。根据服务调用请求的Header头信息判断是否需要从服务调用请求中分离出服务A的命名空间信息、所在节点信息等特征信息。

如图18所示，如果服务调用请求的Header头信息包含特定字符串，则通过服务注册中心提供的访问接口获取所有服务的注册数据，并使用服务A的命名空间信息、所在节点信息等特征信息获取服务A对应的三元组数据。进而可以从服务A对应的三元组数据中获取服务A的id和ClusterIP，使用服务A的id与所有服务的注册数据进行匹配，即可得到服务A的注册数据，将服务A的注册数据中的第一容器组的IP地址替换为服务A的ClusterIP，从而使用服务A的ClusterIP作为服务A的访问地址返回给服务B，服务B即可使用服务A的ClusterIP向服务A发起调用通信。

如果服务调用请求的Header头信息不含特定字符串，则通过服务注册中心提供的访问接口获取所有服务的注册数据，并使用服务A的服务名称与所有服务的注册数据进行匹配，将得到的服务A的注册数据直接返回给服务B。

本申请实施例还提供一种基于服务网格的支持命名空间感知的服务注册***，以执行基于服务网格的支持命名空间感知的服务注册方法。如图19所示，该基于服务网格的支持命名空间感知的服务注册***部署在容器云平台中，容器云平台中包括第一容器组，第一容器组内部署有待注册服务；该基于服务网格的支持命名空间感知的服务注册***包括：第一解析模块910，第一生成模块920，注册模块930，第二生成模块940，存储模块950。

第一解析模块910，用于在接收到第一容器组发出的第一服务注册请求时，对第一服务注册请求进行解析。

第一生成模块920，用于在第一服务注册请求包含待注册服务的特征信息时，使用待注册服务的特征信息生成待注册服务的服务标识信息；待注册服务的服务标识信息用于标识待注册服务，待注册服务的服务标识信息中包含待注册服务的命名空间信息。

注册模块930，用于使用待注册服务的服务标识信息向服务注册中心注册待注册服务；服务注册中心用于存储待注册服务的注册数据。

第二生成模块940，用于在待注册服务在服务注册中心注册成功时，使用待注册服务的特征信息生成待注册服务对应的三元组数据；三元组数据包括待注册服务的服务标识信息和待注册服务的虚拟服务地址。

存储模块950，用于将三元组数据存储至指定存储区域。

可选的，第一容器组包括业务容器和边车容器，待注册服务部署在业务容器中，服务注册***还包括拦截封装模块，拦截封装模块部署在边车容器中，边车模块用于在第一解析模块910接收到第一容器组发出的第一服务注册请求，对第一服务注册请求进行解析之前，对业务容器发出的第二服务注册请求进行拦截，并使用待注册服务的特征信息将第二服务注册请求封装为第一服务注册请求。

可选的，拦截封装模块包括获取单元，获取单元用于在拦截封装模块对业务容器发出的第二服务注册请求进行拦截之前，从服务网格管理平台获取待注册服务的配置信息；配置信息包括识别信息和待注册服务的命名空间信息，识别信息用于从业务容器发出的请求中识别出第二服务注册请求。

可选的，待注册服务对应的三元组数据还包括待注册服务的运行状态，服务注册***还包括标记模块，标记模块用于从待注册服务接收心跳数据包；在心跳数据包超时时，将待注册服务对应的三元组数据中待注册服务的运行状态标记为异常。

可选的，服务注册***还包括删除模块，用于通过容器云平台的统一访问接口监听第一容器组的运行状态；在第一容器组处于异常状态时，将待注册服务对应的三元组数据删除。

本申请实施例还提供一种基于服务网格的支持命名空间感知的服务发现***，以执行基于服务网格的支持命名空间感知的服务发现方法。如图20所示，该基于服务网格的支持命名空间感知的服务发现***部署在容器云平台中，容器云平台中包括第二容器组，第二容器组内部署有发起调用的服务；该基于服务网格的支持命名空间感知的服务发现***包括：第二解析模块1010，获取模块1020，匹配模块1030，替换模块1040，返回模块1050。

第二解析模块1010，用于在接收到第二容器组发出的第一服务调用请求时，对第一服务调用请求进行解析。

获取模块1020，用于在第一服务调用请求包含待调用服务的特征信息时，从服务注册中心获取所有服务的注册数据，以及使用待调用服务的特征信息，从预设存储区域获取待调用服务对应的三元组数据；在注册数据中，各服务所在容器组的IP地址为各服务的访问地址，待调用服务对应的三元组数据由待调用服务注册时生成，待调用服务对应的三元组数据包括待调用服务的服务标识信息和虚拟服务地址。

匹配模块1030，用于使用待调用服务的服务标识信息与所有服务的注册数据进行匹配。

替换模块1040，用于在待调用服务的服务标识信息与注册数据匹配成功时，使用待调用服务的虚拟服务地址代替待调用服务所在容器组的IP地址，作为待调用服务的访问地址。

返回模块1050，用于将待调用服务的访问地址返回给发起调用的服务。

本申请实施例还提供一种机器可读存储介质，其上存储有可执行指令，可执行指令在被机器执行时使得机器实现上面方法实施例中的基于服务网格的支持命名空间感知的服务注册方法的具体过程。

本申请实施例还提供一种机器可读存储介质，其上存储有可执行指令，可执行指令在被机器执行时使得机器实现上面方法实施例中的基于服务网格的支持命名空间感知的服务发现方法的具体过程。

本申请实施例还提供一种电子设备，其中存储有计算机程序，该计算机程序被处理器执行时实现上面方法实施例中的基于服务网格的支持命名空间感知的服务注册方法的具体过程。该计算机程序可以通过通信装置从网络上被下载和安装，或者从存储装置被安装，或者从ROM被安装。

本申请实施例还提供一种电子设备，其中存储有计算机程序，该计算机程序被处理器执行时实现上面方法实施例中的基于服务网格的支持命名空间感知的服务发现方法的具体过程。该计算机程序可以通过通信装置从网络上被下载和安装，或者从存储装置被安装，或者从ROM被安装。

本申请上述的计算机可读存储介质可以是单独的计算机可读存储介质，也可以是计算机可读信号介质，或者是上述两者的任意组合。计算机可读存储介质例如可以是——但不限于——电、磁、光、电磁、红外线、或半导体的***、装置或器件，或者任意以上的组合。计算机可读存储介质的更具体的例子可以包括但不限于：具有一个或多个导线的电连接、便携式计算机磁盘、硬盘、随机访问存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、光纤、便携式紧凑磁盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。在本申请中，计算机可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行***、装置或者器件使用或者与其结合使用。而在本申请中，计算机可读信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了计算机可读的程序代码。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。计算机可读信号介质还可以是计算机可读存储介质以外的任何计算机可读介质，该计算机可读信号介质可以发送、传播或者传输用于由指令执行***、装置或者器件使用或者与其结合使用的程序。计算机可读介质上包含的程序代码可以用任何适当的介质传输，包括但不限于：电线、光缆、RF(射频)等等，或者上述的任意合适的组合。

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

以上详细描述了本发明的较佳具体实施例。应当理解，本领域的普通技术无需创造性劳动就可以根据本发明的构思作出诸多修改和变化。因此，凡本技术领域中技术人员依本发明的构思在现有技术的基础上通过逻辑分析、推理或者有限的实验可以得到的技术方案，皆应在由权利要求书所确定的保护范围内。

Claims (9)

1.一种基于服务网格的支持命名空间感知的服务注册方法，其特征在于，所述方法运行在容器云平台中，待注册服务部署在所述容器云平台中的第一容器组中，所述方法包含以下步骤：

响应于接收到所述第一容器组发出的第一服务注册请求，对所述第一服务注册请求进行解析；

响应于所述第一服务注册请求包含所述待注册服务的特征信息，使用所述待注册服务的特征信息生成所述待注册服务的服务标识信息；所述待注册服务的服务标识信息用于标识所述待注册服务，所述待注册服务的服务标识信息中包含所述待注册服务的命名空间信息；

使用所述待注册服务的服务标识信息向服务注册中心注册所述待注册服务；所述服务注册中心用于存储所述待注册服务的注册数据；

响应于所述待注册服务在所述服务注册中心注册成功，使用所述待注册服务的特征信息生成所述待注册服务对应的三元组数据，并将所述三元组数据存储至指定存储区域；所述三元组数据包括所述待注册服务的服务标识信息和所述待注册服务的虚拟服务地址；

所述第一容器组包括业务容器和边车容器，所述待注册服务部署在所述业务容器中，

在所述响应于接收到所述第一容器组发出的第一服务注册请求，对所述第一服务注册请求进行解析之前，所述方法还包括：

所述边车容器对所述业务容器发出的第二服务注册请求进行拦截，并使用所述待注册服务的特征信息将所述第二服务注册请求封装为所述第一服务注册请求。

2.根据权利要求1所述的基于服务网格的支持命名空间感知的服务注册方法，其特征在于，在所述边车容器对所述业务容器发出的第二服务注册请求进行拦截之前，所述方法还包括：

所述边车容器从服务网格管理平台获取所述待注册服务的配置信息；所述配置信息包括识别信息和所述待注册服务的命名空间信息，所述识别信息用于从所述业务容器发出的请求中识别出所述第二服务注册请求。

3.根据权利要求1所述的基于服务网格的支持命名空间感知的服务注册方法，其特征在于，已注册服务对应的三元组数据包括所述已注册服务的运行状态，所述方法还包括：

从所述已注册服务接收心跳数据包；

响应于所述心跳数据包超时，将所述已注册服务对应的三元组数据中所述已注册服务的运行状态标记为异常。

4.根据权利要求1-3中任一项所述的基于服务网格的支持命名空间感知的服务注册方法，其特征在于，所述方法还包括：

通过所述容器云平台的统一访问接口监听所述第一容器组的运行状态；

响应于所述第一容器组处于异常状态，将所述待注册服务对应的三元组数据删除。

5.一种基于服务网格的支持命名空间感知的服务发现方法，其特征在于，所述方法运行在容器云平台中，发起调用的服务部署在所述容器云平台中的第二容器组中，所述方法包含以下步骤：

响应于接收到所述第二容器组发出的第一服务调用请求，对所述第一服务调用请求进行解析；

响应于所述第一服务调用请求包含待调用服务的特征信息，从服务注册中心获取所有服务的注册数据，以及使用所述待调用服务的特征信息，从预设存储区域获取所述待调用服务对应的三元组数据；在所述注册数据中，各所述服务所在容器组的IP地址为各所述服务的访问地址，所述待调用服务对应的三元组数据由所述待调用服务注册时生成，所述待调用服务对应的三元组数据包括所述待调用服务的服务标识信息和虚拟服务地址；

使用所述待调用服务的服务标识信息与所述所有服务的注册数据进行匹配；

响应于所述待调用服务的服务标识信息与所述注册数据匹配成功，使用所述待调用服务的虚拟服务地址代替所述待调用服务所在容器组的IP地址，作为所述待调用服务的访问地址，并将所述待调用服务的访问地址返回给所述发起调用的服务；

所述第二容器组包括业务容器和边车容器，所述发起调用的服务部署在所述业务容器中，

在所述响应于接收到所述第二容器组发出的第一服务调用请求，对所述第一服务调用请求进行解析之前，所述方法还包括：

所述边车容器对所述业务容器发出的第二服务调用请求进行拦截，并使用所述待调用服务的特征信息将所述第二服务调用请求封装为所述第一服务调用请求。

6.一种基于服务网格的支持命名空间感知的服务注册***，其特征在于，所述服务注册***部署在容器云平台中，所述容器云平台中包括第一容器组，所述第一容器组内部署有待注册服务；所述服务注册***包括：

第一解析模块，用于在接收到所述第一容器组发出的第一服务注册请求时，对所述第一服务注册请求进行解析；

第一生成模块，用于在所述第一服务注册请求包含所述待注册服务的特征信息时，使用所述待注册服务的特征信息生成所述待注册服务的服务标识信息；所述待注册服务的服务标识信息用于标识所述待注册服务，所述待注册服务的服务标识信息中包含所述待注册服务的命名空间信息；

注册模块，用于使用所述待注册服务的服务标识信息向所述服务注册中心注册所述待注册服务；所述服务注册中心用于存储所述待注册服务的注册数据；

第二生成模块，用于在所述待注册服务在所述服务注册中心注册成功时，使用所述待注册服务的特征信息生成所述待注册服务对应的三元组数据；所述三元组数据包括所述待注册服务的服务标识信息和所述待注册服务的虚拟服务地址；

存储模块，用于将所述三元组数据存储至指定存储区域；

所述第一容器组包括业务容器和边车容器，所述待注册服务部署在所述业务容器中，

在响应于接收到所述第一容器组发出的第一服务注册请求，对所述第一服务注册请求进行解析之前，所述边车容器对所述业务容器发出的第二服务注册请求进行拦截，并使用所述待注册服务的特征信息将所述第二服务注册请求封装为所述第一服务注册请求。

7.一种基于服务网格的支持命名空间感知的服务发现***，其特征在于，所述服务发现***部署在容器云平台中，所述容器云平台中包括第二容器组，所述第二容器组内部署有发起调用的服务；所述服务发现***包括：

第二解析模块，用于在接收到所述第二容器组发出的第一服务调用请求时，对所述第一服务调用请求进行解析；

获取模块，用于在所述第一服务调用请求包含待调用服务的特征信息时，从服务注册中心获取所有服务的注册数据，以及使用所述待调用服务的特征信息，从预设存储区域获取所述待调用服务对应的三元组数据；在所述注册数据中，各所述服务所在容器组的IP地址为各所述服务的访问地址，所述待调用服务对应的三元组数据由所述待调用服务注册时生成，所述待调用服务对应的三元组数据包括所述待调用服务的服务标识信息和虚拟服务地址；

匹配模块，用于使用所述待调用服务的服务标识信息与所述所有服务的注册数据进行匹配；

替换模块，用于在所述待调用服务的服务标识信息与所述注册数据匹配成功时，使用所述待调用服务的虚拟服务地址代替所述待调用服务所在容器组的IP地址，作为所述待调用服务的访问地址；

返回模块，用于将所述待调用服务的访问地址返回给所述发起调用的服务；

所述第二容器组包括业务容器和边车容器，所述发起调用的服务部署在所述业务容器中，

在响应于接收到所述第二容器组发出的第一服务调用请求，对所述第一服务调用请求进行解析之前，所述边车容器对所述业务容器发出的第二服务调用请求进行拦截，并使用所述待调用服务的特征信息将所述第二服务调用请求封装为所述第一服务调用请求。

8.一种计算机可读存储介质，其上存储有可执行指令，其特征在于，所述可执行指令在被机器执行时实现如权利要求1-5中任一项所述方法。

9.一种电子设备，其中存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现如权利要求1-5中任一项所述的方法。