CN113765944A - 一种微服务治理方法、装置、设备和存储介质 - Google Patents

Abstract

本发明提出了一种微服务治理方法、装置、电子设备和计算机存储介质，所述方法包括：获取微服务治理请求，所述微服务治理请求中携带有微服务的标识信息和所述微服务对应的至少一个微服务治理规则的标识信息；根据所述微服务治理请求，对所述微服务对应的至少一个微服务治理规则进行统一管理。如此，可以实现对多条服务治理规则的统一管理，降低管理的复杂度。

Description

一种微服务治理方法、装置、设备和存储介质

技术领域

本发明涉及微服务治理技术，尤其涉及一种治理方法、装置、电子设备和计算机存储介质。

背景技术

相关技术中，随着越来越多的单体应用拆分为微服务架构，微服务变得越来越多，微服务之间的依赖关系变得复杂，引入的问题越来越复杂。如何在业务发展的同时，保障服务的高可用性、稳定性，及最大化利用机器资源，是越来越现实的问题。

为解决微服务带来的问题，微服务治理变得越来越迫切。服务治理主要包括服务发现、服务调度、服务配置管理等。服务调度包括客户端与服务端的负载均衡、服务路由、升降级熔断和监控。同时，以Spring Cloud为代表的传统微服务治理方法，对应用逻辑有一定的侵入性，让业务人员不能只专注于业务本身，还需要关心那些治理逻辑。

在此背景下，新型的服务网格的微服务治理方法应运而生，如Istio等。Istio为微服务治理带来了极其丰富的功能，支持超文本传输协议(Hyper Text Transfer Protocol，HTTP，)、grpc等协议的流量的自动复制均衡；通过丰富的路由规则、故障转移与注入、超时重试等机制，可对流量行为进行非常细粒度的控制；可实现任一服务的所有流量的度量指标、日志记录与追踪等。

Istio是一种新型的微服务治理方法，其通过一种简单的方式为已部署的服务建立网络，所建立的网络具有服务间认证、负载均衡、路由控制、网关、监控等功能，只需要对服务的代码进行一点或者不需要作任何改动，应用开发人员无需关注治理逻辑，且适用于任意编程语言开发的服务，但该方法在对服务治理规则进行创建、修改或删除等操作时，是通过在kubernetes中对Istio CRD进行对应的配置来实现的，当服务创建多条服务治理规则时，需要针对各条服务治理规则进行配置，操作比较复杂。

发明内容

本申请提供了一种微服务方法、装置、电子设备和计算机存储介质，可以解决当服务创建多条服务治理规则时，不能有效地进行归类管理的问题。

本发明提供了一种微服务治理方法，所述方法包括：

获取微服务治理请求，所述微服务治理请求中携带有微服务的标识信息和所述微服务对应的至少一个微服务治理规则的标识信息；

根据所述微服务治理请求，对所述微服务对应的至少一个微服务治理规则进行统一管理。

可选地，所述对所述微服务对应的至少一个微服务治理规则进行统一管理，包括：

根据所述微服务治理请求，确定所述微服务对应的至少一个微服务治理规则发生更改时，根据针对所述微服务对应的至少一个微服务治理规则的更改操作，对所述微服务对应的至少一个微服务治理规则进行更改。

可选地，所述更改操作包括以下至少一种操作：创建操作、删除操作、修改操作。

可选地，所述更改操作包括创建操作时，所述对所述微服务对应的至少一个微服务治理规则进行更改，包括：创建微服务的标识信息、以及所述微服务对应的命名空间。

可选地，所述微服务治理规则包括以下至少一项：负载均衡、流量分发、超时重试、错误注入、熔断机制。

可选地，所述微服务治理请求还携带有业务集群的标识信息；所述获取微服务治理请求，包括：在所述微服务治理请求还携带的业务集群的标识信息与预设的业务集群的标识信息匹配时，接收所述微服务治理请求。

本发明实施例还提供了一种微服务治理装置，所述装置包括：获取模块和管理模块，其中，

获取模块，用于获取微服务治理请求，所述微服务治理请求中携带有微服务的标识信息和所述微服务对应的至少一个微服务治理规则的标识信息；

管理模块，用于根据所述微服务治理请求，对所述微服务对应的至少一个微服务治理规则进行统一管理。

