CN116737412A - 服务治理系统、方法及服务治理平台 - Google Patents

Abstract

本说明书提供服务治理系统、方法及服务治理平台，其中服务治理系统包括：服务治理平台、客户端、配置中心和容器服务；客户端，被配置为向服务治理平台发起目标服务的服务调用请求，其中，服务调用请求携带目标服务的服务标签；服务治理平台，被配置为接收服务调用请求，从容器服务获取服务映射表，并根据服务映射表确定服务标签对应的目标容器地址，其中，服务映射表基于服务对应的容器地址生成并更新；从配置中心获取目标容器地址对应的目标治理规则，根据目标治理规则治理服务调用请求并执行调用。如此，提高了服务治理平台的兼容性，且通过容器服务可以维护动态的服务映射表，很好地适配了容器化治理。

Description

服务治理系统、方法及服务治理平台

技术领域

本说明书涉及计算机技术领域，特别涉及一种服务治理系统。本说明书同时涉及一种服务治理方法，一种服务治理平台，一种计算设备，以及一种计算机可读存储介质。

背景技术

随着计算机技术、互联网技术和云服务技术的快速发展，线上服务的种类和数量与日俱增，相应地诞生了分布式系统，在分布式系统中服务治理是重要的任务。服务治理(SOAGovernance)是指基于SOA(Service-OrientedArchitecture，面向服务的架构)对服务进行决策与管理，包括治理服务调用之间的关系、服务发布和发现、服务监控、可靠性保证等一系列内容。

现有技术中，存在许多针对DUBBO、SpringBoot、Kafka等中间件的治理平台，但它们大多数是针对单一技术栈的，并在功能上可能存在一定的限制，这使得它们在生产环境中的应用受到限制，兼容性较差，且现有的治理平台也没有很好地适配容器化治理。

发明内容

有鉴于此，本说明书实施例提供了一种服务治理系统。本说明书同时涉及一种服务治理方法，一种服务治理平台，一种计算设备，以及一种计算机可读存储介质，以解决现有技术中存在的技术缺陷。

根据本说明书实施例的第一方面，提供了一种服务治理系统，服务治理系统包括服务治理平台、客户端、配置中心和容器服务；

客户端，被配置为向服务治理平台发起目标服务的服务调用请求，其中，服务调用请求携带目标服务的服务标签；

服务治理平台，被配置为接收服务调用请求，从容器服务获取服务映射表，并根据服务映射表确定服务标签对应的目标容器地址，其中，服务映射表基于服务对应的容器地址生成并更新；从配置中心获取目标容器地址对应的目标治理规则，根据目标治理规则治理服务调用请求并执行调用。

根据本说明书实施例的第二方面，提供了一种服务治理方法，应用于服务治理系统中的服务治理平台，服务治理系统还包括配置中心和容器服务；方法包括：

接收针对目标服务发起的服务调用请求，其中，服务调用请求携带目标服务的服务标签；

从容器服务获取服务映射表，并根据服务映射表确定服务标签对应的目标容器地址，其中，服务映射表基于服务对应的容器地址生成并更新；

从配置中心获取目标容器地址对应的目标治理规则，根据目标治理规则治理服务调用请求并执行调用。

根据本说明书实施例的第三方面，提供了一种服务治理系统中的服务治理平台，服务治理系统还包括配置中心和容器服务；服务治理平台包括：

接收模块，被配置为接收针对目标服务发起的服务调用请求，其中，服务调用请求携带目标服务的服务标签；

确定模块，被配置为从容器服务获取服务映射表，并根据服务映射表确定服务标签对应的目标容器地址，其中，服务映射表基于服务对应的容器地址生成并更新；

治理模块，被配置为从配置中心获取目标容器地址对应的目标治理规则，根据目标治理规则治理服务调用请求并执行调用。

根据本说明书实施例的第四方面，提供了一种计算设备，包括：

存储器和处理器；

存储器用于存储计算机可执行指令，处理器用于执行计算机可执行指令，以实现上述的服务治理方法的步骤。

根据本说明书实施例的第五方面，提供了一种计算机可读存储介质，其存储有计算机可执行指令，该指令被处理器执行时实现上述的服务治理方法的步骤。

本说明书实施例提供的服务治理系统，包括服务治理平台、客户端、配置中心和容器服务；客户端，被配置为向服务治理平台发起目标服务的服务调用请求，其中，服务调用请求携带目标服务的服务标签；服务治理平台，被配置为接收服务调用请求，从容器服务获取服务映射表，并根据服务映射表确定服务标签对应的目标容器地址，其中，服务映射表基于服务对应的容器地址生成并更新；从配置中心获取目标容器地址对应的目标治理规则，根据目标治理规则治理服务调用请求并执行调用。

本说明书一实施例实现了服务治理平台可以接收任意类型的服务调用请求，从容器服务中获取服务映射表，并根据服务映射表确定目标服务对应的目标容器地址，然后从配置中心获取目标容器地址对应的目标治理规则，根据目标治理规则治理服务调用请求并执行调用。如此，各个技术栈的治理规则均可以预先在配置中心中进行配置，提高了服务治理平台的兼容性，支持多种类型的服务调用请求的服务治理；并且，通过容器服务可以维护动态的服务映射表，从而可以适应服务对应的容器动态变化的场景，准确获取到目标服务当前最新的容器地址，从而针对该容器地址进行服务治理，保证了服务治理的准确性，很好地适配了容器化治理。

附图说明

图1是根据本说明书一实施例提供的一种服务治理系统的结构框图；

图2是根据本说明书一实施例提供的一种服务治理方法的流程图；

图3是根据本说明书一实施例提供的一种服务治理方法的处理过程的交互示意图；

