CN114615320B - 服务治理方法、装置、电子设备及计算机可读存储介质 - Google Patents

Abstract

本申请实施例提供了一种服务治理方法、装置、电子设备及计算机可读存储介质，涉及云原生技术领域。该方法应用于云化服务框架CSF客户端，包括：通过服务编码发起目标服务的服务调用；接着，通过云原生注册中心获取目标服务当前对应的服务信息，服务信息包括微服务发现服务MDS的服务信息或业务接口发现服务FDS的服务信息中的至少一项；接着，根据服务信息，确定目标服务当前对应的目标服务端；接着，基于服务信息，通过向目标服务端进行目标服务的服务调用，来完成目标服务的服务治理。本申请实施例基于xDS协议不仅扩展实现了可以实现微服务级别的服务治理的MDS，还扩展实现了可以实现方法级别的服务治理的FDS。

Description

服务治理方法、装置、电子设备及计算机可读存储介质

技术领域

本申请涉及云原生技术领域，具体而言，本申请涉及一种服务治理方法、装置、电子设备及计算机可读存储介质。

背景技术

近年来，云原生技术快速发展，在各行各业得到广泛应用。云原生技术的应用设计面向微服务架构，将单个应用拆分为多个微服务，每个微服务以容器的形式部署在容器编排平台中。在这种微服务架构下，业界一般通过Istio平台对微服务之间的流量进行治理，以保证微服务应用的安全，Istio平台是一个适用于云原生场景的服务治理的开放平台。

Istio是目前最广为人知的一款服务网格架构，是服务网格最常见的实现之一，Istio提供了一个完整的解决方案，通过为整个服务网格提供行为洞察和操作控制来满足微服务应用程序的多样化需求。Kubernetes是目前Istio唯一支持的容器组织框架，Istio基于Kubernetes的云原生，管理的服务是所有跑在Kubernetes云原生上面的一个个容器实例。现有的运营商核心***的微服务并没有彻底按照微服务的原则进行拆分，更多的还是中心化的一种思路，一个个容器实例里面运行的是多个服务组成的一个应用***，相对应地，Kubernetes的注册中心托管的微服务具体为应用实例的信息，本质上属于应用级别，无法获取到业务接口级别与微服务级别的服务信息，因此无法实现接口级别的服务治理与微服务级别的服务治理。

发明内容

本申请实施例提供了一种服务治理方法、装置、电子设备及计算机可读存储介质，可以实现接口级别的服务治理与微服务级别的服务治理。技术方案如下：

根据本申请实施例的一个方面，提供了一种服务治理方法，应用于云化服务框架CSF客户端，该方法包括：

通过服务编码发起目标服务的服务调用；

通过云原生注册中心获取目标服务当前对应的服务信息，服务信息包括微服务发现服务MDS的服务信息或业务接口发现服务FDS的服务信息中的至少一项；

根据服务信息，确定目标服务当前对应的目标服务端；

基于服务信息，通过向目标服务端进行目标服务的服务调用，来完成目标服务的服务治理。

在一种可能的实现方式中，通过云原生注册中心获取目标服务当前对应的服务信息，包括：

通过云原生注册中心监听APIServer来获取MDS当前的服务信息和/或FDS当前的服务信息；

其中，MDS当前的服务信息与FDS当前的服务信息，均是通过CSF控制平台推送至APIServer中的。

在一种可能的实现方式中，MDS的服务信息包括路由策略信息、负载策略信息及运行模式切换策略信息中的至少一项；

FDS的服务信息包括服务降级策略信息、服务超时策略信息及服务熔断策略信息中的至少一项。

在一种可能的实现方式中，根据目标服务当前对应的服务信息，确定目标服务当前对应的目标服务端，包括：

基于路由策略信息，通过云原生注册中心获取目标服务对应的路由地址，其中，路由地址对应一组POD IP；

基于负载策略信息，从一组POD IP中选定一个目标POD IP，并将目标POD IP对应的服务端确定为目标服务当前对应的目标服务端。

在一种可能的实现方式中，云原生注册中心是一种无状态的注册中心，其本身不保存任何数据信息、且其所需的所有数据信息均来源于Kubernetes自带的存储设施ETCD；

云原生注册中心通过发现服务xDS协议提供服务，并通过xDS服务器提供服务发现接口xDS API；其中，xDS位于云原生注册中心架构的最上层，其直接将云原生注册中心的服务治理的能力暴露给CSF客户端。

根据本申请实施例的一个方面，提供了一种服务治理方法，应用于云原生注册中心，该方法包括：

CSF客户端通过服务编码发起目标服务的服务调用时，获取目标服务当前对应的服务信息，服务信息包括微服务发现服务MDS的服务信息或业务接口发现服务FDS的服务信息中的至少一项；

向CSF客户端发送所服务信息，以使得CSF客户端根据服务信息确定目标服务当前对应的目标服务端，以及基于服务信息通过向目标服务端进行目标服务的服务调用，来完成目标服务的服务治理。

在一种可能的实现方式中，获取目标服务当前对应的服务信息，包括：

通过监听APIServer来获取MDS当前的服务信息和/或FDS当前的服务信息；

其中，MDS当前的服务信息与FDS当前的服务信息，均是通过CSF控制平台推送至APIServer中的。

在一种可能的实现方式中，MDS的服务信息包括路由策略信息、负载策略信息及运行模式切换策略信息中的至少一项；

FDS的服务信息包括服务降级策略信息、服务超时策略信息及服务熔断策略信息中的至少一项。

在一种可能的实现方式中，云原生注册中心是一种无状态的注册中心，其本身不保存任何数据信息、且其所需的所有数据信息均来源于Kubernetes自带的存储设施ETCD；

云原生注册中心通过发现服务xDS协议提供服务，并通过xDS服务器提供服务发现接口xDS API；其中，xDS位于云原生注册中心架构的最上层，其直接将云原生注册中心的服务治理的能力暴露给CSF客户端。

根据本申请实施例的另一个方面，提供了一种服务治理装置，应用于云化服务框架CSF客户端该装置包括：

第一处理模块，用于通过服务编码发起目标服务的服务调用；

第二处理模块，用于通过云原生注册中心获取目标服务当前对应的服务信息，服务信息包括微服务发现服务MDS的服务信息或业务接口发现服务FDS的服务信息中的至少一项；

第三处理模块，用于根据服务信息，确定目标服务当前对应的目标服务端；

第四处理模块，用于基于服务信息，通过向目标服务端进行目标服务的服务调用，来完成所述目标服务的服务治理。

在一种可能的实现方式中，第二处理模块在通过云原生注册中心获取目标服务当前对应的服务信息时，具体用于：

