CN113687919B - 一种微服务治理的控制方法、装置、设备及存储介质 - Google Patents

Abstract

本发明公开了一种微服务治理的控制方法，包括：根据k8s的目标自定义资源，获取目标组件的组件配置信息；其中，组件配置信息包括服务治理启停状态和/或边车容器Istio配额信息；根据组件配置信息，开启或禁用目标组件的服务治理；本发明通过根据k8s的目标自定义资源，获取目标组件的组件配置信息，利用k8s的自定义资源触发组件的服务治理的开启或禁用，使用户可以通过配置k8s的自定义资源，根据自身需求灵活控制业务组件的服务治理开启或禁用，提升了用户体验。此外，本发明还公开了一种微服务治理的控制装置、设备及计算机可读存储介质，同样具有上述有益效果。

Description

一种微服务治理的控制方法、装置、设备及存储介质

技术领域

本发明涉及微服务技术领域，特别涉及一种微服务治理的控制方法、装置、设备及计算机可读存储介质。

背景技术

在开发过程中随着整个系统变得庞大而难以应对，许多企业开始倾向于将其分解开来，转变为微服务架构。微服务架构的关键是采用服务网格的形式，使每个service(服务)实例之间的通信更加流畅、可靠和迅速。服务网格提供了诸如服务发现、负载均衡、加密、身份鉴定、授权、支持熔断器模式以及其他一系列功能。Istio作为优秀的微服务框架，逐渐被开发者所接受并且使用。Istio最大的特点是使用sidecar(边车)模式，在每个业务容器旁边自动启用一个Envoy(代理)容器，Istio让每个Envoy代理都可以访问来自和它关联的工作负载的所有端口的请求，然后转发到对应的工作负载，sidecar代理又代表服务管理请求，从而封装了服务间通信的复杂性

服务治理的启用与禁用是按照用户的需求进行合理规划的。对于业务比较复杂，而且作为流量的上游和下游调用微服务中其他接口，或者其接口被其他微服务调用比较频繁可以开启服务治理；对于业务简单的微服务，是没有必要进行访问代理的。而且不同应用的业务不同，会对微服务的开启状态的需求不同，甚至在同一应用中，不同工作负载(包括有状态负载和无状态负载)也有可能对是否开启服务治理有不同的要求。

现有技术中，sidecar注入方式有自动注入和手动注入。目前行业流行使用webhook(一种应用程序编程接口API概念)自动为工作负载注入边车容器；而原生的Istio设置比较固定，开启配置文件中控制服务治理开启的设置，会默认为每一个不添加固定注解的组件开启服务治理，否则不开启，这样就会严重影响用户网格规划，不利于用户体验。因此，如何能够根据用户的实际需求，自动开启或禁用业务组件的服务治理，提升用户体验，是现今急需解决的问题。

发明内容

本发明的目的是提供一种微服务治理的控制方法、装置、设备及计算机可读存储介质，以利用k8s(kubernetes，一个容器编排引擎)的自定义资源触发组件的服务治理的开启或禁用，提升了用户体验。

为解决上述技术问题，本发明提供一种微服务治理的控制方法，包括：

根据k8s的目标自定义资源，获取目标组件的组件配置信息；其中，所述组件配置信息包括服务治理启停状态和/或边车容器Istio配额信息；

根据所述组件配置信息，开启或禁用所述目标组件的服务治理。

可选的，所述根据k8s的目标自定义资源，获取目标组件的组件配置信息，包括：

根据所述目标自定义资源，获取目标应用的服务治理信息；其中，所述服务治理信息包括所述目标应用的服务治理状态和所述目标应用对应的组件配置信息，所述服务治理状态包括全应用开启状态、非全应用开启状态和应用禁用状态中的至少两项；

根据所述服务治理信息，确定目标应用对应的组件中的所述目标组件。

可选的，所述组件配置信息包括所述服务治理启停状态，所述服务治理状态包括所述全应用开启状态、所述非全应用开启状态和所述应用禁用状态时，所述根据所述服务治理信息，确定目标应用对应的组件中的目标组件，包括：

若所述服务治理状态为所述全应用开启状态，则将所述目标应用对应的全部组件确定为所述目标组件；其中，所述目标应用对应的全部组件的服务治理启停状态均为开启状态；

若所述服务治理状态为所述非全应用开启状态，则将所述目标应用对应的组件中服务治理启停状态为所述开启状态的组件确定为所述目标组件；