图4是本说明书一个实施例提供的一种服务调用界面的界面示意图；

图5是本说明书一实施例提供的一种服务治理系统中的服务治理平台的结构示意图；

图6是本说明书一实施例提供的一种计算设备的结构框图。

具体实施方式

在下面的描述中阐述了很多具体细节以便于充分理解本说明书。但是本说明书能够以很多不同于在此描述的其它方式来实施，本领域技术人员可以在不违背本说明书内涵的情况下做类似推广，因此本说明书不受下面公开的具体实施的限制。

在本说明书一个或多个实施例中使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本说明书一个或多个实施例。在本说明书一个或多个实施例和所附权利要求书中所使用的单数形式的“一种”和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义。还应当理解，本说明书一个或多个实施例中使用的术语“和/或”是指并包含一个或多个相关联的列出项目的任何或所有可能组合。

应当理解，尽管在本说明书一个或多个实施例中可能采用术语第一、第二等来描述各种信息，但这些信息不应限于这些术语。这些术语仅用来将同一类型的信息彼此区分开。例如，在不脱离本说明书一个或多个实施例范围的情况下，第一也可以被称为第二，类似地，第二也可以被称为第一。取决于语境，如在此所使用的词语“如果”可以被解释成为“在……时”或“当……时”或“响应于确定”。

首先，对本说明书一个或多个实施例涉及的名词术语进行解释。

DUBBO：是一个高性能的服务框架，使得应用可通过高性能的RPC实现服务的输出和输入功能，可以和Spring框架无缝集成。

RPC：一个远程过程调用的抽象，支持负载均衡、容灾和集群功能。

Spring框架：是Java平台上的一种应用框架，提供具有控制反转特性的容器。Spring框架为开发提供了一系列的解决方案，比如利用控制反转的核心特性，并通过依赖注入实现控制反转来实现管理对象生命周期容器化，利用面向切面编程进行声明式的事务管理，整合多种持久化技术管理数据访问，提供大量优秀的Web框架方便开发等等。

SpringBoot：是一种全新框架，其设计目的是用来简化新Spring应用的初始搭建以及开发过程。该框架使用了特定的方式来进行配置，从而使开发人员不再需要定义样板化的配置。

Kafka：是一个流处理平台，是一种高吞吐量的分布式发布订阅消息系统，它可以处理消费者在网站中的所有动作流数据。

APIMASTER：Kubernetes的API的暴露服务，可获取Pod等相关节点信息。其中，Pod是Kubernetes创建和管理的最小单元，一个Pod由一个容器或多个容器组成，这些容器共享存储、网络。一个Pod可以理解为是一个应用实例，提供服务，Pod中容器始终部署在一个节点上，Pod中容器共享网络、存储资源，Kubernetes直接管理Pod，而不是容器。

HTTP：HyperTextTransferProtocol，超文本传输协议，是一种用于分布式、协作式和超媒体信息系统的应用层协议，是万维网的数据通信的基础，也是互联网应用最为广泛的一种网络传输协议。本说明书实施例中是指客户端到服务器端的请求消息。

实际应用中，服务治理是分布式系统中的一项关键任务，用于实现对微服务的管理、监控和协调。服务治理平台通常会涉及以下几个技术：

服务注册与发现：允许服务实例在启动时自动注册到注册中心，同时允许其他服务实例发现并调用这些已注册的服务。常见的服务注册与发现技术有Eureka、Zookeeper、Consul和etcd等。

负载均衡：在多个服务实例之间分发请求，以均衡系统负载并提高服务可用性。负载均衡可以在客户端(如Ribbon)或服务端(如Nginx、HAProxy)实现。

熔断与降级：在分布式系统中，熔断和降级用于处理故障和异常情况，以防止故障级联。Hystrix和Sentinel是两个常见的熔断与降级框架。

限流与流量控制：限制系统中的请求数量或流量，以保护系统免受过载。常见的限流框架有Sentinel、Nginx限流模块等。

服务链路追踪：跟踪和监控服务之间的调用关系和性能指标。常见的服务链路追踪技术有Zipkin、Jaeger和SkyWalking等。

API网关：作为系统入口，处理外部请求并将其转发到相应的服务。API网关可以实现鉴权、路由、限流等功能。常见的API网关有Zuul、Kong、Spring CloudGateway和Nginx等。

配置中心：用于集中管理和分发系统中的配置信息。常见的配置中心技术有SpringCloudConfig、Apollo、Nacos等。

容器与编排：容器技术(如Docker)和编排工具(如Kubernetes)用于实现服务的自动部署、扩展和管理。

需要说明的是，当前市场上存在许多针对DUBBO、SpringBoot、Kafka等中间件的治理平台，但它们大多数是针对单一技术栈的，并在功能上可能存在一定的限制，这使得它们在生产环境中的应用受到限制。这些平台主要通过修改注册信息以及在配置中心修改治理规则来实现治理目的。同时，由于采用了自研的网关，很难找到相应的治理技术来满足需求。此外，现有的中间件也没有很好地适配容器化治理。

实际应用中，服务治理技术方案主要包括以下几种：

1、Dubbo+Zookeeper：Dubbo是一个分布式服务框架，通常与Zookeeper配合使用以实现服务注册与发现。

2、SpringCloud：SpringCloud是一个基于SpringBoot的微服务治理框架，提供了丰富的微服务治理组件，如Eureka、Ribbon、Hystrix、Zuul、SpringCloud Config等。

3、Istio+Kubernetes：Istio是一个服务网格平台，提供了丰富的服务治理能力，如负载均衡、熔断、链路监控等。