通过云原生注册中心监听APIServer来获取MDS当前的服务信息和/或FDS当前的服务信息；

其中，MDS当前的服务信息与FDS当前的服务信息，均是通过CSF控制平台推送至APIServer中的。

在一种可能的实现方式中，MDS的服务信息包括路由策略信息、负载策略信息及运行模式切换策略信息中的至少一项；

FDS的服务信息包括服务降级策略信息、服务超时策略信息及服务熔断策略信息中的至少一项。

在一种可能的实现方式中，第三处理模块在根据目标服务当前对应的服务信息，确定目标服务当前对应的目标服务端时，具体用于：

基于路由策略信息，通过云原生注册中心获取目标服务对应的路由地址，其中，路由地址对应一组POD IP；

基于负载策略信息，从一组POD IP中选定一个目标POD IP，并将目标POD IP对应的服务端确定为目标服务当前对应的目标服务端。

在一种可能的实现方式中，云原生注册中心是一种无状态的注册中心，其本身不保存任何数据信息、且其所需的所有数据信息均来源于Kubernetes自带的存储设施ETCD；

云原生注册中心通过发现服务xDS协议提供服务，并通过xDS服务器提供服务发现接口xDS API；其中，xDS位于云原生注册中心架构的最上层，其直接将云原生注册中心的服务治理的能力暴露给CSF客户端。

根据本申请实施例的另一个方面，提供了一种服务治理装置，应用于云原生注册中心，该装置包括：

获取模块，用于CSF客户端通过服务编码发起目标服务的服务调用时，获取目标服务当前对应的服务信息，服务信息包括微服务发现服务MDS的服务信息或业务接口发现服务FDS的服务信息中的至少一项；

发送模块，用于向CSF客户端发送所服务信息，以使得CSF客户端根据服务信息确定目标服务当前对应的目标服务端，以及基于服务信息通过向目标服务端进行目标服务的服务调用，以完成目标服务的服务治理。

在一种可能的实现方式中，获取模块在获取目标服务当前对应的服务信息时，具体用于：

通过监听APIServer来获取MDS当前的服务信息和/或FDS当前的服务信息；

其中，MDS当前的服务信息与FDS当前的服务信息，均是通过CSF控制平台推送至APIServer中的。

在一种可能的实现方式中，MDS的服务信息包括路由策略信息、负载策略信息及运行模式切换策略信息中的至少一项；

FDS的服务信息包括服务降级策略信息、服务超时策略信息及服务熔断策略信息中的至少一项。

在一种可能的实现方式中，云原生注册中心是一种无状态的注册中心，其本身不保存任何数据信息、且其所需的所有数据信息均来源于Kubernetes自带的存储设施ETCD；

云原生注册中心通过发现服务xDS协议提供服务，并通过xDS服务器提供服务发现接口xDS API；其中，xDS位于云原生注册中心架构的最上层，其直接将云原生注册中心的服务治理的能力暴露给CSF客户端。

根据本申请实施例的另一个方面，提供了一种电子设备，该电子设备包括：存储器、处理器及存储在存储器上的计算机程序，处理器执行计算机程序以实现上述的服务治理方法的步骤。

根据本申请实施例的再一个方面，提供了一种计算机可读存储介质，计算机程序被处理器执行时实现上述的服务治理方法的步骤。

根据本申请实施例的一个方面，提供了一种计算机程序产品，计算机程序被处理器执行时实现上述的服务治理方法的步骤。

本申请实施例提供的技术方案带来的有益效果是：基于Pilot xDS协议扩展实现了MDS，使得可以实现微服务级别的服务治理，还基于Pilot xDS协议扩展实现了FDS，使得可以实现方法级别的服务治理，从而解决了当前云原生注册中心只支持EDS、CDS和LDS的监听，而不能与微服务和接口层面的策略信息相结合的问题；此外，服务端无须保持与云原生注册中心的长链接，在kubernetes体系内，所有实例信息均存储在k8s体系原生的存储设施ETCD内，避免了网络不佳或复杂网络情况下容易出现服务端掉线的情况的发生。

附图说明

为了更清楚地说明本申请实施例中的技术方案，下面将对本申请实施例描述中所需要使用的附图作简单地介绍。

图1为本申请一个实施例提供的服务治理方法的流程示意图；

图2为本申请一个实施例提供的服务治理的整体处理过程示意图；

图3为本申请一个实施例提供的对原有云原生注册中心所做改进的示意图；

图4为本申请又一实施例提供的服务治理方法的流程示意图；

图5为本申请又一实施例提供的服务治理装置的结构示意图；

图6为本申请另一实施例提供的服务治理装置的流程示意图；

图7为本申请实施例提供的一种电子设备的结构示意。

具体实施方式

下面结合本申请中的附图描述本申请的实施例。应理解，下面结合附图所阐述的实施方式，是用于解释本申请实施例的技术方案的示例性描述，对本申请实施例的技术方案不构成限制。

本技术领域技术人员可以理解，除非特意声明，这里使用的单数形式“一”、“一个”、“所述”和“该”也可包括复数形式。应该进一步理解的是，本申请实施例所使用的术语“包括”以及“包含”是指相应特征可以实现为所呈现的特征、信息、数据、步骤、操作、元件和/或组件，但不排除实现为本技术领域所支持其他特征、信息、数据、步骤、操作、元件、组件和/或它们的组合等。应该理解，当我们称一个元件被“连接”或“耦接”到另一元件时，该一个元件可以直接连接或耦接到另一元件，也可以指该一个元件和另一元件通过中间元件建立连接关系。此外，这里使用的“连接”或“耦接”可以包括无线连接或无线耦接。这里使用的术语“和/或”指示该术语所限定的项目中的至少一个，例如“A和/或B”指示实现为“A”，或者实现为“A”，或者实现为“A和B”。

为使本申请的目的、技术方案和优点更加清楚，下面将结合附图对本申请实施方式作进一步地详细描述。

先对本申请可能涉及到的几个名词进行介绍和解释：

Kubernetes：简称K8s，是用8代替名字中间的8个字符“ubernete”而成的缩写。是一个开源的，用于管理云平台中多个主机上的容器化的应用，Kubernetes的目标是让部署容器化的应用简单并且高效(powerful)，Kubernetes提供了应用部署，规划，更新，维护的一种机制，它支持自动化部署、大规模可伸缩、应用容器化管理。在生产环境中部署一个应用程序时，通常要部署该应用的多个实例以便对应用请求进行负载均衡。在Kubernetes中，可以创建多个容器，每个容器里面运行一个应用实例，然后通过内置的负载均衡策略，实现对这一组应用实例的管理、发现、访问，而这些细节都不需要运维人员去进行复杂的手工配置和处理。