若所述服务治理状态为所述非全应用开启状态，则将所述目标应用对应的组件中服务治理启停状态为禁用状态的组件确定为所述目标组件。

可选的，所述服务治理状态包括所述全应用开启状态时，还包括：

在所述服务治理状态为所述全应用开启状态时，根据所述目标应用对应的边车容器Istio配额信息，开启所述目标应用对应的新添加的组件的服务治理。

可选的，所述根据k8s的目标自定义资源，获取目标组件的组件配置信息，包括：

根据所述目标自定义资源中spec字段中的组件信息，获取所述组件配置信息。

可选的，所述根据所述组件配置信息，开启或禁用所述目标组件的服务治理之后，还包括：

将所述目标组件对应的pod重启。

可选的，所述根据k8s的目标自定义资源，获取目标组件的组件配置信息之前，还包括：

根据获取的用户请求，配置所述目标自定义资源。

本发明还提供了一种微服务治理的控制装置，包括：

信息获取模块，用于根据k8s的目标自定义资源，获取目标组件的组件配置信息；其中，所述组件配置信息包括服务治理启停状态和/或边车容器Istio配额信息；

启停控制模块，用于根据所述组件配置信息，开启或禁用所述目标组件的服务治理。

本发明还提供了一种微服务治理的控制设备，包括：

存储器，用于存储计算机程序；

处理器，用于执行所述计算机程序时实现如上述所述的微服务治理的控制方法的步骤。

本发明还提供了一种计算机可读存储介质，所述计算机可读存储介质上存储有计算机程序，所述计算机程序被处理器执行时实现如上述所述的微服务治理的控制方法的步骤。

本发明所提供的一种微服务治理的控制方法，包括：根据k8s的目标自定义资源，获取目标组件的组件配置信息；其中，组件配置信息包括服务治理启停状态和/或边车容器Istio配额信息；根据组件配置信息，开启或禁用目标组件的服务治理；

可见，本发明通过根据k8s的目标自定义资源，获取目标组件的组件配置信息，利用k8s的自定义资源触发组件的服务治理的开启或禁用，使用户可以通过配置k8s的自定义资源，根据自身需求灵活控制业务组件的服务治理开启或禁用，提升了用户体验。此外，本发明还提供了一种微服务治理的控制装置、设备及计算机可读存储介质，同样具有上述有益效果。

附图说明

为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据提供的附图获得其他的附图。

图1为本发明实施例所提供的一种微服务治理的控制方法的流程图；

图2为本发明实施例所提供的另一种微服务治理的控制方法的流程示意图；

图3为本发明实施例所提供的一种微服务治理的控制装置的结构框图；

图4为本发明实施例所提供的一种微服务治理的控制设备的结构示意图；

图5为本发明实施例所提供的一种微服务治理的控制设备的具体结构示意图。

具体实施方式

为使本发明实施例的目的、技术方案和优点更加清楚，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

请参考图1，图1为本发明实施例所提供的一种微服务治理的控制方法的流程图。该方法可以包括：

步骤101：根据k8s的目标自定义资源，获取目标组件的组件配置信息；其中，组件配置信息包括服务治理启停状态和/或边车容器Istio配额信息。

可以理解的是，本步骤中的目标自定义资源可以为k8s中用户触发对目标组件服务治理的启用和禁用的自定义资源(crd资源)；例如本实施例中可以定义一个名为release的crd资源(即release crd)作为目标自定义资源，通过这个自定义资源触发对服务治理的启用与禁用流程。

具体的，本步骤中的目标组件可以为需要进行服务治理的启停控制的组件，如应用的业务组件；本步骤中的目标组件的组件配置信息可以为从k8s的目标自定义资源中获取的配置目标组件的服务治理的开启或禁用的信息。对于本步骤中的组件配置信息的具体内容，可以由设计人员根据实用场景和用户需求自行设置，如组件配置信息可以包括服务治理启停状态，如开启状态或禁用状态；例如服务治理启停状态为开启状态时，处理器可以根据预设的目标组件所属的应用(即目标应用)对应的边车容器(sidecar)Istio配额信息，为目标组件开启服务治理；服务治理启停状态为禁用状态时，处理器可以禁用目标组件的服务治理。组件配置信息也可以包括边车容器Istio配额信息，使用户可以灵活配置每个组件中Istio的配额，从而使用户选择应用中某些组件开启服务治理时候，可以指定每个组件中注入的sidecar的配额信息，实现了对一个网格内不同组件中边车容器配额的灵活配置；例如处理器可以在目标组件的边车容器Istio配额信息不为空时，利用边车容器Istio配额信息为目标组件开启服务治理；在目标组件的边车容器Istio配额信息为空时，禁用目标组件的服务治理。组件配置信息还可以包括服务治理启停状态和边车容器Istio配额信息；例如处理器可以在服务治理启停状态为开启状态时，利用目标组件的边车容器Istio配额信息为目标组件开启服务治理；在服务治理启停状态为禁用状态时，禁用目标组件的服务治理。本实施例对此不做任何限制。