然而，上述服务治理的技术方案中，许多服务治理平台专注于特定的技术栈，如DUBBOSpringBoot等等，这可能导致在采用多种技术栈的场景中，需要使用不同的服务治理平台，存在技术栈局限性，兼容性较差。其次，一些服务治理平台的功能可能不够完善，无法满足复杂的生产环境需求，例如，某些平台可能缺乏高级的流量管理、故障注入和安全控制功能。其次，部分服务治理技术集成和扩展性有限，可能难以与其他中间件、框架或第三方服务无缝集成，集成和扩展性存在限制，这可能导致在某些情况下需要进行大量的定制开发。其次，虽然容器化已经成为一种主流的部署方式，但一些服务治理技术在容器化支持方面仍然不足，例如在资源管理、自动扩展和故障恢复等方面存在挑战。其次，部分服务治理技术的文档可能不够完善，或者社区支持有限，这可能导致开发者在遇到问题时难以找到有效的解决方案。其次，在某些情况下，服务治理技术可能存在性能瓶颈或稳定性问题，特别是在高并发和大规模分布式环境下。另外，服务治理涉及到许多概念和技术，对于开发者来说可能存在较高的学习曲线；同时，由于平台之间的差异，从一个平台切换到另一个平台可能需要投入额外的学习成本。再者，一些商业化的服务治理解决方案可能涉及较高的许可和维护成本，给企业带来较大的负担。

因而，为了解决上述技术问题，本说明书实施例提供了一种服务治理系统，包括服务治理平台、客户端、配置中心和容器服务。提供了一个统一的服务治理平台，支持Dubbo、SpringBoot、Kafka等多种中间件技术栈，实现跨技术栈的服务治理，兼容多种中间件技术栈。其次，优化了服务治理平台以适应容器化部署环境，实现在容器化场景下的高效资源管理、自动扩展和故障恢复等功能，与容器化治理适配。其次，确保服务治理平台具有高性能和稳定性，以应对大规模流量场景和保持高可用性。其次，通过采用开源技术和自动化运维手段，降低服务治理平台的维护成本，提高可持续性。另外，还设计了直观易用的用户界面，降低学习曲线；同时，提供统一的管控平台，支持多种终端设备，便于用户随时随地进行服务治理。再者，确保了服务治理平台能够支持自研的多个中间件，提供便捷的扩展能力，以满足不断变化的业务需求和技术挑战。

需要说明的是，本说明书实施例提供的一种服务治理系统，其中包括的服务治理平台可以兼容大部分中间件的治理功能，并且支持内部定制中间件的治理。针对Dubbo治理部分，虽然Dubbo项目中的DubboAdmin可以作为一种替代方案，但由于其存在众多为问题，难以在生产环境中稳定运行。因此，本说明书实施例的服务治理平台提供了一个更加稳定、全面和高效的服务治理解决方案，以满足不同场景和业务需求。

在本说明书中，提供了一种服务治理系统，本说明书同时涉及一种服务治理方法，一种服务治理系统中的服务治理平台，一种计算设备，以及一种计算机可读存储介质，在下面的实施例中逐一进行详细说明。

参见图1，图1示出了根据本说明书一实施例提供的一种服务治理系统的结构框图，如图1所示，服务治理系统包括服务治理平台102、客户端104、配置中心106和容器服务108；

客户端104，被配置为向服务治理平台102发起目标服务的服务调用请求，其中，服务调用请求携带目标服务的服务标签；

服务治理平台102，被配置为接收服务调用请求，从容器服务108中获取服务映射表，并根据服务映射表确定服务标签对应的目标容器地址，其中，服务映射表基于服务对应的容器地址生成并更新；从配置中心106获取目标容器地址对应的目标治理规则，根据目标治理规则治理服务调用请求并执行调用。

其中，服务标签为唯一标识一个应用服务的标识，如服务IP、服务名称等，该服务标签用于查找对应的容器地址。目标服务为任一应用服务。

具体的，服务治理系统包括服务治理平台、客户端、配置中心和容器服务。其中，服务治理平台为对目标服务的服务调用请求进行治理的平台；客户端为发起服务调用请求的终端，如客户端可以包括前端页面、办公协作应用程序等；配置中心为预先写入不同类型的服务调用请求的治理规则的模块，通过配置中心可以实现对不同技术栈，也即不同类型的服务调用的兼容性，该服务治理规则可以包括限流、降级、黑白名单、熔断、IP封禁、权重调整、消息治理、服务启禁用、接口缓存、场景组合等；容器服务用于基于服务对应的容器地址生成并更新，以适应服务对应的容器动态变化的场景，也即容器服务可以获取服务对应的容器列表信息，即服务映射表，从而保证在容器里可以正确执行相应的命令，作为一种示例该容器服务可以为kuberneteAPImaster服务。

需要说明的是，应用服务的启动和关闭，应用服务对应容器的增减等变更均会影响应用服务对应的容器地址，也即是应用服务对应的容器地址可能是动态变化的，如果直接将应用服务对应的容器地址写入容器服务，在应用服务对应的容器发生变化时，可能会导致查找到的容器地址有错误，进而可能会导致服务治理失败。

因而，实际应用中，容器服务可以基于服务对应的容器地址生成并更新一个服务映射表，将该服务映射表写入容器服务，也即该服务映射表可以维护应用服务动态变化的容器地址信息。

用户可以在客户端发起针对目标服务的服务调用请求，该服务调用请求携带有目标服务的服务标签。客户端可以向服务治理平台发送该服务调用请求，服务治理平台接收到该服务调用请求时，可以从容器服务中获取服务映射表，并根据服务映射表确定目标服务的服务标签对应的目标容器地址，该目标容器地址为目标服务当前最新的容器地址。然后，可以从配置中心获取目标容器地址对应的目标治理规则，根据目标治理规则对该服务调用请求进行治理并执行调用。