微服务：是指***的不同单元或功能运行不同的容器，每一个服务的容器数量可以根据自己的负载进行调整。比如，一个大***包含用户登录、货品展示、货品交互等功能，但这个***的各个部分并不是同时线性增加的，有些部分可能忙一些，有些部分的容量可能还有富余。

Pod：一种增强型容器。Pod是Kubernetes集群最基本的部署调度单元，也就是，微服务应用运行的最小单元，每个Pod包括多个容器，可以把它看作是一种容器的扩展或者增强型的容器。Pod里面包括一个主容器和数个辅助容器，它们共同完成一个特定的功能。把多个进程(容器也是一种隔离的进程)打包在一个Name Space里的时候，就构成了一个Pod。Pod里面不同进程的应用包装仍然是独立的(每个容器都会有自己的镜像)。

Pod的意义在于，它可以既保持主容器和辅助容器的密切关系，又保持主容器的独立性。由于主容器和辅助容器的生命周期相同，可以同时被创建和销毁，因此把它们放在一个Pod中，可以使他们的交互更加高效。而另一方面，主容器需要完成一些主要的工作，而另一些工作可能是有共性的，就可以单独打包由辅助容器来运行。

服务网格：是服务(包括微服务)之间通信的控制器。

随着越来越多的容器应用的开发和部署，一个企业可能会有成百上千或数万计的容器在运行，怎样管理这些容器或服务之间的通信，包括服务间的负载均衡、流量管理、路由、运行状况监视、安全策略及服务间身份验证，成为云原生技术的巨大挑战。以Istio为代表的服务网格应运而生。在架构上，Istio属于云原生技术的基础设施层，通过在容器旁提供一系列网络代理，来实现服务间的通信控制。其中的每个网络代理就是一个网关，管理容器或容器集群中每个服务间的请求或交互。每个网络代理还拦截服务请求，并将服务请求分发到服务网格上，因此，众多服务构成的无数连接“编织”成网，也就有了“网格”这个概念。服务网格的中央控制器，在Kubernetes容器平台的帮助下，通过服务策略来控制和调整网络代理的功能，包括收集服务的性能指标。

在经典的服务网络的示意图中，边车(Sidecar)中有各种配置规则和流量治理策略，这部分叫做数据面，而配置规则的发现及下发是通过控制面进行的，控制面主要包括Pilot、Mixer、Citadel等服务组件。如果把数据面的Envoy也看作一种Agent，则Pilot类似传统C/S架构中的服务端Master，下发指令控制客户端完成业务功能。和传统的微服务架构对比，Pilot至少涵盖服务注册中心和Config Server等管理组件的功能。

其中，Pilot直接从运行平台提取数据并将其构造和转换成Istio的服务发现模型，因此Pilot只有服务发现功能，无须进行服务注册。这种抽象模型解耦了Pilot和底层平台的不同实现，可支持Kubernetes、Consul等平台。

除了服务发现外，Pilot更重要的一个功能是向数据面下发规则，包括VirtualService(虚拟服务)、DestinationRule(目标规则)、Gateway(网关)、ServiceEntry(服务入口)等流量治理规则，也包括认证授权等安全规则。Pilot负责将各种规则转换成Envoy可识别的格式，通过标准的xDS协议发送给Envoy，指导Envoy完成动作。在通信上，Envoy通过gRPC流式订阅Pilot的配置资源。

可见，Pilot是Istio控制面流量管理的核心组件，管理和配置部署在Istio服务网格中的所有Envoy代理实例，允许用户创建Envoy代理之间的流量转发路由规则，并配置故障恢复功能，例如超时、重试及熔断。另外，Pilot支持设置安全(认证、鉴权、策略控制)、遥测上报等规则，维护着网格中所有的服务实例信息，并基于xDS服务发现让每个Envoy都能了解上游服务的实例信息。

除此之外，Pilot还提供了一个用于Debug的REST接口，可供管理员获取进程缓存状态、配置下发状态及针对某个代理进行完整配置。目前，命令行工具istioctl获取配置及代理状态的很多子命令都直接访问此接口。另外，Pilot支持基于多个不同的底层平台进行服务发现和流量规则发现，抽象聚合层通过聚合不同平台的服务、配置规则对外提供统一的接口，进而使得Pilot发现服务(xDS)无须关心底层平台的差异，达到解耦xDS与底层平台的目的。

虽然当前的服务网格云原生注册中心Pilot具有上述一系列功能与优点，然而，在具体实现中，本申请发明人发现现有服务网格云原生注册中心Pilot，只支持EDS(EndpointDiscovery Service，集群成员发现服务)，CDS(Cluster Discovery Service，集群发现服务)，LDS(Listener Discovery Service，监听发现服务)的监听，不能与微服务以及接口层面的路由、负载、降级、熔断、超时等策略信息相结合，而且，当前微服务注册中心，如zookeeper，nacos等大多为有状态注册中心，在使用的时候，服务端启动均需要向注册中心注册，需要维持与注册中心长链接以及健康检查机制。在网络不佳，或者复杂网络情况下，容易出现服务端掉线的情况。

针对上述情况，本申请提出一种服务治理的方案，下面通过对几个示例性实施方式的描述，对本申请实施例的技术方案以及本申请的技术方案产生的技术效果进行说明。需要指出的是，下述实施方式之间可以相互参考、借鉴或结合，对于不同实施方式中相同的术语、相似的特征以及相似的实施步骤等，不再重复描述。

图1为本申请实施例提供的服务治理方法的流程示意图，如图1所示，该方法应用于CSF客户端，包括：步骤S110，通过服务编码发起目标服务的服务调用；步骤S120，通过云原生注册中心获取目标服务当前对应的服务信息，服务信息包括微服务发现服务MDS的服务信息或业务接口发现服务FDS的服务信息中的至少一项；步骤S130，根据服务信息，确定目标服务当前对应的目标服务端；步骤S140，基于服务信息，通过向目标服务端进行目标服务的服务调用，来完成目标服务的服务治理。

CSF客户端具有自己的调用方式，即通过服务编码发起服务调用，在一个示例中，CSF客户端可以通过服务编码向服务接口发起目标服务的服务调用，比如，若要发起针对FDS(Function Discovery Sevice，业务接口发现服务)的服务调用，可以向FDS业务接口发起FDS的服务调用，又比如，若要发起针MDS(MicroService Discovery Sevice，微服务发现服务)的服务调用，可以向MDS业务接口发起FDS的服务调用。上述的目标服务可以是与FDS和/或MDS具有一定关联的任一服务。需要注意的是，上述示例只是为了便于理解服务调用而引入的，本申请实施例中的服务调用方法不局限于上述示例中的情况，不能将上述示例作为对本申请实施的限定。