具体的，对于本步骤中处理器根据k8s的目标自定义资源，获取目标组件的组件配置信息的具体方式，可以由设计人员根据实用场景和用户需求自行设置，如处理器可以直接从k8s的目标自定义资源，获取各需要进行服务治理的启停控制的组件(即目标组件)的组件配置信息；例如直接将服务治理启停状态不为空的组件确定为目标组件。处理器也可以根据k8s的目标自定义资源，获取目标应用的服务治理信息；根据服务治理信息，确定目标应用对应的组件中的目标组件；其中，服务治理信息包括目标应用的服务治理状态和目标应用对应的组件配置信息，服务治理状态包括全应用开启状态、非全应用开启状态和应用禁用状态中的至少两项；也就是说，处理器可以利用应用的服务治理状态，从属于该应用的组件中确定目标组件。本实施例对此不做任何限制。

需要说明的是，以云管理平台为例，应用是一个业务系统下的多工作负载的集合；在应用中可以通过添加工作负载增加业务系统，同时也可以关联新建的工作负载到应用；在同一应用下的网络是互通的，不同工作负载负责不同的业务模块，比如存储、网络、网关和镜像管理等，这些模块采用微服务架构，构成一个庞大的业务系统。这样往往会产生两种诉求：一是全应用开启，即在此应用中的全部组件都会注入sidecar，开启服务治理，并且后续添加到应用的组件也要自动开启服务治理，在服务网格的框架下工作；二是在应用中依照用户的实际需求为组件开启服务治理，只有用户指定开启的组件才会纳入网格管理，其他不需要的业务组件不需要开启服务治理，后续添加到应用的组件默认不开启服务治理。因此，本实施例中可以通过应用级别的服务治理状态，定义三种服务治理状态：全应用开启状态；非全应用开启状态，即部分组件开启的状态和应用禁用状态；也就是说，上述目标应用的服务治理信息中的服务治理状态包括全应用开启状态、非全应用开启状态和应用禁用状态，从而适配用户使用的不同场景，分级别设置服务治理的启用和禁用，使用户能够灵活配置一个应用的网格大小。服务治理状态可以为包括全应用开启状态、非全应用开启状态和应用禁用状态中的两种或其他状态(如全应用禁用状态)，本实施例对此不做任何限制。

具体的，上述目标应用可以为目标组件对应的应用，即目标组件所属的应用。本实施例中可以在k8s的目标自定义资源(如release crd)中spec字段的components(成分)里面定义每一个组件的基本信息(即组件信息)，可以包括是否需要开启服务治理的服务治理启停状态(如ifEnableMesh)和注入的边车容器Istio配额信息(如istioconfig)；并且k8s的目标自定义资源的字段中可以包括应用的服务治理状态，如使用releasemeshStatus来标记；而服务治理状态为全应用开启状态时，后续应用增加的组件所需的边车容器Istio配额可以放在该应用的边车容器Istio配额信息中，即在服务治理状态为全应用开启状态时，处理器根据目标应用的边车容器Istio配额信息，开启目标应用对应的新添加的组件的服务治理。

也就是说，如图2所示，用户可以通过发送请求(即用户请求)修改k8s的目标自定义资源(Release CRD资源)中相应的字段，配置目标自定义资源，从而实现对目标组件的治理服务(Wordload1和Wordload 2等)的启停控制。即本步骤之前处理器可以根据获取的用户请求，配置目标自定义资源；例如用户可以通过kubelet(k8s工作节点上的一个代理组件)访问修改目标自定义资源(如release crd资源)中相应的字段，通过目标自定义资源触发对服务治理的启停控制。

对应的，上述根据服务治理信息，确定目标应用对应的组件中的目标组件的具体方式，可以由设计人员自行设置，例如，若目标应用的服务治理状态为全应用开启状态，则将目标应用对应的全部组件确定为目标组件；其中，目标应用对应的全部组件的服务治理启停状态均为开启状态。若目标应用的服务治理状态为非全应用开启状态，则将目标应用对应的组件中服务治理启停状态为开启状态的组件确定为目标组件。若目标应用的服务治理状态为非全应用开启状态，则将目标应用对应的组件中服务治理启停状态为禁用状态的组件确定为目标组件。