可选地，所述管理模块用于根据所述微服务治理请求，确定所述微服务对应的至少一个微服务治理规则发生更改时，根据针对所述微服务对应的至少一个微服务治理规则的更改操作，对所述微服务对应的至少一个微服务治理规则进行更改。

可选地，所述更改操作包括以下至少一种操作：创建操作、删除操作、修改操作。

可选地，所述管理模块用于创建微服务的标识信息、以及所述微服务对应的命名空间。

可选地，所述微服务治理规则包括以下至少一项：负载均衡、流量分发、超时重试、错误注入、熔断机制。

可选地，所述获取模块用于在所述微服务治理请求还携带的业务集群的标识信息与预设的业务集群的标识信息匹配时，接收所述微服务治理请求。

本发明实施例还提供了一种电子设备，包括处理器和用于存储能够在处理器上运行的计算机程序的存储器；其中，

所述处理器用于运行所述计算机程序时，执行上述任意一种微服务治理方法。

本发明还提供了一种计算机存储介质，其上存储有计算机程序，该计算机程序被处理器执行时实现上述任意一种所述的微服务方法。

本发明提出的微服务治理方法，根据所获取的微服务治理请求，对微服务对应的至少一个微服务治理规则进行统一管理，其中，微服务治理请求中携带有微服务的标识信息和所述微服务对应的至少一个微服务治理规则的标识信息，可以实现同一微服务下的多个治理规则的统一管理，降低管理的复杂度，具体地，通过对微服务治理规则的分类，可以实现对多种微服务治理规则的归类管理，极大简化了管理的复杂性，且无需对创建的每条服务治理规则都创建治理规则标识以及治理规则对应的命名空间，而只需要在创建规则整合组件中创建微服务的标识信息和微服务对应的命名空间即可。

应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，而非限制本发明。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，这些附图示出了符合本发明的实施例，并与说明书一起用于说明本发明的技术方案。

图1为相关技术中Istio的框架示意图；

图2为本发明的微服务治理方法的流程图；

图3为本发明的微服务治理方法PaaS-Mesh的架构图；

图4为本发明的规则整合组件中微服务治理规则的更改操作示意图；

图5为本发明的微服务治理装置的组成结构示意图；

图6为本发明的电子设备的结构示意图。

具体实施方式

以下结合附图及实施例，对本发明进行进一步详细说明。应当理解，此处所提供的实施例仅仅用以解释本发明，并不用于限定本发明。另外，以下所提供的实施例是用于实施本发明的部分实施例，而非提供实施本发明的全部实施例，在不冲突的情况下，本发明实施例记载的技术方案可以任意组合的方式实施。

需要说明的是，在本发明实施例中，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的方法或者装置不仅包括所明确记载的要素，而且还包括没有明确列出的其他要素，或者是还包括为实施方法或者装置所固有的要素。在没有更多限制的情况下，由语句“包括一个......”限定的要素，并不排除在包括该要素的方法或者装置中还存在另外的相关要素(例如方法中的步骤或者装置中的单元，例如的单元可以是部分电路、部分处理器、部分程序或软件等等)。

本文中术语“和/或”，仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。另外，本文中术语“至少一种”表示多种中的任意一种或多种中的至少两种的任意组合，例如，包括A、B、C中的至少一种，可以表示包括从A、B和C构成的集合中选择的任意一个或多个元素。

例如，本发明实施例提供的微服务治理方法包含了一系列的步骤，但是本发明实施例提供的微服务治理法不限于所记载的步骤，同样地，本发明实施例提供的微服务治理装置包括了一系列模块，但是本发明实施例提供的装置不限于包括所明确记载的模块，还可以包括为获取相关信息、或基于信息进行处理时所需要设置的模块。

本发明实施例可以应用于kubernetes应用平台中，kubernetes应用平台是用于提供了应用部署，规划，更新，维护的一种机制，可以让部署容器化的应用简单并且高效。