具体实现时，配置中心可以存储有多种服务治理规则，该服务治理规则基于实际的业务需求配置。基于配置中心配置的各个服务治理规则，确定出目标容器地址对应的目标治理规则后，可以基于目标治理规则对该服务调用请求进行治理，并执行该服务调用请求，执行完毕后，可以向客户端反馈请求的执行结果，该请求执行结果中可以包括对其进行了哪种治理，也即是携带基于目标治理规则对该服务调用请求进行治理的治理信息。

作为一种示例，假设配置中心配置的服务治理规则包括限流、降级、黑白名单、熔断、IP封禁、权重调整、消息治理、服务启禁用、接口缓存、场景组合等。假设确定出的目标容器地址对应的目标治理规则为限流，限制该目标容器地址对应的应用服务只能访问1000大小的数据，那么无论服务调用请求所请求访问的数据大小为多少，一次访问最大只能访问1000大小的数据，并将访问到的数据反馈给客户端，并向客户端展示限流的详细信息，如“本次只能访问1000大小的数据，若需其他数据，请再次访问”。又假设确定出的目标容器地址对应的目标治理规则为黑白名单，且该目标容器地址为禁止访问的黑名单，此时可以禁止执行该服务调用请求，并向客户端反馈服务治理的结果，如“该目标服务当前禁止访问，请稍后再试”。

本说明书实施例提供的服务治理系统中的服务治理平台可以接收任意类型的服务调用请求，从容器服务中获取服务映射表，并根据服务映射表确定目标服务对应的目标容器地址，然后从配置中心获取目标容器地址对应的目标治理规则，根据目标治理规则治理服务调用请求并执行调用。如此，各个技术栈的治理规则均可以预先在配置中心中进行配置，提高了服务治理平台的兼容性，支持多种类型的服务调用请求的服务治理；并且，通过容器服务可以维护动态的服务映射表，从而可以适应服务对应的容器动态变化的场景，准确获取到目标服务当前最新的容器地址，从而针对该容器地址进行服务治理，保证了服务治理的准确性，很好地适配了容器化治理。

另外，服务治理系统中的服务治理平台通过采用开源技术和自动化运维手段，可以降低服务治理平台的维护成本，提高可持续性。

再者，服务治理系统中的服务治理平台能够支持自研的多个中间件，仅需将中间件对应的服务治理规则在配置中心进行配置即可，提供了便捷的扩展能力，以满足不断变化的业务需求和技术挑战。

本实施例一个可选的实施方式中，如图1所示，服务治理系统还包括注册中心110；

客户端104，进一步被配置为在目标服务启动时，向注册中心110注册目标服务；

服务治理平台102，进一步被配置为获取目标服务在注册中心110中的注册信息，根据注册信息执行目标治理规则。

需要说明的是，各个应用服务在启动时，会自动向注册中心注册，该注册中心可以维护各个服务的注册信息，也即允许服务实例在启动时自动注册到注册中心，同时允许其他服务实例发现并调用这些已注册的服务。常见的服务注册与发现技术有Eureka、Zookeeper、Consul和etcd等。

实际应用中，客户端在目标服务启动时可以向注册中心注册，服务治理平台可以先从注册中心获取目标服务在注册中心注册的元数据信息，该元数据信息可以指示目标服务已经在注册中心注册，允许其他服务发现并调用这些已注册的服务，用于作为服务治理规则执行的入口，也即服务治理平台可以基于该元数据信息执行该目标治理规则。具体的，先基于目标治理规则对服务调用请求进行治理，治理后基于元数据信息执行该服务调用请求。

本说明书实施例中，各个应用服务在启动时，会自动向注册中心注册，使得服务治理平台接收到针对目标服务的服务调用请求后，可以在注册中心中获取目标服务对应的元数据信息，以查询目标服务是否注册，若已经注册，再进行后续的服务调用请求治理，通过注册中心提供服务治理规则的入口，实现对目标服务的服务调用请求的服务治理。

本实施例一个可选的实施方式中，容器服务108，被配置为：

在目标服务对应的容器地址发生变化的情况下，根据目标服务的更新容器地址更新服务映射表。

需要说明的是，应用服务对应的容器不是一成不变的，应用服务的启动和关闭，应用服务对应容器的增减等变更均会影响应用服务对应的容器地址，也即是应用服务对应的容器地址可能是动态变化的，如果直接将应用服务对应的容器地址写入容器服务，在应用服务对应的容器发生变化时，可能会导致查找到的容器地址有错误，进而可能会导致服务治理失败。

因而，实际应用中，容器服务可以监控目标服务对应的容器地址是否发生变化，若发生变化，则可以根据目标服务的更新容器地址更新服务映射表，使得该服务映射表可以存储目标服务当前最新的容器地址，通过该服务映射表维护目标服务动态变化的容器地址。

一种可能的实现方式中，每个应用服务可以对应一个容器地址列表，每更新一次容器地址，将新的容器地址写入列表的末尾，获取目标服务的目标容器地址时，可以获取目标服务的服务标签对应的容器列表，将该容器列表中最后一个容器地址作为该目标服务对应的目标容器地址。另一种可能的实现方式中，每个应用服务仅存储当前最新的容器地址，也即是每更新一次容器地址，将新的容器地址替换旧的容器地址，此时各个应用服务对应一个容器列表，该容器列表中存储有各个应用服务当前最新的容器地址，此时可以直接根据目标服务的服务标签在该容器列表中查找到对应的目标容器地址。