CSF客户端发起服务调用后，可以通过服务编码从CSF-xDS(即云原生注册中心)获取目标服务当前对应的服务信息，该服务信息是云原生注册中心中最新更新后的服务信息。该服务信息可以是MDS的服务信息，也可以是FDS的服务信息，还可以MDS的服务信息和FDS的服务信息，当然也可以是除了MDS的服务信息和/或FDS的服务信息之外，完成该服务调用所需要的其他服务信息，比如EDS的服务信息、CDS的服务信息及LDS的服务信息等等，本申请实施例不对其做限定。

CSF客户端获取到所需的服务信息后，可以根据该服务信息确定，确定目标服务当前对应的目标服务端，接着基于该服务信息，通过向目标服务端进行目标服务的服务调用，来完成目标服务的服务治理。

本申请提供的方法，基于Pilot xDS协议扩展实现了MDS，使得可以实现微服务级别的服务治理，还基于Pilot xDS协议扩展实现了FDS，使得可以实现方法级别的服务治理，从而解决了当前云原生注册中心只支持EDS、CDS和LDS的监听，而不能与微服务和接口层面的策略信息相结合的问题；此外，服务端无须保持与云原生注册中心的长链接，在kubernetes体系内，所有实例信息均存储在k8s体系原生的存储设施ETCD内，避免了网络不佳或复杂网络情况下容易出现服务端掉线的情况的发生。

在本申请实施例的一种可能的实现方式中，通过云原生注册中心获取目标服务当前对应的服务信息，可以为：通过云原生注册中心监听APIServer来获取MDS当前的服务信息和/或FDS当前的服务信息；其中，MDS当前的服务信息与FDS当前的服务信息，均是通过CSF控制平台推送至APIServer中的。

CSF控制平台通过fabric8 java客户端，将MDS当前的服务信息和/或FDS当前的服务信息，推送至APIServer，相当于向APIServer进行配置规则的下发，此处的服务信息就相当于配置规则。APIServer接收到CSF控制平台推送的MDS当前的服务信息，就利MDS当前的服务信息替代APIServer中原有的MDS的服务信息，同样地，APIServer接收到CSF控制平台推送的FDS当前的服务信息，就利FDS当前的服务信息替代APIServer中原有的FDS的服务信息，即MDS当前的服务信息为APIServer中的MDS的最新的服务信息，FDS当前的服务信息为APIServer中的FDS的最新的服务信息。

其中，MDS的服务信息可以包括路由策略信息、负载策略信息及运行模式切换策略信息中的至少一项；FDS的服务信息可以包括服务降级策略信息、服务超时策略信息及服务熔断策略信息中的至少一项。相当于，CSF控制平台通过fabric8 java客户端，将路由策略信息、负载策略信息及运行模式切换策略信息中的至少一项，推送至APIServer；或者，CSF控制平台通过fabric8 java客户端，将服务降级策略信息、服务超时策略信息及服务熔断策略信息中的至少一项，推送至APIServer；又或者，CSF控制平台通过fabric8 java客户端，将路由策略信息、负载策略信息及运行模式切换策略信息中的至少一项，以及将服务降级策略信息、服务超时策略信息及服务熔断策略信息中的至少一项，推送至APIServer。

同样地，APIServer接收到CSF控制平台推送的路由策略信息、负载策略信息以及运行模式切换策略信息中的至少一项；或者，APIServer接收到CSF控制平台推送的服务降级策略信息、服务超时策略信息及服务熔断策略信息中的至少一项；又或者，APIServer接收到CSF控制平台推送的路由策略信息、负载策略信息及运行模式切换策略信息中的至少一项，以及服务降级策略信息、服务超时策略信息及服务熔断策略信息中的至少一项。

其中，APIServer(本身是无状态服务)用于把资源数据存储到ETCD，后续的业务逻辑由副本控制器和调度器执行；Kubernetes容器管理组件同时运行多个APIServer服务，通过代理把流量转发到不同的APIServer上实现接入层的高可用。Master节点服务扮演着总控中心的角色。Master节点包括APIServer、副本控制器和调度器。APIServer检测到资源产生变更时，会主动通知到Controller manager(利用分块传输编码)。

CSF控制平台通过fabric8 java客户端，将MDS当前的服务信息和/或FDS当前的服务信息，推送至APIServer之后，云原生注册中心通过对APIServer进行监听，可以获取到MDS当前的服务信息和/或FDS当前的服务信息，即CSF客户端通过云原生注册中心对APIServer进行监听，来获取MDS当前的服务信息和/或FDS当前的服务信息，换言之，CSF客户端通过云原生注册中心对APIServer进行监听，来实时动态获取改变后的MDS的服务信息和改变后的FDS的服务信息，以获取最新的服务信息。在一个示例中，由于云原生注册中心本身不保存任何数据，其所有数据均来源于K8s自带存储设施ETCD，且ETCD是一个高可用、强一致性的键值存储***，所以云原生注册中心可以将监听到的MDS当前的服务信息和/或FDS当前的服务信息，按照key-value的方式进行组装，并存储至存储设施ETCD中。

上述的ETCD是一个高可用强一致性的键值存储***，主要用于共享配置和服务发现。ETCD专门为管理分布式***中节点状态、集群环境的服务发现和注册而设计，它提供数据TTL失效、数据改变监视、多值、目录监听、分布式锁原子操作等功能，可以方便的跟踪并管理集群节点的状态。ETCD让服务快速透明地接入到计算集群中，让共享配置信息快速被集群中的所有机器发现，通过ETCD可以构建一套高可用、安全、易于部署以及响应快速的服务集群。ETCD通过Raft一致性算法以保证强一致性，解决了分布式场景中最为常见的一致性问题，为服务发现提供了一个稳定高可用的消息注册仓库，为以微服务协同工作的架构提供了无限可能。

本申请实施例的实现方式，基于xDS协议扩展实现了MDS基于微服务的路由策略、负载策略以及运行模式切换的服务治理方式；基于xDS协议扩展实现了FDS基于方法级别的服务治理。

在本申请实施例的一种可能的实现方式中，根据目标服务当前对应的服务信息，确定目标服务当前对应的目标服务端的过程，可以为：基于路由策略信息，通过云原生注册中心获取目标服务对应的路由地址，其中，路由地址对应一组POD IP；接着，基于负载策略信息，从该一组POD IP中选定一个目标POD IP，并将目标POD IP对应的服务端确定为目标服务当前对应的目标服务端。