图1为相关技术中Istio的框架示意图，如图1所示，代理Proxy相当于边车代理sidecar envoy，服务A的代理(Proxy)通过协议HTTP/1.1，HTTP/2，带有或不带相互安全传输层协议(mutual Transport Layer Security mTLS)的grpc或传输控制协议(Transmission Control Protocol，TCP)向服务B的Proxy发出调用请求，在服务A调用服务B之前，需要进行权限检查(policy checks)以确定服务A是否可以调用服务B并将服务A调用服务B的请求上报给服务B的proxy，混合器(Mixer)用于在服务A调用服务B之前进行流量和安全性的检查，检查是以适配器的方式集成在Mixer中来实现的，第一下发模块用于将治理规则下发给Proxy，第二下发模块用于将配置信息发给Mixer，第三下发模块用于将安全传输层协议(Transport Layer Security，TLS)证书信息下发给Proxy。

以isito为代表的新一代服务网格的微服务治理方法，是针对Spring Cloud系列的改良，其采用sidecar代理的方式，使应用开发人员无需关注治理逻辑，且该方式与语言无关，任一编程语言开发的服务，都可采用该治理方法。但该治理方法存在一定的局限性，在创建服务治理规则时，是通过在kubernetes中配置Istio自定义资源(CRD，CustomResource Definition)实现的，当服务创建多条服务治理规则时，配置服务治理规则比较复杂，不能有效地进行归类管理。

针对上述技术问题，在本发明的一些实施例中，提出了一种微服务治理方法，可以应用于任一业务集群中，业务集群可以是kubernetes业务集群；多个业务集群可以分别与管理集群相连接，通过管理集群实现对业务集群的管理，具体地，对业务集群的管理可以包括业务集群的创建或删除。

图2为本发明的微服务治理方法的流程图，如图2所示，该流程可以包括：

步骤101：获取微服务治理请求，所述微服务治理请求中携带有微服务的标识信息和所述微服务对应的至少一个微服务治理规则的标识信息；

这里，微服务的标识信息可以是用于确定该微服务治理请求具体是对哪个微服务进行治理的标识信息，具体地，微服务的标识信息可以是指微服务的名称或是微服务对应的数字代码，例如，当存在微服务A、微服务B和微服务C等时，微服务的标识信息可以是微服务的名称A、B或C等，当然，微服务的标识信息也可以是数字代码1、2和3等，用于分别代表微服务A、微服务B和微服务C等。

对于微服务对应的至少一个微服务治理规则的标识信息的实现方式，示例性地，可以是用于确定该微服务治理请求所涉及的所有微服务治理规则的标识信息，其中，微服务治理规则的数量是根据微服务治理请求即需求来确定的，这里不对所涉及的微服务治理规则的数量进行限制，可以是一个微服务治理规则，也可以是多个微服务治理规则，对应的，微服务治理规则的标识信息可以是一个微服务治理规则的标识信息，也可以是多个微服务治理规则的标识信息。同时，这里不对微服务治理规则的标识信息的具体表示形式进行限制，微服务治理规则的标识信息的具体表示形式可以是微服务治理规则的名称或微服务规则对应的数字代码，例如，微服务治理规则的标识信息可以分别是规则1、规则2和规则3等微服务治理规则的名称，微服务治理规则的标识信息也可以分别是数字1、数字2和数字3等微服务规则对应的数字代码。

对于所述微服务治理请求中携带有微服务的标识信息和所述微服务对应的至少一个微服务治理规则的标识信息的实现方式，示例性地，微服务治理请求中包含微服务的名称A、规则1和规则2，即微服务请求是针对微服务A的规则1和规则2的治理请求。

在一种实施方式中，业务集群中可以包括转发组件，获取微服务治理请求的方式可以是通过转发组件接收微服务治理请求，具体地，转发组件可以是kubernetes业务集群中的应用程序接口服务器(Application Programming Interface，API)server组件，进而可以通过转发组件接收微服务治理请求并对接收到的微服务治理请求进行处理和转发。

在一种实施方式中，管理集群可以包括管理组件，管理组件可以将管理组件接收到的微服务治理请求转发给业务集群中的转发组件，这里，管理组件用于对多集群环境下的微服务治理进行管理，具体地，管理组件可以是名称标识为Mesh Web的组件，实际应用中，可以通过多副本的方式实现管理组件的高可用性。