本说明书实施例中，容器服务可以监控目标服务对应的容器地址是否发生变化，在发生变化的情况下，根据目标服务的更新容器地址更新服务映射表，通过该服务映射表维护目标服务动态变化的容器地址，从而保证在容器里可以正确执行相应的命令，针对正确的容器地址进行服务治理，保证了服务治理的准确性，很好地适配了容器化治理。优化了服务治理平台，以适应容器化部署环境，实现在容器化场景下的高效资源管理、自动扩展和故障恢复等功能。

本实施例一个可选的实施方式中，配置中心106，被配置为：

接收配置方发起的配置请求，其中，配置请求携带至少一种服务治理规则；

存储至少一种服务治理规则。

其中，服务治理规则是指对服务调用请求进行治理的规则，可以预先配置，如该服务治理规则可以包括限流、降级、黑白名单、熔断、IP封禁、权重调整、消息治理、服务启禁用、接口缓存、场景组合等。

需要说明的是，配置方可以基于自身实际的业务需求，发起配置请求，将配置请求中携带的至少一种服务治理规则写入配置中心，服务治理平台可以基于配置中心写入的配置规则，对目标服务的服务调用请求进行治理。如此，提供了一个统一的服务治理平台，各个技术栈的治理规则均可以预先在配置中心中进行配置，支持多种中间件技术栈，实现跨技术栈的服务治理，提高了服务治理平台的兼容性，支持多种类型的服务调用请求的服务治理。

本实施例一个可选的实施方式中，服务治理平台102中包括管理组件和至少两种类型的执行组件；

管理组件，被配置为接收并解析服务调用请求，确定服务调用请求的请求类型；根据请求类型，将服务调用请求转发至对应类型的执行组件；

执行组件，被配置为从配置中心获取目标容器地址对应的目标治理规则，根据目标治理规则治理服务调用请求并执行调用。

需要说明的是，服务治理平台中包括管理组件和至少两种类型的执行组件，不同类型的执行组件用于执行不同类型的服务调用请求。

实际应用中，管理组件可以接收并解析目标服务的服务调用请求，确定该服务调用请求的请求类型，然后根据该请求类型，将服务调用请求转发至对应类型的执行组件，对应类型的执行组件从配置中心获取目标容器地址对应的目标治理规则，根据目标治理规则治理服务调用请求并执行调用。

本说明书实施例中，服务治理平台中分散布置有多种类型的执行组件，通过相应类型的执行组件实现基于配置中心的服务治理规则的服务治理，不同类型的服务调用请求，可以分配给对应的执行组件，确保服务治理平台具有高性能和稳定性，以应对大规模流量场景和保持高可用性。

本实施例一个可选的实施方式中，管理组件，进一步被配置为：

在服务调用请求的请求类型为第一请求类型的情况下，将服务调用请求转发至第一执行组件；

在服务调用请求的请求类型为第二请求类型的情况下，将服务调用请求转发至第二执行组件；

其中，第一执行组件和第二执行组件为不同类型的执行组件。

需要说明的是，服务调用请求可以分为多种请求类型，不同请求类型需要通过不同的执行组件执行，服务调用请求可以分为第一请求类型和第二请求类型，第一请求类型可以为HTTP请求类型，第二请求类型可以为RPC请求类型。

实际应用中，管理组件中预先配置有不同类型对应的执行组件，如HTTP请求类型对应的执行组件为网关；RPC请求类型对应的执行组件为服务框架的扩展组件，如Dubbo的扩展组件。

本说明书实施例中，管理组件可以将第一请求类型的服务调用请求分配至第一执行组件，将第二请求类型的服务调用请求分配至第二执行组件，不同类型的服务调用请求，通过不同的执行组件进行服务治理，从而可以基于服务调用请求的类型特征，以对应的方式进行服务治理，提高了灵活性和兼容，且确保服务治理平台具有高性能和稳定性，以应对大规模流量场景和保持高可用性。

本实施例一个可选的实施方式中，第一执行组件，被配置为：

从配置中心获取预先配置的至少一种服务治理规则，从各个服务治理规则中确定目标容器地址对应的目标治理规则；

根据目标治理规则治理服务调用请求并执行调用。

需要说明的是，第一执行组件可以为HTTP请求类型对应的执行组件，如自研网关，针对HTTP请求类型，需要从配置中心中获取预先配置的至少一种服务治理规则，然后再从各个服务治理规则中确定目标容器地址对应的目标治理规则。也即是说，针对HTTP请求类型需要主动从配置中心拉取服务治理规则，再基于标容器地址对应的目标治理规则对该服务调用请求进行治理并执行调用。如此，基于HTTP请求类型的类型特征，以主动拉取配置中心中配置的服务治理规则的方式进行服务治理，确保服务治理平台具有高性能和稳定性，以应对大规模流量场景和保持高可用性。

本实施例一个可选的实施方式中，第二执行组件，被配置为：

确定配置中心中配置的服务治理规则是否发生变化；

在服务治理规则发生变化的情况下，确定发生变化的更新治理规则是否为目标容器地址对应的治理规则；

若是，则将更新治理规则作为目标容器地址对应的目标治理规则，根据目标治理规则治理服务调用请求并执行调用；

若否，则直接执行服务调用请求。

实际应用中，第二执行组件可以为RPC请求类型对应的执行组件，如Dubbo的扩展组件。针对RPC请求类型，需要监控配置中心中配置的服务治理规则是否发生变化，在服务治理规则发生变化的情况下，进一步确定发生变化的更新治理规则是否为目标容器地址对应的治理规则，也即发生变化的更新治理规则是否影响目标服务的服务调用请求的治理，如果影响，则将更新治理规则作为目标容器地址对应的目标治理规则，根据目标治理规则治理并执行调用；如果不影响，则说明目标服务的服务调用请求无需治理，直接执行调用即可。