步骤102：根据组件配置信息，开启或禁用目标组件的服务治理。

具体的，本步骤中处理器可以根据目标组件的组件配置信息，对应控制目标组件的服务治理的开启或禁用。例如处理器可以根据目标组件的组件配置信息，控制对应底层组件进行调谐，从而开启或禁用目标组件的服务治理。

例如，用户想要全应用级别开启服务治理，可以通过用户请求，修改k8s中releasecrd资源的字段中releasemeshStatus为全应用开启状态，并且添加应用的istioconfig(即边车容器Istio配额信息)字段；由于是全应用开启，对于应用中已经存在的组件，也需要全部开启的服务治理，因此对于已经存在的组件也要把spec字段的components下面的对应组件信息的ifEnableMesh(即服务治理启停状态)设置为true(即开启状态)；在release crd资源中的上述修改变动可以触发对应底层组件(deployment,statefulset)的调谐，通过添加注解sidecar.istio.io/inject＝true为应用的全部组件(即目标组件)开启服务治理；而后续添加到该应用中的组件可以在感知所在应用的服务治理状态为全应用开启状态后，也可以触发底层组件增加注解实现自动注入，开启服务治理。

用户想要启用应用中部分组件的服务治理，如一个应用中有10个组件，需要给其中的5个开启服务治理，剩下5个组件的不需要纳入Istio管理。在这种情况下，只给应用中部分组件开启服务治理，可以通过用户请求，修改k8s中release crd资源的字段中releasemeshStatus为非全应用开启状态(即非全应用开启但是有组件开启的状态)；对于用户希望开启服务治理的组件，spec字段的components下面的对应组件信息的ifEnableMesh可以设置为true，并且配置可以控制每个组件的边车容器Istio配额信息(istioconfig)；在release crd资源中的上述修改变动会触发对应底层组件(deployment,statefulset)的调谐，通过添加注解sidecar.istio.io/inject＝true为组件开启服务治理。

用户想要禁用组件的服务治理，即用户希望对已经开启服务治理的组件进行禁用时，可以通过用户请求，修改k8s中release crd资源的字段中releasemeshStatus为应用禁用状态；对于用户希望禁用服务治理的组件，spec字段的components下面的对应组件信息的ifEnableMesh可以设置为false(即禁用状态)，在release crd资源中的上述修改变动会触发对应底层组件(deployment,statefulset)的调谐，通过更新注解sidecar.istio.io/inject＝false为组件禁用服务治理。

对应的，本步骤中处理器可以在开启或禁用目标组件的服务治理后，将目标组件对应的pod(k8s中最小的调度单元)重启，即重启目标组件所在的pod，以保证后续服务治理调整的组件能够正常工作。

本实施例中，本发明实施例通过根据k8s的目标自定义资源，获取目标组件的组件配置信息，利用k8s的自定义资源触发组件的服务治理的开启或禁用，使用户可以通过配置k8s的自定义资源，根据自身需求灵活控制业务组件的服务治理开启或禁用，提升了用户体验。

相应于上面的方法实施例，本发明实施例还提供了一种微服务治理的控制装置，下文描述的一种微服务治理的控制装置与上文描述的一种微服务治理的控制方法可相互对应参照。

请参考图3，图3为本发明实施例所提供的一种微服务治理的控制装置的结构框图。该装置可以包括：

信息获取模块10，用于根据k8s的目标自定义资源，获取目标组件的组件配置信息；其中，组件配置信息包括服务治理启停状态和/或边车容器Istio配额信息；

启停控制模块20，用于根据组件配置信息，开启或禁用目标组件的服务治理。

可选的，信息获取模块10可以包括：

应用获取子模块，用于根据目标自定义资源，获取目标应用的服务治理信息；其中，服务治理信息包括目标应用的服务治理状态和目标应用对应的组件配置信息，服务治理状态包括全应用开启状态、非全应用开启状态和应用禁用状态中的至少两项；

组件确定子模块，用于根据服务治理信息，确定目标应用对应的组件中的目标组件。

可选的，组件配置信息包括服务治理启停状态，服务治理状态包括全应用开启状态、非全应用开启状态和应用禁用状态时，启停控制模块20可以包括：