在一实施方式中，业务集群还包括规则整合组件，转发组件在接收到微服务治理请求后可以将该微服务治理请求转发给业务集群中的规则整合组件，在微服务治理请求所携带的微服务的标识信息与规则整合组件中预设的微服务的标识信息匹配时，转发组件将微服务治理请求转发给对应的规则整合组件。这里，可以在规则整合组件中预先设置微服务的标识信息，且如果微服务治理请求中携带的微服务的标识信息与规则整合组件中预设的微服务的标识信息完全一致时，认为微服务治理请求所携带的微服务的标识信息与规则整合组件中预设的微服务的标识信息相匹配，如果微服务治理请求中携带的微服务的标识信息与规则整合组件中预设的微服务的标识信息不完全一致时，认为微服务治理请求所携带的微服务的标识信息与规则整合组件中预设的微服务的标识信息不匹配。

具体地，规则整合组件可以是名称标识为Mesh CRD的组件，规则整合组件可以是对kubernetes应用程序接口(API，Application programming interface)的扩展，kubernetes中的每个资源都是一个API对象集合，且每个微服务在创建微服务治理规则时，都将对应创建一个Mesh CRD。在同一个微服务下，创建多条微服务治理规则，也只会创建一个微服务的Mesh CRD。

步骤102：根据所述微服务治理请求，对所述微服务对应的至少一个微服务治理规则进行统一管理。

在一个示例中，业务集群还可以包括控制组件，确定微服务治理请求对应的规则整合组件，确定的规则整合组件接收到微服务治理请求后，对微服务请求所对应的治理规则进行设置，并配合控制组件，创建治理规则对应的多个Istio CRD组件，然后将治理规则转发给Istio组件，经由Istio组件将服务治理规则，应用到服务中部署的应用组件中，这里，应用组件可以是sidecar envoy组件，控制组件可以是名称标识为Mesh Controller组件。

具体地，控制组件可以是指用于监听规则整合组件的资源变化的组件，控制组件可以通过对规则整合组件中设置的服务治理规则进行分析和整合处理，创建治理规则对应的多个Istio CRD组件。

在一个示例中，当微服务请求包含微服务的名称A、规则1和规则2时，对微服务对应的至少一个微服务治理规则进行统一管理，可以是将规则1和规则2添加到规则整合组件中，控制组件监控到规则1和规则2的添加，对规则1和规则2进行分析和整合，建立规则1和规则2对应的多个Istio CRD组件，并将规则1和规则2对应的多个Istio CRD组件转发给Istio组件，经由Istio组件将规则1和规则2对应的多个Istio CRD组件，应用到服务中部署的应用组件sidecar envoy组件中。

本发明所提出的微服务治理方法是基于kubernetes平台与istio的开源的微服务治理方法，该方法可称为平台即服务(PaaS-Mesh，Platform-as-a-Service)。

图3为本发明的微服务治理方法PaaS-Mesh的架构图，如图3所示，管理组件(MeshWeb)位于管理集群中，转发组件(API Server)、规则整合组件(Mesh CRD)、控制组件(MeshController)、Istio CRD组件和Istio组件位于业务集群1或业务集群N中，其中，管理组件、规则整合组件和控制组件是本发明的新增组件，业务集群可以是kubernetes集群。具体地，基于图3所示的微服务治理框架，本实施例的微服务治理方法可以是：管理组件接收到服务治理请求，并将服务治理请求转发给对应的业务集群的转发组件，转发组件将服务治理请求转发给对应的规则整合组件，规则整合组件根据所接收到的服务治理请求设置对应的治理规则，控制组件监听到治理规则的变化，并将治理规则变化进行对应的处理，更新IstioCRD组件，最后将治理规则变化应用到服务器中的应用组件中。

在实际应用中，步骤101至步骤102可以利用业务集群中的处理器实现，上述处理器可以为特定用途集成电路(Application Specific Integrated Circuit，ASIC)、数字信号处理器(Digital Signal Processor，DSP)、数字信号处理装置(Digital SignalProcessing Device，DSPD)、可编程逻辑装置(Programmable Logic Device，PLD)、FPGA、中央处理器(Central Processing Unit，CPU)、控制器、微控制器、微处理器中的至少一种。

可以看出，本发明实施例提出的微服务治理方法，根据所获取的微服务治理请求，对微服务对应的至少一个微服务治理规则进行统一管理，其中，微服务治理请求中携带有微服务的标识信息和所述微服务对应的至少一个微服务治理规则的标识信息，可以实现同一微服务下的治理规则的统一管理。