需要说明的是，基于RPC请求类型的类型特征，监控配置中心中配置的服务治理规则的变化，从而对服务调用请求进行服务治理，确保服务治理平台具有高性能和稳定性，以应对大规模流量场景和保持高可用性。

另外，服务治理平台还可以提供直观易用的用户界面，降低学习曲线；同时，提供统一的管控平台，支持多种终端设备，便于用户随时随地进行服务治理。

本说明书实施例提供的服务治理系统，实现了其中的服务治理平台可以接收任意类型的服务调用请求，从容器服务中获取服务映射表，并根据服务映射表确定目标服务对应的目标容器地址，然后从配置中心获取目标容器地址对应的目标治理规则，根据目标治理规则治理服务调用请求并执行调用。如此，各个技术栈的治理规则均可以预先在配置中心中进行配置，提高了服务治理平台的兼容性，支持多种类型的服务调用请求的服务治理；并且，通过容器服务可以维护动态的服务映射表，从而可以适应服务对应的容器动态变化的场景，准确获取到目标服务当前最新的容器地址，从而针对该容器地址进行服务治理，保证了服务治理的准确性，很好地适配了容器化治理。

图2示出了根据本说明书一实施例提供的一种服务治理方法的流程图，应用于服务治理系统中的服务治理平台，服务治理系统还包括配置中心和容器服务。如图2所示，该方法具体包括以下步骤202-206：

步骤202：接收针对目标服务发起的服务调用请求，其中，服务调用请求携带目标服务的服务标签。

步骤204：从容器服务获取服务映射表，并根据服务映射表确定服务标签对应的目标容器地址，其中，服务映射表基于服务对应的容器地址生成并更新。

步骤206：从配置中心获取目标容器地址对应的目标治理规则，根据目标治理规则治理服务调用请求并执行调用。

本说明书实施例提供的服务治理方法，实现了服务治理平台可以接收任意类型的服务调用请求，从容器服务中获取服务映射表，并根据服务映射表确定目标服务对应的目标容器地址，然后从配置中心获取目标容器地址对应的目标治理规则，根据目标治理规则治理服务调用请求并执行调用。如此，各个技术栈的治理规则均可以预先在配置中心中进行配置，提高了服务治理平台的兼容性，支持多种类型的服务调用请求的服务治理；并且，通过容器服务可以维护动态的服务映射表，从而可以适应服务对应的容器动态变化的场景，准确获取到目标服务当前最新的容器地址，从而针对该容器地址进行服务治理，保证了服务治理的准确性，很好地适配了容器化治理。

图3示出了根据本说明书一实施例提供的一种服务治理方法的处理过程的交互示意图，如图3所示，该方法具体包括以下步骤：

应用服务启动时，向注册中心注册。

配置方配置限流、降级、黑白名单、熔断、IP封禁、权重调整、消息治理、服务启禁用、接口缓存、场景组合等服务治理规则，写入配置中心。

容器服务在应用服务初始化时、服务治理规则变更时、应用服务的容器变更等时机，获取应用服务对应得到容器列表，该容器列表即为容器服务基于容器地址的变化维护更新的服务映射表。

客户端，如前端页面和办公协作应用程序，向服务治理平台发起目标服务的服务调用请求，服务治理平台从注册中心获取目标服务的元数据信息，作为服务治理的入口。服务治理平台从容器服务获取服务映射表，并根据服务映射表确定目标服务对应的目标容器地址；然后，从配置中心获取目标容器地址对应的目标治理规则，通过获取到的目标容器地址进行规则的转换，之后根据目标治理规则治理服务调用请求并执行调用，将该服务调用请求的调用结果和治理信息反馈给客户端。

本说明书实施例提供的服务治理方法，实现了服务治理平台可以接收任意类型的服务调用请求，从容器服务中获取服务映射表，并根据服务映射表确定目标服务对应的目标容器地址，然后从配置中心获取目标容器地址对应的目标治理规则，根据目标治理规则治理服务调用请求并执行调用。如此，各个技术栈的治理规则均可以预先在配置中心中进行配置，提高了服务治理平台的兼容性，支持多种类型的服务调用请求的服务治理；并且，通过容器服务可以维护动态的服务映射表，从而可以适应服务对应的容器动态变化的场景，准确获取到目标服务当前最新的容器地址，从而针对该容器地址进行服务治理，保证了服务治理的准确性，很好地适配了容器化治理。

图4示出了本说明书一个实施例提供的一种服务调用界面的界面示意图。如图4所示，服务调用界面分为应用服务的调用请求输入界面和应用服务的调用结果展示界面。应用服务的调用请求输入界面中包括调用请求输入框、“确定”控件以及“取消”控件。应用服务的调用结果展示界面中包括应用服务的调用结果展示框，该展示框中展示有应用服务的调用结果。

用户通过客户端显示的调用请求输入框输入应用服务的调用请求，点选“确定”控件，客户端向服务治理平台发起目标服务的服务调用请求，服务治理平台接收到该服务调用请求后，从容器服务获取服务映射表，并根据服务映射表确定服务标签对应的目标容器地址，其中，该服务映射表基于服务对应的容器地址生成并更新；然后，从配置中心获取目标容器地址对应的目标治理规则，根据目标治理规则治理服务调用请求并执行调用。

实际应用中，用户对控件进行操作的方式包括点击、双击、触控、鼠标悬停、滑动、长按、语音控制或摇一摇等任一方式，具体根据实际情况进行选择，本说明书实施例对此不作任何限定。