其中，POD IP是指POD的IP(Internet Protocol，互联网协议)地址，即Docker容器的IP地址，其为虚拟IP地址。POD IP是每个POD的IP地址，其是Docker Engine根据Docker网桥的IP地址段进行分配的，通常是一个虚拟的二层网络；通常，同Service下的POD可以直接根据POD IP相互通信；不同Service下的POD在集群间POD通信要借助于Cluster IP(即Service的IP地址，其为虚拟IP地址)；POD和集群外通信，要借助于Node IP(即Node节点的IP地址，为物理网卡的IP地址)。

CSF客户端基于获取到的路由策略信息，可以通过云原生注册中心获取目标服务对应的路由地址，其中，一个路由地址对应的是一个集群，可以认为该集群是一组POD IP的集合(即一个POD IP地址列表)，相当于一个路由地址对应的是一组POD IP(即一个POD IP地址列表)。相当于，CSF客户端基于获取到的路由策略信息，通过云原生注册中心获取可访问的POD IP地址列表，该POD IP地址列表包括至少一个POD IP地址(比如1个、2个、3个或更多个)。通常一个POD IP对应一个服务端，故上述过程相当于通过云原生注册中心获取可访问的一个或多个服务端。在实际应用中，可以将获取到的一组POD IP中的每个POD IP对应的服务端，看作是目标服务对应的候选服务端。

CSF客户端获取到一组POD IP后，可以基于通过云原生注册中心获取到的负载策略信息，从该一组POD IP中选定一个指定的POD IP，该指定的POD IP即为目标POD IP，该指定的POD IP对应的服务端即为目标服务端。上述过程，相当于基于通过云原生注册中心获取到的负载策略信息，从一个或多个候选服务端中选择出目标服务端。接着，CSF客户端基于获取到的服务信息，通过向目标服务端进行目标服务的服务调用，来完成目标服务的服务治理。

在本申请实施例的一种可能的实现方式中，云原生注册中心是一种无状态的注册中心，其本身不保存任何数据信息、且其所需的所有数据信息均来源于Kubernetes自带的存储设施ETCD；云原生注册中心通过发现服务xDS协议提供服务，并通过xDS服务器提供服务发现接口xDS API；其中，xDS位于云原生注册中心架构的最上层，其直接将云原生注册中心的服务治理的能力暴露给CSF客户端。

为了便于描述，可以将本申请实施例中的云原生注册中心记作CSF-Xds，该CSF-Xds是CSF基于kubernetes的云原生注册中心，它管理和配置部署在k8s容器中CSF服务的所有路由、负载、超时、熔断、降级、模式切换等策略的配置信息，以及Service、POD信息等。

本申请实施例中的CSF-Xds是一种无状态的注册中心，它本身不保存任何数据，其所有数据均来源于K8s自带存储设施ETCD，并且，CSF-Xds的POD IP数据是基于APIServer监听获取到的POD信息，CSF-Xds的服务数据、负载策略、降级策略、超时策略、熔断策略等是基于APIServer监听的自定义CSF服务资源获取的，CSF-Xds的路由策略信息是基于APIServer监听获取的CSF路由资源获取的，CSF-Xds的负载策略是基于APIServer监听获取的CSF负载资源获取的。

CSF-Xds通过xDS提供服务，xDS发现服务位于CSF-Xds架构的最上层，直接将CSF-Xds服务治理的能力暴露给客户端。CSF-Xds通过xDS服务器提供服务发现接口xDS API，xDS服务器接收并维护CSF应用的连接，并基于客户端订阅的资源名称进行相应xDS配置的分发。

在CSF-Xds与CSF应用之间维护着一条gRPC长连接，所有配置的分发都基于此连接的一个Stream(流)。配置的下发采用异步方式，主要基于底层注册中心服务的变化或者配置规则的更新事件进行。

下面通过图2所示的本申请实施例的服务治理的整体处理过程，对本申请实施例的方法进行具体介绍：

(1)CSF控制平台向APIServer进行策略推送，即CSF控制平台通过fabric8 java客户端，将自定义资源服务信息、服务路由信息、服务负载信息、服务熔断信息、服务降级信息、服务超时信息等策略信息，推送到APIServer。

(2)CSF-Xds通过对APIServer监听来监听MDS和/或FDS，即CSF-Xds通过对K8S自定义资源信息FDS和/或MDS进行监听，来获取MDS当前的服务信息和/或所述FDS当前的服务信息，FDS和/或MDS位于APIServer中。

(3)CSF-Xds将监听的自定义资源信息、Service资源信息、Pod资源信息等，按照key-value的方式进行组装。

(4)CSF客户端通过GRPC协议对CSF-Xds进行监听。

(5)CSF客户端通过服务编码发起CSF服务调用，即CSF客户端通过服务编码发起目标服务的服务调用。

(6)CSF客户端通过服务编码从云原生注册中心CSF-Xds获取相应的服务信息、路由策略信息等，即CSF客户端基于服务编码，通过云原生注册中心CSF-xDS获取目标服务当前对应的服务信息，该服务信息包括微服务发现服务MDS的服务信息或业务接口发现服务FDS的服务信息中的至少一项；其中，MDS的服务信息包括路由策略信息、负载策略信息及运行模式切换策略信息中的至少一项；FDS的服务信息包括服务降级策略信息、服务超时策略信息及服务熔断策略信息中的至少一项。

(7)CSF客户端通过路由信息获取可访问的POD IP地址列表(即一组POD IP)，该POD IP地址列表包括一个或多个POD IP，相当于，CSF客户端基于路由策略信息，通过云原生注册中心CSF-xDS获取目标服务对应的路由地址，其中，路由地址对应一组POD IP。

(8)CSF客户端通过CSF-Xds获取负载策略配置信息，即CSF客户端通过云原生注册中心CSF-xDS获取负载策略信息。

(9)CSF客户端通过负载策略信息，从上述的一组POD IP中选定指定的POD IP进行服务调用，该指定的POD IP对应的服务端即为目标服务端，相当于，CSF客户端通过向目标服务端进行服务调用，来完成服务治理。

图3示出了本申请实施例对原有云原生注册中心所做的改进，原有云原生注册中心xDS API只包括LDA、CDS、EDS等，而不包括FDS、MDS(即图中带点填充部分)，本申请实施例通过基于xDS协议进行扩展，实现了FDS与MDS，使得现有云原生注册中心xDS API不仅支持LDA、CDS、EDS等，还支持FDS、MDS(即图中带点填充部分)。