在一种实施方式中，对所述微服务对应的至少一个微服务治理规则进行统一管理，包括：根据微服务治理请求，确定微服务对应的至少一个微服务治理规则发生更改时，根据针对微服务对应的至少一个微服务治理规则的更改操作，对微服务对应的至少一个微服务治理规则进行更改。

对于根据所述微服务治理请求，确定微服务器对应的至少一个微服务治理规则发生更改的实现方式，示例性地，可以是根据微服务治理请求中携带的微服务对应的至少一个微服务治理规则的标识信息，确定微服务器对应的至少一个微服务治理规则发生更改，例如，微服务对应的至少一个微服务治理规则的标识信息可以是删除治理规则1和修改治理规则2，进而，可以确定微服务器对应的规则1和规则2发生更改。

对于根据针对所述微服务对应的至少一个微服务治理规则的更改操作的实现方式，示例性地，可以是在上述的规则整合组件中设置微服务对应的至少一个微服务治理规则，例如，直接在规则整合组件中对微服务治理规则进行更改操作。

对所述微服务对应的至少一个微服务治理规则进行更改，具体地，可以通过上述所述的微服务的控制组件，更改治理规则对应的多个Istio CRD组件，然后将治理规则转发给Istio组件，经由Istio组件将服务治理规则，应用到服务中部署的应用组件中，以实现对微服务治理规则的更改。

在一种实施方式中，所述更改操作包括以下至少一种操作：创建操作、删除操作、修改操作。

这里，创建操作可以是设置或添加治理规则程序的操作，删除操作可以是删除治理规则程序的操作，修改操作可以是修改治理程序的操作，例如，添加操作可以是在规则整合组件中添加对应的治理规则1的程序，删除操作可以是删除规则整合组件中治理规则2对应的程序，修改操作可以是修改规则整合组件中治理规则3对应的程序。

在一种实施方式中，所述更改操作包括创建操作时，所述对所述微服务对应的至少一个微服务治理规则进行更改，包括：创建微服务的标识信息、以及所述微服务对应的命名空间。

这里，微服务对应的命名空间用于表明将微服务对应的治理规则存储在哪个命名空间下。当更改操作包括创建操作时，对所述微服务对应的至少一个微服务治理规则进行更改的实现方式，可以是创建微服务治理规则，由于可以通过上述所述的规则整合组件来对微服务的所有治理规则进行统一管理，因此，无需对创建的每条服务治理规则都创建治理规则标识以及治理规则对应的命名空间，而只需要在创建规则整合组件中创建微服务的标识信息和微服务对应的命名空间即可。

在一种实施方式中，所述微服务治理规则包括以下至少一项：负载均衡、流量分发、超时重试、错误注入、熔断机制。

在一个示例中，可以将规则整合组件中微服务治理规则进行分类，具体地，微服务治理规则可以被分为以下类型：负载均衡、流量分发、超时重试、错误注入、熔断机制等。

负载均衡可以用于对每个微服务的某个版本，设置不同的负载均衡策略，支持轮询、最小连接数、随机等策略。

流量分发可以用于根据不同的分发类型(路径、请求方法、请求头)，以不同的匹配规则，将相应权重的请求分发到微服务的某个版本进行处理。

超时重试可以用于对每个微服务的某个版本，设置相应的超时时间与重试次数。

错误注入可以用于指定特定版本的微服务进行错误注入；支持延迟和错误两种类型，其中，可以设置延迟时间和触发概率，可以设置错误码和触发概率。

熔断机制可以用于指定服务版本设置熔断机制，通过设置服务的最大连接数、最大挂起请求数、最大请求数、最大活动重试次数，在网络级别实现强制断路限制。当服务的健康状况低于设定的这些阈值时，将启动熔断机制，禁止请求通过。

图4为本发明的规则整合组件中微服务治理规则的更改操作示意图：其中，loadBalancers可以用于负责服务的负载均衡策略的设置，可以设置服务为轮询的负载策略；routes可以用于负责服务的流量分发的设置，可根据请求路径、请求头等进行流量的分发；retries可以用于负责服务的超时重试机制的设置，当服务请求出现超时，可通过该机制进行重试；fault Injection可以用于负责服务的错误注入的设置，可设置服务的请求按百分比直接返回错误状态码。