本说明书实施例提供的服务治理方案，实现了服务治理平台可以接收任意类型的服务调用请求，从容器服务中获取服务映射表，并根据服务映射表确定目标服务对应的目标容器地址，然后从配置中心获取目标容器地址对应的目标治理规则，根据目标治理规则治理服务调用请求并执行调用。如此，各个技术栈的治理规则均可以预先在配置中心中进行配置，提高了服务治理平台的兼容性，支持多种类型的服务调用请求的服务治理；并且，通过容器服务可以维护动态的服务映射表，从而可以适应服务对应的容器动态变化的场景，准确获取到目标服务当前最新的容器地址，从而针对该容器地址进行服务治理，保证了服务治理的准确性，很好地适配了容器化治理。

与上述方法实施例相对应，本说明书还提供了服务治理系统中的服务治理平台实施例，图5示出了本说明书一实施例提供的一种服务治理系统中的服务治理平台的结构示意图，服务治理系统还包括配置中心和容器服务。如图5所示，该服务治理系统中的服务治理平台包括：

接收模块502，被配置为接收针对目标服务发起的服务调用请求，其中，服务调用请求携带目标服务的服务标签；

确定模块504，被配置为从容器服务获取服务映射表，并根据服务映射表确定服务标签对应的目标容器地址，其中，服务映射表基于服务对应的容器地址生成并更新；

治理模块506，被配置为从配置中心获取目标容器地址对应的目标治理规则，根据目标治理规则治理服务调用请求并执行调用。

本说明书实施例提供的服务治理平台，实现了可以接收任意类型的服务调用请求，从容器服务中获取服务映射表，并根据服务映射表确定目标服务对应的目标容器地址，然后从配置中心获取目标容器地址对应的目标治理规则，根据目标治理规则治理服务调用请求并执行调用。如此，各个技术栈的治理规则均可以预先在配置中心中进行配置，提高了服务治理平台的兼容性，支持多种类型的服务调用请求的服务治理；并且，通过容器服务可以维护动态的服务映射表，从而可以适应服务对应的容器动态变化的场景，准确获取到目标服务当前最新的容器地址，从而针对该容器地址进行服务治理，保证了服务治理的准确性，很好地适配了容器化治理。

上述为本实施例的一种服务治理系统中的服务治理平台的示意性方案。需要说明的是，该服务治理系统中的服务治理平台的技术方案与上述的服务治理系统的技术方案属于同一构思，服务治理系统中的服务治理平台的技术方案未详细描述的细节内容，均可以参见上述服务治理系统的技术方案的描述。

图6示出了根据本说明书一实施例提供的一种计算设备的结构框图。该计算设备600的部件包括但不限于存储器610和处理器620。处理器620与存储器610通过总线630相连接，数据库650用于保存数据。

计算设备600还包括接入设备640，接入设备640使得计算设备600能够经由一个或多个网络660通信。这些网络的示例包括公用交换电话网(PSTN，PublicSwitchedTelephoneNetwork)、局域网(LAN，LocalAreaNetwork)、广域网(WAN，WideAreaNetwork)、个域网(PAN，PersonalAreaNetwork)或诸如因特网的通信网络的组合。接入设备640可以包括有线或无线的任何类型的网络接口(例如，网络接口卡(NIC，NetworkInterfaceController))中的一个或多个，诸如IEEE802.11无线局域网(WLAN，WirelessLocalAreaNetworks)无线接口、全球微波互联接入(Wi-MAX，WorldwideInteroperabilityforMicrowave Access)接口、以太网接口、通用串行总线(USB，UniversalSerialBus)接口、蜂窝网络接口、蓝牙接口、近场通信(NFC，NearFieldCommunication)接口，等等。

在本说明书的一个实施例中，计算设备600的上述部件以及图6中未示出的其他部件也可以彼此相连接，例如通过总线。应当理解，图6所示的计算设备结构框图仅仅是出于示例的目的，而不是对本说明书范围的限制。本领域技术人员可以根据需要，增添或替换其他部件。

计算设备600可以是任何类型的静止或移动计算设备，包括移动计算机或移动计算设备(例如，平板计算机、个人数字助理、膝上型计算机、笔记本计算机、上网本等)、移动电话(例如，智能手机)、可佩戴的计算设备(例如，智能手表、智能眼镜等)或其他类型的移动设备，或者诸如台式计算机或PC的静止计算设备。计算设备600还可以是移动式或静止式的服务器。

其中，处理器620用于执行如下计算机可执行指令，以实现上述的服务治理方法的步骤。

上述为本实施例的一种计算设备的示意性方案。需要说明的是，该计算设备的技术方案与上述的服务治理系统的技术方案属于同一构思，计算设备的技术方案未详细描述的细节内容，均可以参见上述服务治理系统的技术方案的描述。

本说明书一实施例还提供一种计算机可读存储介质，其存储有计算机指令，该指令被处理器执行时以用于实现上述的服务治理方法的步骤。

上述为本实施例的一种计算机可读存储介质的示意性方案。需要说明的是，该存储介质的技术方案与上述的服务治理系统的技术方案属于同一构思，存储介质的技术方案未详细描述的细节内容，均可以参见上述服务治理系统的技术方案的描述。

上述对本说明书特定实施例进行了描述。其它实施例在所附权利要求书的范围内。在一些情况下，在权利要求书中记载的动作或步骤可以按照不同于实施例中的顺序来执行并且仍然可以实现期望的结果。另外，在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序才能实现期望的结果。在某些实施方式中，多任务处理和并行处理也是可以的或者可能是有利的。

计算机指令包括计算机程序代码，计算机程序代码可以为源代码形式、对象代码形式、可执行文件或某些中间形式等。计算机可读介质可以包括：能够携带计算机程序代码的任何实体或装置、记录介质、U盘、移动硬盘、磁碟、光盘、计算机存储器、只读存储器(ROM，Read-OnlyMemory)、随机存取存储器(RAM，RandomAccessMemory)、电载波信号、电信信号以及软件分发介质等。