第一控制子模块，用于若服务治理状态为全应用开启状态，则将目标应用对应的全部组件确定为目标组件；其中，目标应用对应的全部组件的服务治理启停状态均为开启状态；

第二控制子模块，用于若服务治理状态为非全应用开启状态，则将目标应用对应的组件中服务治理启停状态为开启状态的组件确定为目标组件；

第三控制子模块，用于若服务治理状态为非全应用开启状态，则将目标应用对应的组件中服务治理启停状态为禁用状态的组件确定为目标组件。

可选的，服务治理状态包括全应用开启状态时，该装置还可以包括：

开启控制模块，用于在服务治理状态为全应用开启状态时，根据目标应用对应的边车容器Istio配额信息，开启目标应用对应的新添加的组件的服务治理。

可选的，信息获取模块10可以具体用于根据目标自定义资源中spec字段中的组件信息，获取组件配置信息。

可选的，该装置还可以包括：

重启模块，用于将目标组件对应的pod重启。

可选的，该装置还可以包括：

资源配置模块，用于根据获取的用户请求，配置目标自定义资源。

本实施例中，本发明实施例通过信息获取模块10根据k8s的目标自定义资源，获取目标组件的组件配置信息，利用k8s的自定义资源触发组件的服务治理的开启或禁用，使用户可以通过配置k8s的自定义资源，根据自身需求灵活控制业务组件的服务治理开启或禁用，提升了用户体验。

相应于上面的方法实施例，本发明实施例还提供了一种微服务治理的控制设备，下文描述的一种微服务治理的控制设备与上文描述的一种微服务治理的控制方法可相互对应参照。

请参考图4，图4为本发明实施例所提供的一种微服务治理的控制设备的结构示意图。该微服务治理的控制设备可以包括：

存储器D1，用于存储计算机程序；

处理器D2，用于执行计算机程序时实现上述方法实施例所提供的微服务治理的控制方法的步骤。

具体的，请参考图5，图5为本发明实施例所提供的一种微服务治理的控制设备的具体结构示意图，该微服务治理的控制设备310可因配置或性能不同而产生比较大的差异，可以包括一个或一个以上处理器(central processing units，CPU)322(例如，一个或一个以上处理器)和存储器332，一个或一个以上存储应用程序342或数据344的存储介质330(例如一个或一个以上海量存储设备)。其中，存储器332和存储介质330可以是短暂存储或持久存储。存储在存储介质330的程序可以包括一个或一个以上单元(图示没标出)，每个单元可以包括对数据处理设备中的一系列指令操作。更进一步地，中央处理器322可以设置为与存储介质330通信，在微服务治理的控制设备310上执行存储介质330中的一系列指令操作。

对微服务治理的控制设备310还可以包括一个或一个以上电源326，一个或一个以上有线或无线网络接口350，一个或一个以上输入输出接口358，和/或，一个或一个以上操作系统341。例如，Windows ServerTM，Mac OS XTM，UnixTM，LinuxTM，FreeBSDTM等。

其中，微服务治理的控制设备310可以为k8s集群的服务器。

上文所描述的微服务治理的控制方法中的步骤可以由微服务治理的控制设备的结构实现。

相应于上面的方法实施例，本发明实施例还提供了一种计算机可读存储介质，下文描述的一种计算机可读存储介质与上文描述的一种微服务治理的控制方法可相互对应参照。

一种计算机可读存储介质，计算机可读存储介质上存储有计算机程序，计算机程序被处理器执行时实现如上述实施例所提供的微服务治理的控制方法的步骤。

该计算机可读存储介质具体可以为U盘、移动硬盘、只读存储器(Read-OnlyMemory，ROM)、随机存取存储器(Random Access Memory，RAM)、磁碟或者光盘等各种可存储程序代码的计算机可读存储介质。

说明书中各个实施例采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似部分互相参见即可。对于实施例公开的装置、设备及计算机可读存储介质而言，由于其与实施例公开的方法相对应，所以描述的比较简单，相关之处参见方法部分说明即可。

以上对本发明所提供的一种微服务治理的控制方法、装置、设备及计算机可读存储介质进行了详细介绍。本文中应用了具体个例对本发明的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本发明的方法及其核心思想。应当指出，对于本技术领域的普通技术人员来说，在不脱离本发明原理的前提下，还可以对本发明进行若干改进和修饰，这些改进和修饰也落入本发明权利要求的保护范围内。

Claims (8)