本申请实施例基于云原生架构，实现了无状态可伸缩的微服务架构注册中心，并基于xDS实现了FDS和MDS，其中，FDS可以实现云原生模式下方法级别的服务治理，MDS上记录有微服务路由信息、服务负载策略以及运行模式切换信息等，此外，基于xDS注册中心可以实现CSF自有运行模式和网格模式双栈切换功能。

图4为本申请实施例提供的服务治理方法的流程示意图，如图4所示，该方法应用于云原生注册中心，包括：步骤S410，CSF客户端通过服务编码发起目标服务的服务调用时，获取目标服务当前对应的服务信息，服务信息包括微服务发现服务MDS的服务信息或业务接口发现服务FDS的服务信息中的至少一项；步骤S420，向CSF客户端发送所服务信息，以使得CSF客户端根据服务信息确定目标服务当前对应的目标服务端，以及基于服务信息通过向目标服务端进行目标服务的服务调用，以完成目标服务的服务治理。

本申请实施例所提供的云原生注册中心侧的服务治理方法，是与本申请实施例提供的CSF客户端侧的服务治理方法相对应地，因此，可以理解的是，云原生注册中心侧的服务治理的处理步骤是与CSF客户端侧的服务治理的步骤相对应的，即CSF客户端侧的服务治理的步骤的相关内容同样适应于云原生注册中心侧的服务治理的处理步骤，在此不再对云原生注册中心侧的服务治理的步骤进行赘述，其中，CSF客户端侧的服务治理的相应步骤的具体描述可以参见前文中的相应描述。

在本申请实施例的一种可能的实现方式中，获取目标服务当前对应的服务信息，包括：

通过监听APIServer来获取MDS当前的服务信息和/或FDS当前的服务信息；

其中，MDS当前的服务信息与FDS当前的服务信息，均是通过CSF控制平台推送至APIServer中的。

在本申请实施例的一种可能的实现方式中，MDS的服务信息包括路由策略信息、负载策略信息及运行模式切换策略信息中的至少一项；

FDS的服务信息包括服务降级策略信息、服务超时策略信息及服务熔断策略信息中的至少一项。

在本申请实施例的一种可能的实现方式中，云原生注册中心是一种无状态的注册中心，其本身不保存任何数据信息、且其所需的所有数据信息均来源于Kubernetes自带的存储设施ETCD；

云原生注册中心通过发现服务xDS协议提供服务，并通过xDS服务器提供服务发现接口xDS API；其中，xDS位于云原生注册中心架构的最上层，其直接将云原生注册中心的服务治理的能力暴露给CSF客户端。

本申请实施例的方法，基于Pilot xDS协议扩展实现了MDS，使得可以实现微服务级别的服务治理，还基于Pilot xDS协议扩展实现了FDS，使得可以实现方法级别的服务治理，从而解决了当前云原生注册中心只支持EDS、CDS和LDS的监听，而不能与微服务和接口层面的策略信息相结合的问题；此外，服务端无须保持与云原生注册中心的长链接，在kubernetes体系内，所有实例信息均存储在k8s体系原生的存储设施ETCD内，避免了网络不佳或复杂网络情况下容易出现服务端掉线的情况的发生。

本申请实施例提供了一种服务治理装置，该装置应用于云化服务框架CSF客户端，如图5所示，可以包括：第一处理模块501、第二处理模块502、第三处理模块503以及第四处理模块504，其中，

第一处理模块501，用于通过服务编码发起目标服务的服务调用；

第二处理模块502，用于通过云原生注册中心获取目标服务当前对应的服务信息，服务信息包括微服务发现服务MDS的服务信息或业务接口发现服务FDS的服务信息中的至少一项；

第三处理模块503，用于根据服务信息，确定目标服务当前对应的目标服务端；

第四处理模块504，用于基于服务信息，通过向目标服务端进行目标服务的服务调用，来完成目标服务的服务治理。

在一种可能的实现方式中，第二处理模块在通过云原生注册中心获取目标服务当前对应的服务信息时，具体用于：

通过云原生注册中心监听APIServer来获取MDS当前的服务信息和/或FDS当前的服务信息；

其中，MDS当前的服务信息与FDS当前的服务信息，均是通过CSF控制平台推送至APIServer中的。

在一种可能的实现方式中，MDS的服务信息包括路由策略信息、负载策略信息及运行模式切换策略信息中的至少一项；

FDS的服务信息包括服务降级策略信息、服务超时策略信息及服务熔断策略信息中的至少一项。

在一种可能的实现方式中，第三处理模块在根据目标服务当前对应的服务信息，确定目标服务当前对应的目标服务端时，具体用于：

基于路由策略信息，通过云原生注册中心获取目标服务对应的路由地址，其中，路由地址对应一组POD IP；

基于负载策略信息，从一组POD IP中选定一个目标POD IP，并将目标POD IP对应的服务端确定为目标服务当前对应的目标服务端。

在一种可能的实现方式中，云原生注册中心是一种无状态的注册中心，其本身不保存任何数据信息、且其所需的所有数据信息均来源于Kubernetes自带的存储设施ETCD；

云原生注册中心通过发现服务xDS协议提供服务，并通过xDS服务器提供服务发现接口xDS API；其中，xDS位于云原生注册中心架构的最上层，其直接将云原生注册中心的服务治理的能力暴露给CSF客户端。

本申请实施例的装置，基于Pilot xDS协议扩展实现了MDS，使得可以实现微服务级别的服务治理，还基于Pilot xDS协议扩展实现了FDS，使得可以实现方法级别的服务治理，从而解决了当前云原生注册中心只支持EDS、CDS和LDS的监听，而不能与微服务和接口层面的策略信息相结合的问题；此外，服务端无须保持与云原生注册中心的长链接，在kubernetes体系内，所有实例信息均存储在k8s体系原生的存储设施ETCD内，避免了网络不佳或复杂网络情况下容易出现服务端掉线的情况的发生。

本申请实施例的服务治理装置可执行本申请上述CSF客户端侧实施例所示的的服务治理方法，其实现原理相类似，本申请各实施例的装置中的各模块所执行的动作是与本申请CSF客户端侧的各实施例的服务治理方法中的步骤相对应的，对于装置的各模块的详细功能描述具体可以参见前文中所示的对应方法中的描述，此处不再赘述。

本申请实施例提供了一种服务治理装置，应用于云原生注册中心，如图6所示，该装置600以包括：获取模块601以及发送模块602，其中，

获取模块601，用于CSF客户端通过服务编码发起目标服务的服务调用时，获取目标服务当前对应的服务信息，服务信息包括微服务发现服务MDS的服务信息或业务接口发现服务FDS的服务信息中的至少一项；