通过上述微服务治理规则的分类，可以实现对多种微服务治理规则的归类管理，极大简化了管理的复杂性。

在一种实施方式中，所述微服务治理请求还携带有业务集群的标识信息；所述获取微服务治理请求，可以包括：在所述微服务治理请求还携带的业务集群的标识信息与预设的业务集群的标识信息匹配时，接收所述微服务治理请求。

业务集群的标识信息可以用于确定微服务治理请求是对哪个业务集群进行治理的标识信息，具体地，业务集群的标识信息可以是业务集群的名称或业务集群对应的数字代码，当存在业务集群A、业务集群B和业务集群C等时，业务集群的标识信息可以是业务集群的名称A、B或C等，当然，业务集群的标识信息也可以是数字代码1、2和3，用于分别代表业务集群A、业务集群B和业务集群C。

示例性地，如果微服务治理请求还携带的业务集群的标识信息与预设的业务集群的标识信息完全一致，可以认为微服务治理请求还携带的业务集群的标识信息和预设的业务集群的标识信息匹配；如果微服务治理请求还携带的业务集群的标识信息与预设的业务集群的标识信息不完全一致，可以认为微服务治理请求还携带的业务集群的标识信息和预设的业务集群的标识信息不匹配。这里，预设的业务集群的标识信息可以是在业务集群的转发组件中预先设置的业务集群的标识信息。

图5为本发明的微服务治理装置的组成结构示意图，如图5所示，该装置可以包括：获取模块501和管理模块502；其中，

获取模块501，用于获取微服务治理请求，所述微服务治理请求中携带有微服务的标识信息和所述微服务对应的至少一个微服务治理规则的标识信息；

管理模块502，用于根据所述微服务治理请求，对所述微服务对应的至少一个微服务治理规则进行统一管理。

可选地，所述管理模块502用于根据所述微服务治理请求，确定所述微服务对应的至少一个微服务治理规则发生更改时，根据针对所述微服务对应的至少一个微服务治理规则的更改操作，对所述微服务对应的至少一个微服务治理规则进行更改。

可选地，所述更改操作包括以下至少一种操作：创建操作、删除操作、修改操作。

可选地，所述管理模块502用于创建微服务的标识信息、以及所述微服务对应的命名空间。

可选地，所述微服务治理规则包括以下至少一项：负载均衡、流量分发、超时重试、错误注入、熔断机制。

可选地，所述获取模块501用于在所述微服务治理请求还携带的业务集群的标识信息与预设的业务集群的标识信息匹配时，接收所述微服务治理请求。

实际应用中，获取模块501和管理模块502均可以利用电子设备中的处理器实现，上述处理器可以为ASIC、DSP、DSPD、PLD、FPGA、CPU、控制器、微控制器、微处理器中的至少一种。

另外，在本实施例中的各功能模块可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能模块的形式实现。

所述集成的单元如果以软件功能模块的形式实现并非作为独立的产品进行销售或使用时，可以存储在一个计算机可读取存储介质中，基于这样的理解，本实施例的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)或processor(处理器)执行本实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(Read Only Memory，ROM)、随机存取存储器(Random Access Memory，RAM)、磁碟或者光盘等各种可以存储程序代码的介质。

具体来讲，本实施例中的一种微服务治理方法对应的计算机程序指令可以被存储在光盘，硬盘，U盘等存储介质上，当存储介质中的与一种微服务治理方法对应的计算机程序指令被一电子设备读取或被执行时，实现前述实施例的任意一种微服务方法。

基于前述实施例相同的技术构思，参见图6，其示出了本发明提供的一种电子设备，可以包括：存储器601和处理器602；其中，

所述存储器601，用于存储计算机程序和数据；

所述处理器602，用于执行所述存储器中存储的计算机程序，以实现前述实施例的任意一种微服务治理方法。

在实际应用中，上述存储器601可以是易失性存储器(volatile memory)，例如RAM；或者非易失性存储器(non-volatile memory)，例如ROM，快闪存储器(flash memory)，硬盘(Hard Disk Drive，HDD)或固态硬盘(Solid-State Drive，SSD)；或者上述种类的存储器的组合，并向处理器602提供指令和数据。