1.一种微服务治理的控制方法，其特征在于，包括：

根据k8s的目标自定义资源，获取目标组件的组件配置信息；其中，所述组件配置信息包括服务治理启停状态和/或边车容器Istio配额信息；

根据所述组件配置信息，开启或禁用所述目标组件的服务治理；

其中，所述根据k8s的目标自定义资源，获取目标组件的组件配置信息，包括：

根据所述目标自定义资源，获取目标应用的服务治理信息；其中，所述服务治理信息包括所述目标应用的服务治理状态和所述目标应用对应的组件配置信息，所述服务治理状态包括全应用开启状态、非全应用开启状态和应用禁用状态中的至少两项；

根据所述服务治理信息，确定目标应用对应的组件中的所述目标组件；

相应的，所述组件配置信息包括所述服务治理启停状态，所述服务治理状态包括所述全应用开启状态、所述非全应用开启状态和所述应用禁用状态时，所述根据所述服务治理信息，确定目标应用对应的组件中的目标组件，包括：

若所述服务治理状态为所述全应用开启状态，则将所述目标应用对应的全部组件确定为所述目标组件；其中，所述目标应用对应的全部组件的服务治理启停状态均为开启状态；

若所述服务治理状态为所述非全应用开启状态，则将所述目标应用对应的组件中服务治理启停状态为所述开启状态的组件确定为所述目标组件；

若所述服务治理状态为所述非全应用开启状态，则将所述目标应用对应的组件中服务治理启停状态为禁用状态的组件确定为所述目标组件。

2.根据权利要求1所述的微服务治理的控制方法，其特征在于，所述服务治理状态包括所述全应用开启状态时，还包括：

在所述服务治理状态为所述全应用开启状态时，根据所述目标应用对应的边车容器Istio配额信息，开启所述目标应用对应的新添加的组件的服务治理。

3.根据权利要求1所述的微服务治理的控制方法，其特征在于，所述根据k8s的目标自定义资源，获取目标组件的组件配置信息，包括：

根据所述目标自定义资源中spec字段中的组件信息，获取所述组件配置信息。

4.根据权利要求1所述的微服务治理的控制方法，其特征在于，所述根据所述组件配置信息，开启或禁用所述目标组件的服务治理之后，还包括：

将所述目标组件对应的pod重启。

5.根据权利要求1所述的微服务治理的控制方法，其特征在于，所述根据k8s的目标自定义资源，获取目标组件的组件配置信息之前，还包括：

根据获取的用户请求，配置所述目标自定义资源。

6.一种微服务治理的控制装置，其特征在于，包括：

信息获取模块，用于根据k8s的目标自定义资源，获取目标组件的组件配置信息；其中，所述组件配置信息包括服务治理启停状态和/或边车容器Istio配额信息；

启停控制模块，用于根据所述组件配置信息，开启或禁用所述目标组件的服务治理；

其中，所述信息获取模块包括：

应用获取子模块，用于根据所述目标自定义资源，获取目标应用的服务治理信息；其中，所述服务治理信息包括所述目标应用的服务治理状态和所述目标应用对应的组件配置信息，所述服务治理状态包括全应用开启状态、非全应用开启状态和应用禁用状态中的至少两项；

组件确定子模块，用于根据所述服务治理信息，确定目标应用对应的组件中的所述目标组件；

相应的，所述组件配置信息包括所述服务治理启停状态，所述服务治理状态包括所述全应用开启状态、所述非全应用开启状态和所述应用禁用状态时，所述组件确定子模块包括：

第一控制子模块，用于若所述服务治理状态为所述全应用开启状态，则将所述目标应用对应的全部组件确定为所述目标组件；其中，所述目标应用对应的全部组件的服务治理启停状态均为开启状态；

第二控制子模块，用于若所述服务治理状态为所述非全应用开启状态，则将所述目标应用对应的组件中服务治理启停状态为所述开启状态的组件确定为所述目标组件；

第三控制子模块，用于若所述服务治理状态为所述非全应用开启状态，则将所述目标应用对应的组件中服务治理启停状态为禁用状态的组件确定为所述目标组件。

7.一种微服务治理的控制设备，其特征在于，包括：

存储器，用于存储计算机程序；

处理器，用于执行所述计算机程序时实现如权利要求1至5任一项所述的微服务治理的控制方法的步骤。

8.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质上存储有计算机程序，所述计算机程序被处理器执行时实现如权利要求1至5任一项所述的微服务治理的控制方法的步骤。