需要说明的是，对于前述的各方法实施例，为了简便描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本说明书并不受所描述的动作顺序的限制，因为依据本说明书，某些步骤可以采用其它顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于优选实施例，所涉及的动作和模块并不一定都是本说明书所必须的。

在上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述的部分，可以参见其它实施例的相关描述。

以上公开的本说明书优选实施例只是用于帮助阐述本说明书。可选实施例并没有详尽叙述所有的细节，也不限制该发明仅为的具体实施方式。显然，根据本说明书的内容，可作很多的修改和变化。本说明书选取并具体描述这些实施例，是为了更好地解释本说明书的原理和实际应用，从而使所属技术领域技术人员能很好地理解和利用本说明书。本说明书仅受权利要求书及其全部范围和等效物的限制。

Claims (12)

1.一种服务治理系统，其特征在于，所述服务治理系统包括服务治理平台、客户端、配置中心和容器服务；

所述客户端，被配置为向所述服务治理平台发起目标服务的服务调用请求，其中，所述服务调用请求携带所述目标服务的服务标签；

所述服务治理平台，被配置为接收所述服务调用请求，从所述容器服务获取服务映射表，并根据所述服务映射表确定所述服务标签对应的目标容器地址，其中，所述服务映射表基于服务对应的容器地址生成并更新；从所述配置中心获取所述目标容器地址对应的目标治理规则，根据所述目标治理规则治理所述服务调用请求并执行调用。

2.根据权利要求1所述的服务治理系统，其特征在于，所述服务治理系统还包括注册中心；

所述客户端，进一步被配置为在所述目标服务启动时，向所述注册中心注册所述目标服务；

所述服务治理平台，进一步被配置为获取所述目标服务在所述注册中心中的注册信息，根据所述注册信息执行所述目标治理规则。

3.根据权利要求1所述的服务治理系统，其特征在于，所述容器服务，被配置为：

在所述目标服务对应的容器地址发生变化的情况下，根据所述目标服务的更新容器地址更新所述服务映射表。

4.根据权利要求1所述的服务治理系统，其特征在于，所述配置中心，被配置为：

接收配置方发起的配置请求，其中，所述配置请求携带至少一种服务治理规则；

存储所述至少一种服务治理规则。

5.根据权利要求1-4任一项所述的服务治理系统，其特征在于，所述服务治理平台中包括管理组件和至少两种类型的执行组件；

所述管理组件，被配置为接收并解析所述服务调用请求，确定所述服务调用请求的请求类型；根据所述请求类型，将所述服务调用请求转发至对应类型的执行组件；

所述执行组件，被配置为从所述配置中心获取所述目标容器地址对应的目标治理规则，根据所述目标治理规则治理所述服务调用请求并执行调用。

6.根据权利要求5所述的服务治理系统，其特征在于，所述所述管理组件，进一步被配置为：

在所述服务调用请求的请求类型为第一请求类型的情况下，将所述服务调用请求转发至第一执行组件；

在所述服务调用请求的请求类型为第二请求类型的情况下，将所述服务调用请求转发至第二执行组件；

其中，所述第一执行组件和所述第二执行组件为不同类型的执行组件。

7.根据权利要求6所述的服务治理系统，其特征在于，所述第一执行组件，被配置为：

从所述配置中心获取预先配置的至少一种服务治理规则，从各个服务治理规则中确定所述目标容器地址对应的目标治理规则；

根据所述目标治理规则治理所述服务调用请求并执行调用。

8.根据权利要求6所述的服务治理系统，其特征在于，所述第二执行组件，被配置为：

确定所述配置中心中配置的服务治理规则是否发生变化；

在所述服务治理规则发生变化的情况下，确定发生变化的更新治理规则是否为所述目标容器地址对应的治理规则；

若是，则将所述更新治理规则作为所述目标容器地址对应的目标治理规则，根据所述目标治理规则治理所述服务调用请求并执行调用；

若否，则直接执行所述服务调用请求。

9.一种服务治理方法，其特征在于，应用于服务治理系统中的服务治理平台，所述服务治理系统还包括配置中心和容器服务；所述方法包括：

接收针对目标服务发起的服务调用请求，其中，所述服务调用请求携带所述目标服务的服务标签；

从所述容器服务获取服务映射表，并根据所述服务映射表确定所述服务标签对应的目标容器地址，其中，所述服务映射表基于服务对应的容器地址生成并更新；

从所述配置中心获取所述目标容器地址对应的目标治理规则，根据所述目标治理规则治理所述服务调用请求并执行调用。

10.一种服务治理系统中的服务治理平台，其特征在于，所述服务治理系统还包括配置中心和容器服务；所述服务治理平台包括：

接收模块，被配置为接收针对目标服务发起的服务调用请求，其中，所述服务调用请求携带所述目标服务的服务标签；

确定模块，被配置为从所述容器服务获取服务映射表，并根据所述服务映射表确定所述服务标签对应的目标容器地址，其中，所述服务映射表基于服务对应的容器地址生成并更新；

治理模块，被配置为从所述配置中心获取所述目标容器地址对应的目标治理规则，根据所述目标治理规则治理所述服务调用请求并执行调用。

11.一种计算设备，包括：

存储器和处理器；

所述存储器用于存储计算机可执行指令，所述处理器用于执行所述计算机可执行指令，以实现上述权利要求9所述的服务治理方法的步骤。

12.一种计算机可读存储介质，其存储有计算机指令，该指令被处理器执行时实现实现上述权利要求9所述的服务治理方法的步骤。