发送模块602，用于向CSF客户端发送所服务信息，以使得CSF客户端根据服务信息确定目标服务当前对应的目标服务端，以及基于服务信息通过向目标服务端进行目标服务的服务调用，来完成目标服务的服务治理。

在一种可能的实现方式中，获取模块在获取目标服务当前对应的服务信息时，具体用于：

通过监听APIServer来获取MDS当前的服务信息和/或FDS当前的服务信息；

其中，MDS当前的服务信息与FDS当前的服务信息，均是通过CSF控制平台推送至APIServer中的。

在一种可能的实现方式中，MDS的服务信息包括路由策略信息、负载策略信息及运行模式切换策略信息中的至少一项；

FDS的服务信息包括服务降级策略信息、服务超时策略信息及服务熔断策略信息中的至少一项。

在一种可能的实现方式中，云原生注册中心是一种无状态的注册中心，其本身不保存任何数据信息、且其所需的所有数据信息均来源于Kubernetes自带的存储设施ETCD；

云原生注册中心通过发现服务xDS协议提供服务，并通过xDS服务器提供服务发现接口xDS API；其中，xDS位于云原生注册中心架构的最上层，其直接将云原生注册中心的服务治理的能力暴露给CSF客户端。

本申请实施例的装置，基于Pilot xDS协议扩展实现了MDS，使得可以实现微服务级别的服务治理，还基于Pilot xDS协议扩展实现了FDS，使得可以实现方法级别的服务治理，从而解决了当前云原生注册中心只支持EDS、CDS和LDS的监听，而不能与微服务和接口层面的策略信息相结合的问题；此外，服务端无须保持与云原生注册中心的长链接，在kubernetes体系内，所有实例信息均存储在k8s体系原生的存储设施ETCD内，避免了网络不佳或复杂网络情况下容易出现服务端掉线的情况的发生。

本申请实施例的服务治理装置可执行本申请上述云原生注册中心侧实施例所示的的服务治理方法，其实现原理相类似，本申请各实施例的装置中的各模块所执行的动作是与本申请云原生注册中心侧的各实施例的方法中的步骤相对应的，对于装置的各模块的详细功能描述具体可以参见前文中所示的对应方法中的描述，此处不再赘述。

本申请实施例中提供了一种电子设备，包括存储器、处理器及存储在存储器上的计算机程序，该处理器执行上述计算机程序以实现服务治理的方法的步骤，与现有技术相比可实现：基于Pilot xDS协议扩展实现了MDS，使得可以实现微服务级别的服务治理，还基于Pilot xDS协议扩展实现了FDS，使得可以实现方法级别的服务治理，从而解决了当前云原生注册中心只支持EDS、CDS和LDS的监听，而不能与微服务和接口层面的策略信息相结合的问题；此外，服务端无须保持与云原生注册中心的长链接，在kubernetes体系内，所有实例信息均存储在k8s体系原生的存储设施ETCD内，避免了网络不佳或复杂网络情况下容易出现服务端掉线的情况的发生。

在一个可选实施例中提供了一种电子设备，如图7所示，图7所示的电子设备4000包括：处理器4001和存储器4003。其中，处理器4001和存储器4003相连，如通过总线4002相连。可选地，电子设备4000还可以包括收发器4004，收发器4004可以用于该电子设备与其他电子设备之间的数据交互，如数据的发送和/或数据的接收等。需要说明的是，实际应用中收发器4004不限于一个，该电子设备4000的结构并不构成对本申请实施例的限定。

处理器4001可以是CPU(Central Processing Unit，中央处理器)，通用处理器，DSP(Digital Signal Processor，数据信号处理器)，ASIC(Application SpecificIntegrated Circuit，专用集成电路)，FPGA(Field Programmable Gate Array，现场可编程门阵列)或者其他可编程逻辑器件、晶体管逻辑器件、硬件部件或者其任意组合。其可以实现或执行结合本申请公开内容所描述的各种示例性的逻辑方框，模块和电路。处理器4001也可以是实现计算功能的组合，例如包含一个或多个微处理器组合，DSP和微处理器的组合等。

总线4002可包括一通路，在上述组件之间传送信息。总线4002可以是PCI(Peripheral Component Interconnect，外设部件互连标准)总线或EISA(ExtendedIndustry Standard Architecture，扩展工业标准结构)总线等。总线4002可以分为地址总线、数据总线、控制总线等。为便于表示，图7中仅用一条粗线表示，但并不表示仅有一根总线或一种类型的总线。

存储器4003可以是ROM(Read Only Memory，只读存储器)或可存储静态信息和指令的其他类型的静态存储设备，RAM(Random Access Memory，随机存取存储器)或者可存储信息和指令的其他类型的动态存储设备，也可以是EEPROM(Electrically ErasableProgrammable Read Only Memory，电可擦可编程只读存储器)、CD-ROM(Compact DiscRead Only Memory，只读光盘)或其他光盘存储、光碟存储(包括压缩光碟、激光碟、光碟、数字通用光碟、蓝光光碟等)、磁盘存储介质、其他磁存储设备、或者能够用于携带或存储计算机程序并能够由计算机读取的任何其他介质，在此不做限定。

存储器4003用于存储执行本申请实施例的计算机程序，并由处理器4001来控制执行。处理器4001用于执行存储器4003中存储的计算机程序，以实现前述方法实施例所示的步骤。

本申请实施例提供了一种计算机可读存储介质，该计算机可读存储介质上存储有计算机程序，计算机程序被处理器执行时可实现前述方法实施例的步骤及相应内容。

本申请实施例还提供了一种计算机程序产品，包括计算机程序，计算机程序被处理器执行时可实现前述方法实施例的步骤及相应内容。

应该理解的是，虽然本申请实施例的流程图中通过箭头指示各个操作步骤，但是这些步骤的实施顺序并不受限于箭头所指示的顺序。除非本文中有明确的说明，否则在本申请实施例的一些实施场景中，各流程图中的实施步骤可以按照需求以其他的顺序执行。此外，各流程图中的部分或全部步骤基于实际的实施场景，可以包括多个子步骤或者多个阶段。这些子步骤或者阶段中的部分或全部可以在同一时刻被执行，这些子步骤或者阶段中的每个子步骤或者阶段也可以分别在不同的时刻被执行。在执行时刻不同的场景下，这些子步骤或者阶段的执行顺序可以根据需求灵活配置，本申请实施例对此不限制。

以上所述仅是本申请部分实施场景的可选实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本申请的方案技术构思的前提下，采用基于本申请技术思想的其他类似实施手段，同样属于本申请实施例的保护范畴。