上述处理器602可以为ASIC、DSP、DSPD、PLD、FPGA、CPU、控制器、微控制器、微处理器中的至少一种。可以理解地，对于不同的增强现实云平台，用于实现上述处理器功能的电子器件还可以为其它，本发明实施例不作具体限定。

在一些实施例中，本发明提供的装置具有的功能或包含的模块可以用于执行上文方法实施例描述的方法，其具体实现可以参照上文方法实施例的描述，为了简洁，这里不再赘述

上文对各个实施例的描述倾向于强调各个实施例之间的不同之处，其相同或相似之处可以互相参考，为了简洁，本文不再赘述

本申请所提供的各方法实施例中所揭露的方法，在不冲突的情况下可以任意组合，得到新的方法实施例。

本申请所提供的各产品实施例中所揭露的特征，在不冲突的情况下可以任意组合，得到新的产品实施例。

本申请所提供的各方法或设备实施例中所揭露的特征，在不冲突的情况下可以任意组合，得到新的方法实施例或设备实施例。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到上述实施例方法可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质(如ROM/RAM、磁碟、光盘)中，包括若干指令用以使得一台终端(可以是手机，计算机，服务器，空调器，或者网络设备等)执行本发明各个实施例所述的方法。

上面结合附图对本发明的实施例进行了描述，但是本发明并不局限于上述的具体实施方式，上述的具体实施方式仅仅是示意性的，而不是限制性的，本领域的普通技术人员在本发明的启示下，在不脱离本发明宗旨和权利要求所保护的范围情况下，还可做出很多形式，这些均属于本发明的保护之内。

Claims (10)

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

获取微服务治理请求，所述微服务治理请求中携带有微服务的标识信息和所述微服务对应的至少一个微服务治理规则的标识信息；

根据所述微服务治理请求，对所述微服务对应的至少一个微服务治理规则进行统一管理。

2.根据权利要求1所述的方法，其特征在于，所述对所述微服务对应的至少一个微服务治理规则进行统一管理，包括：

根据所述微服务治理请求，确定所述微服务对应的至少一个微服务治理规则发生更改时，根据针对所述微服务对应的至少一个微服务治理规则的更改操作，对所述微服务对应的至少一个微服务治理规则进行更改。

3.根据权利要求1或2所述的方法，其特征在于，所述更改操作包括以下至少一种操作：创建操作、删除操作、修改操作。

4.根据权利要求3所述的方法，其特征在于，所述更改操作包括创建操作时，所述对所述微服务对应的至少一个微服务治理规则进行更改，包括：

创建微服务的标识信息、以及所述微服务对应的命名空间。

5.根据权利要求1或2所述的方法，其特征在于，所述微服务治理规则包括以下至少一项：负载均衡、流量分发、超时重试、错误注入、熔断机制。

6.根据权利要求1所述的方法，其特征在于，所述微服务治理请求还携带有业务集群的标识信息；

所述获取微服务治理请求，包括：在所述微服务治理请求还携带的业务集群的标识信息与预设的业务集群的标识信息匹配时，接收所述微服务治理请求。

7.一种微服务治理装置，其特征在于，所述装置包括：获取模块和管理模块，其中，

获取模块，用于获取微服务治理请求，所述微服务治理请求中携带有微服务的标识信息和所述微服务对应的至少一个微服务治理规则的标识信息；

管理模块，用于根据所述微服务治理请求，对所述微服务对应的至少一个微服务治理规则进行统一管理。

8.根据权利要求7所述的装置，其特征在于，所述管理模块用于根据所述微服务治理请求，确定所述微服务对应的至少一个微服务治理规则发生更改时，根据针对所述微服务对应的至少一个微服务治理规则的更改操作，对所述微服务对应的至少一个微服务治理规则进行更改。

9.一种电子设备，其特征在于，包括处理器和用于存储能够在处理器上运行的计算机程序的存储器；其中，

所述处理器用于运行所述计算机程序时，执行权利要求1-6任一项所述的微服务治理方法。

10.一种计算机存储介质，其上存储有计算机程序，其特征在于，该计算机程序被处理器执行时实现权利要求1-6任一项所述的微服务治理方法。

Images