Claims (13)

1.一种服务治理方法，其特征在于，应用于云化服务框架CSF客户端，包括：

通过服务编码发起目标服务的服务调用；

通过所述云原生注册中心获取所述目标服务当前对应的服务信息，所述服务信息包括微服务发现服务MDS的服务信息或业务接口发现服务FDS的服务信息中的至少一项；

根据所述服务信息，确定所述目标服务当前对应的目标服务端；

基于所述服务信息，通过向所述目标服务端进行所述目标服务的服务调用，来完成所述目标服务的服务治理；

其中，所述云原生注册中心是一种无状态的注册中心，其本身不保存任何数据信息、且其所需的所有数据信息均来源于Kubernetes自带的存储设施ETCD；所述云原生注册中心可以将监听到的MDS当前的服务信息和/或FDS当前的服务信息，按照key-value的方式进行组装，并存储至存储设施ETCD中。

2.根据权利要求1所述的方法，其特征在于，所述通过所述云原生注册中心获取所述目标服务当前对应的服务信息，包括：

通过所述云原生注册中心监听APIServer来获取所述MDS当前的服务信息和/或所述FDS当前的服务信息；

其中，所述MDS当前的服务信息与所述FDS当前的服务信息，均是通过CSF控制平台推送至所述APIServer中的。

3.根据权利要求1或2所述的方法，其特征在于，

所述MDS的服务信息包括路由策略信息、负载策略信息及运行模式切换策略信息中的至少一项；

所述FDS的服务信息包括服务降级策略信息、服务超时策略信息及服务熔断策略信息中的至少一项。

4.根据权利要求3所述的方法，其特征在于，所述根据所述目标服务当前对应的服务信息，确定所述目标服务当前对应的目标服务端，包括：

基于所述路由策略信息，通过所述云原生注册中心获取所述目标服务对应的路由地址，其中，所述路由地址对应一组PODIP；

基于所述负载策略信息，从所述一组PODIP中选定一个目标PODIP，并将所述目标PODIP对应的服务端确定为所述目标服务当前对应的目标服务端。

5.根据权利要求1或2所述的方法，其特征在于，

所述云原生注册中心通过发现服务xDS协议提供服务，并通过xDS服务器提供服务发现接口xDS API；其中，所述xDS位于所述云原生注册中心架构的最上层，其直接将所述云原生注册中心的服务治理的能力暴露给所述CSF客户端。

6.一种服务治理方法，其特征在于，应用于云原生注册中心，包括：

CSF客户端通过服务编码发起目标服务的服务调用时，获取所述目标服务当前对应的服务信息，所述服务信息包括微服务发现服务MDS的服务信息或业务接口发现服务FDS的服务信息中的至少一项；

向所述CSF客户端发送所服务信息，以使得所述CSF客户端根据所述服务信息确定所述目标服务当前对应的目标服务端，以及基于所述服务信息通过向所述目标服务端进行所述目标服务的服务调用，以完成所述目标服务的服务治理；

其中，所述云原生注册中心是一种无状态的注册中心，其本身不保存任何数据信息、且其所需的所有数据信息均来源于Kubernetes自带的存储设施ETCD；所述云原生注册中心可以将监听到的MDS当前的服务信息和/或FDS当前的服务信息，按照key-value的方式进行组装，并存储至存储设施ETCD中。

7.根据权利要求6所述的方法，其特征在于，所述获取所述目标服务当前对应的服务信息，包括：

通过监听APIServer来获取所述MDS当前的服务信息和/或所述FDS当前的服务信息；

其中，所述MDS当前的服务信息与所述FDS当前的服务信息，均是通过CSF控制平台推送至所述APIServer中的。

8.根据权利要求6或7所述的方法，其特征在于，

所述MDS的服务信息包括路由策略信息、负载策略信息及运行模式切换策略信息中的至少一项；

所述FDS的服务信息包括服务降级策略信息、服务超时策略信息及服务熔断策略信息中的至少一项。

9.根据权利要求6或7所述的方法，其特征在于，

所述云原生注册中心通过发现服务xDS协议提供服务，并通过xDS服务器提供服务发现接口xDS API；其中，所述xDS位于所述云原生注册中心架构的最上层，其直接将所述云原生注册中心的服务治理的能力暴露给所述CSF客户端。

10.一种服务治理装置，其特征在于，应用于云化服务框架CSF客户端，包括：

第一处理模块，用于通过服务编码发起目标服务的服务调用；

第二处理模块，用于通过所述云原生注册中心获取所述目标服务当前对应的服务信息，所述服务信息包括微服务发现服务MDS的服务信息或业务接口发现服务FDS的服务信息中的至少一项；

第三处理模块，用于根据所述服务信息，确定所述目标服务当前对应的目标服务端；

第四处理模块，用于基于所述服务信息，通过向所述目标服务端进行所述目标服务的服务调用，来完成所述目标服务的服务治理；

其中，所述云原生注册中心是一种无状态的注册中心，其本身不保存任何数据信息、且其所需的所有数据信息均来源于Kubernetes自带的存储设施ETCD；所述云原生注册中心可以将监听到的MDS当前的服务信息和/或FDS当前的服务信息，按照key-value的方式进行组装，并存储至存储设施ETCD中。

11.一种服务治理装置，其特征在于，应用于云原生注册中心，包括：

获取模块，用于CSF客户端通过服务编码发起目标服务的服务调用时，获取所述目标服务当前对应的服务信息，所述服务信息包括微服务发现服务MDS的服务信息或业务接口发现服务FDS的服务信息中的至少一项；

发送模块，用于向所述CSF客户端发送所服务信息，以使得所述CSF客户端根据所述服务信息确定所述目标服务当前对应的目标服务端，以及基于所述服务信息通过向所述目标服务端进行所述目标服务的服务调用，以完成所述目标服务的服务治理；

其中，所述云原生注册中心是一种无状态的注册中心，其本身不保存任何数据信息、且其所需的所有数据信息均来源于Kubernetes自带的存储设施ETCD；所述云原生注册中心可以将监听到的MDS当前的服务信息和/或FDS当前的服务信息，按照key-value的方式进行组装，并存储至存储设施ETCD中。

12.一种电子设备，包括存储器、处理器及存储在存储器上的计算机程序，其特征在于，所述处理器执行所述计算机程序以实现权利要求1-5任一项所述方法的步骤，或者，所述处理器执行所述计算机程序以实现权利要求6-9任一项所述方法的步骤。

13.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现权利要求1-5任一项所述的方法的步骤，或者，所述计算机程序被处理器执行时实现权利要求6-9任一项所述的方法的步骤。