CN112612804A - 一种服务治理参数更新方法及装置 - Google Patents

Abstract

本申请涉及分布式系统技术领域，特别涉及一种服务治理参数更新方法及装置。应用于分布式系统，该分布式系统包括至少运行有各类业务服务，管理服务组件，配置中心组件，数据库和通讯总线的若干服务器，该方法包括：管理服务组件在监测到数据库存在服务治理参数的更新事件时，向配置中心组件发送第一消息，其中，第一消息携带有该更新事件；配置中心组件从数据库获取更新后的服务治理参数，并向通讯组件发送第二消息，其中，第二消息携带有该更新事件；各类业务服务在监听到通讯组件接收到第二消息时，判断自身是否与该更新事件相关联，若判定相关联，则从配置中心获取更新后的服务治理参数，并基于更新后的服务治理参数进行更新处理。

Description

一种服务治理参数更新方法及装置

技术领域

本申请涉及分布式系统技术领域，特别涉及一种服务治理参数更新方法及装置。

背景技术

在分布式系统的构建之中，服务治理是类似血液一样的存在，贯穿了服务的整个生命周期，包括针对业务系统的设计、开发、测试以及后续运维。随着业务系统的逐步迭代，构成整个系统的微服务会越来越复杂，慢慢演化成网状依赖结构，这就使得服务治理的重要性愈发凸显。具体来说，服务治理主要具备的能力包括处理服务调用之间的关系、服务发布和发现、故障监控与处理，服务的参数配置、服务降级和熔断、服务使用率监控等。一个好的服务治理平台可以大大降低开发的成本，提升运维的效率，对提升业务系统性能、稳定性和可用性发挥着重要的作用。

Spring Cloud是当前应用最广泛的微服务解决方案之一，关于服务治理，SpringCloud集成了Ribbon、Hystrix、Feign等框架实现处理微服务间调用的负载均衡、熔断降级、线程隔离、超时重试等治理能力。目前，在Spring Cloud框架下，服务治理需要用到的Ribbon、Hystrix、Feign等相关的配置参数需要配置在代码工程.properties文件中，这些配置仅在Spring Boot启动过程中进行加载及初始化实例，以此达到治理的目的。但如果在系统运行中想要重新配置服务治理策略，则需要在调整参数后重新启动应用，以使程序加载修改后的配置。

然而，若服务治理参数无法热更新，则会导致整个业务系统对实时问题的响应迟缓，无法根据系统实际使用情况对其进行灵活的运维，降低了系统的可用性和稳定性；若必须调整服务治理策略，则需要重启系统中的某个微服务或整个系统，会导致系统中的部分功能或全部功能中断，这在生产环境中是不能接受的。

发明内容

本申请提供了一种服务治理参数更新方法及装置，用以解决现有技术中存在的服务治理参数无法及时更新而导致业务系统可用性不高的问题。

第一方面，本申请提供了一种服务治理参数更新方法，应用于分布式系统，所述分布式系统包括至少运行有各类业务服务，管理服务组件，配置中心组件，数据库和通讯总线的若干服务器，所述方法包括：

所述管理服务组件在监测到所述数据库存在服务治理参数的更新事件时，向所述配置中心组件发送第一消息，其中，所述第一消息携带有所述更新事件；

所述配置中心组件从所述数据库获取更新后的服务治理参数，并向所述通讯组件发送第二消息，其中，所述第二消息携带有所述更新事件；

所述各类业务服务在监听到所述通讯组件接收到所述第二消息时，判断自身是否与所述更新事件相关联，若判定相关联，则从所述配置中心获取所述更新后的服务治理参数，并基于所述更新后的服务治理参数进行更新处理。

可选地，管理服务组件监测所述数据库存在服务治理参数的更新事件的步骤包括：

所述管理服务组件在确定接收到用户触发的服务治理参数更新操作，并将更新的服务治理参数存储至所述数据库时，确定监测到所述数据库存在服务治理参数的更新事件。

可选地，所述分布式系统为基于Spring Cloud框架的系统，所述配置中心组件为Spring Cloud Config，所述通讯组件为Spring Cloud Bus。

可选地，所述服务治理包括Hystrix提供的熔断能力和限流能力，Ribbon提供的超时重试能力。

可选地，所述分布式系统中预设有软件开发工具包SDK，所述SDK预设有用于监听所述通讯组件是否接收到消息的接口和用于服务治理参数热更新的执行逻辑；所述SDK初始化时，基于所述执行逻辑确定各服务治理参数在业务代码中的位置；目标业务服务从所述配置中心获取所述更新后的服务治理参数时，生成对应的更新待办任务；

各类业务服在监到所述通讯组件是否接收到所述第二消息的步骤包括：

各业务服务基于预设的SDK监听所述通讯组件是否接收到所述第二消息；

基于所述更新后的服务治理参数进行更新处理的步骤包括：

确定需进行更新处理的目标服务治理参数，并基于所述各服务治理参数在业务代码中的位置确定所述目标服务治理参数在业务代码中的目标位置；

在检测到生成所述更新待办任务时，将业务代码中所述目标服务治理参数替换为更新后的所述目标服务治理参数。

第二方面，本申请提供了一种服务治理参数更新装置，应用于分布式系统，所述分布式系统包括至少运行有各类业务服务，管理服务组件，配置中心组件，数据库和通讯总线的若干服务器，所述装置包括：

发送单元，用于在监测到所述数据库存在服务治理参数的更新事件时，向所述配置中心组件发送第一消息，其中，所述第一消息携带有所述更新事件；

获取单元，用于从所述数据库获取更新后的服务治理参数，并向所述通讯组件发送第二消息，其中，所述第二消息携带有所述更新事件；

更新单元，用于在监听到所述通讯组件接收到所述第二消息时，判断自身是否与所述更新事件相关联，若判定相关联，则从所述配置中心获取所述更新后的服务治理参数，并基于所述更新后的服务治理参数进行更新处理。

可选地，在监测所述数据库存在服务治理参数的更新事件时，所述监测单元具体用于：

在确定接收到用户触发的服务治理参数更新操作，并将更新的服务治理参数存储至所述数据库时，确定监测到所述数据库存在服务治理参数的更新事件。

可选地，所述分布式系统为基于Spring Cloud框架的系统，所述配置中心组件为Spring Cloud Config，所述通讯组件为Spring Cloud Bus。

可选地，所述服务治理包括Hystrix提供的熔断能力和限流能力，Ribbon提供的超时重试能力。

可选地，所述分布式系统中预设有软件开发工具包SDK，所述SDK预设有用于监听所述通讯组件是否接收到消息的接口和用于服务治理参数热更新的执行逻辑；所述SDK初始化时，基于所述执行逻辑确定各服务治理参数在业务代码中的位置；目标业务服务从所述配置中心获取所述更新后的服务治理参数时，生成对应的更新待办任务；

各类业务服在监到所述通讯组件是否接收到所述第二消息时，所述更新单元具体用于：

各业务服务基于预设的包SDK监听所述通讯组件是否接收到所述第二消息；

在基于所述更新后的服务治理参数进行更新处理时，所述更新单元具体用于：

确定需进行更新处理的目标服务治理参数，并基于所述各服务治理参数在业务代码中的位置确定所述目标服务治理参数在业务代码中的目标位置；

在检测到生成所述更新待办任务时，将业务代码中所述目标服务治理参数替换为更新后的所述目标服务治理参数。

第三方面，本申请实施例提供一种分布式系统，该分布式系统包括：

存储器，用于存储程序指令；

处理器，用于调用所述存储器中存储的程序指令，按照获得的程序指令执行如上述第一方面中任一项所述的方法的步骤。

第四方面，本申请实施例还提供了一种计算机可读存储介质，所述计算机可读存储介质存储有计算机可执行指令，所述计算机可执行指令用于使所述计算机执行如上述第一方面中任一项所述方法的步骤。

综上可知，本申请实施例提供的服务治理参数更新方法，应用于分布式系统，所述分布式系统包括至少运行有各类业务服务，管理服务组件，配置中心组件，数据库和通讯总线的若干服务器，所述方法包括：所述管理服务组件在监测到所述数据库存在服务治理参数的更新事件时，向所述配置中心组件发送第一消息，其中，所述第一消息携带有所述更新事件；所述配置中心组件从所述数据库获取更新后的服务治理参数，并向所述通讯组件发送第二消息，其中，所述第二消息携带有所述更新事件；所述各类业务服务在监听到所述通讯组件接收到所述第二消息时，判断自身是否与所述更新事件相关联，若判定相关联，则从所述配置中心获取所述更新后的服务治理参数，并基于所述更新后的服务治理参数进行更新处理。

采用本申请实施例提供的服务治理参数更新方法，在确定目标服务治理参数更新后，主动告知配置中心组件进行获取操作，并通过通讯组件告知各业务服务，以使得与此次参数更新事件相关的目标业务服务主动从配置中心获取最新的目标服务治理参数，并进行更新处理，提升了服务治理参数跟新效率，提升了分布式系统业务稳定性。

附图说明

为了更加清楚地说明本申请实施例或者现有技术中的技术方案，下面将对本申请实施例或者现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请中记载的一些实施例，对于本领域普通技术人员来讲，还可以根据本申请实施例的这些附图获得其他的附图。

图1为本申请实施例提供的一种服务治理参数更新方法的详细流程图；

图2为本申请实施例提供的一种分布式系统的结构示意图；

图3为本申请实施例提供的一种服务治理参数更新装置的结构示意图；

图4为本申请实施例提供的另一种服务治理参数更新装置的结构示意图。

具体实施方式

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

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

示例性的，参阅图1所示，为本申请实施例提供的一种服务治理参数更新方法的详细流程图，该方法应用于分布式系统，所述分布式系统包括至少运行有各类业务服务，管理服务组件，配置中心组件，数据库和通讯总线的若干服务器，该方法包括以下步骤：

步骤100：管理服务组件在监测到上述数据库存在服务治理参数的更新事件时，向上述配置中心组件发送第一消息，其中，上述第一消息携带有上述更新事件。

本申请实施例中，分布式系统可以包括多个服务器，各服务上可以至少运行各类业务服务，管理服务组件，配置中心组件，数据库和通讯总线，也就是说，各类业务服务，管理服务组件，配置中心组件，数据库和通讯总线可以运行在同一服务器上，例如，各类业务服务，管理服务组件，配置中心组件，数据库和通讯总线均运行服务器1上；或者，各类业务服务，管理服务组件，配置中心组件，数据库和通讯总线分别运行在不同服务器上，例如，各类业务服务器运行在服务器1上，管理服务组件运行在服务器2上，配置中心组件运行在服务器3上，数据库运行在服务器4上，通讯总线运行在服务器5上，当然，以上示例只是两种极端示例，并不用于限制本申请实施例，本申请实施例中，一个服务器上可以运行至少一个组件，在此不再赘述。

本申请实施例中，管理服务组件监测所述数据库存在服务治理参数的更新事件时，一种较佳的实现方式为，所述管理服务组件在确定接收到用户触发的服务治理参数更新操作，并将更新的服务治理参数存储至所述数据库时，确定监测到所述数据库存在服务治理参数的更新事件。

也就是说，用户可以通过管理服务组件，对服务治理参数进行增、删、改的操作，并将更新后的服务治理参数视作配置保存至数据库中(也可以是Git仓库等)。管理服务组件在监测到用户触发的服务治理参数增、删、改等操作时，确定监测到数据库存在服务治理参数的更新事件。

进一步地，管理服务组件在监测到数据库存在服务治理参数的更新事件时，通过向配置中心组件发送第一消息的方式，将该服务治理参数的更新事件告知配置中心组件。

具体地，本申请实施例中，一种较佳的实现方式为，所述分布式系统为基于SpringCloud框架的系统，所述配置中心组件为Spring Cloud Config，所述通讯组件为SpringCloud Bus。

进一步地，本申请实施例中，所述服务治理包括Hystrix提供的熔断能力和限流能力，Ribbon提供的超时重试能力。

例如，如集成在Spring Cloud框架的Hystrix提供的熔断能力；

(相关参数：hystrix.command.default.circuitBreaker.enabled；

hyxtrix.command.default.circuitBreaker.forceOpen；

hyxtrix.command.default.circuitBreaker.errorThresholdPercentage；

hyxtrix.command.default.circuitBreaker.requestVolumeThreshold；

hyxtrix.command.default.circuitBreaker.sleepWindowInMilliseconds)；

如集成在Spring Cloud框架的Hystrix提供的限流能力(即线程池隔离能力)：

(相关参数：hystrix.command.default.execution.isolation.strategy；

hystrix.command.default.execution.isolation.semaphore.maxConcurrentRequest s；

hystrix.threadpool.default.queueSizeRejectionThreshold；

hystrix.threadpool.default.maxQueseSize)；

以及，如集成在Spring Cloud框架的Ribbon提供的超时重试能力：

(相关参数：default.ribbon.ReadTimeout，default.ribbon.ConnectionTimeout，default.ribbon.MaxAutoRetries，default.ribbon.MaxAutoRetriesNextServer)。

步骤110：上述配置中心组件从上述数据库获取更新后的服务治理参数，并向上述通讯组件发送第二消息，其中，上述第二消息携带有上述更新事件。

具体地，配置中心组件在接收到管理服务组件发送的第一消息后，从数据库中获取更新后的服务治理参数，得到最新的服务治理参数，进一步地，通过向通讯总线发送第二消息的方式，将该服务治理参数的更新事件告知通讯总线。

实际应用中，配置中心组件在接收到第一消息后，可以确定出此次服务治理参数更新对应的目标业务服务，即，确定此次是针对哪个业务服务对应的服务治理参数进行的更新操作。

步骤120：上述各类业务服务在监听到上述通讯组件接收到上述第二消息时，判断自身是否与上述更新事件相关联，若判定相关联，则从上述配置中心获取上述更新后的服务治理参数，并基于上述更新后的服务治理参数进行更新处理。

具体地，各业务服务在运行过中，会监听通讯总线是否接收到第二事件的操作，若监听到通讯总线接收到第二消息，则确定存在服务治理参数更新操作，进一步地，判断此次服务治理参数更新操作是否与自身相关联，若判定与自身相关联，则确定自身需要进行服务治理参数更新，那么，首先，需要从配置中心组件获取最新的，与自身相关的服务治理参数，然后基于最新的，与自身相关的服务治理参数进行参数热更新操作。

本申请实施例中，所述分布式系统中预设有软件开发工具包SDK，所述SDK预设有用于监听所述通讯组件是否接收到消息的接口和用于服务治理参数热更新的执行逻辑；所述SDK初始化时，基于所述执行逻辑确定各服务治理参数在业务代码中的位置；目标业务服务从所述配置中心获取所述更新后的服务治理参数时，生成对应的更新待办任务。

例如，为了实现各业务服务对更新的服务治理参数的监听，本申请实施例中，用于监听所述通讯组件是否接收到消息的接口指的是：在SDK中实现ApplicationContextAware和ApplicationListener<EnvironmentChangeEvent>接口，采用override方法voidonApplicationEvent(EnvironmentChangeEvent event)，完成监听逻辑，进而获取到最新的服务治理参数。

又例如，从配置中心组件获取到更新后的服务治理参数后，用于服务治理参数热更新的执行逻辑指的是：对Spring Boot AbstractConfiguration的重载逻辑通过ConfigurationManager.getConfigInstance()方法，获取AbstractConfiguration实例，并通过AbstractConfiguration的setProperty(String instancesPropertyName,String value)方法将新的服务治理参数重新设置。

那么，各类业务服在监到所述通讯组件是否接收到所述第二消息时，一种较佳的实现方式为，各业务服务基于预设的SDK监听所述通讯组件是否接收到所述第二消息。

进一步地，在基于所述更新后的服务治理参数进行更新处理时，一种较佳的实现方式为，确定需进行更新处理的目标服务治理参数，并基于所述各服务治理参数在业务代码中的位置确定所述目标服务治理参数在业务代码中的目标位置；在检测到生成所述更新待办任务时，将业务代码中所述目标服务治理参数替换为更新后的所述目标服务治理参数。

下面结合具体应用场景对本申请实施例提供的分布式系统的结构进行详细说明。示例性的，参阅图2所示，为本申请实施例提供的一种分布式系统的结构示意图，所述分布式系统包括至少运行有各类业务服务，管理服务组件，配置中心组件，数据库和通讯总线的若干服务器，其中，各组件之间的运行逻辑详见以下步骤：

步骤1、管理服务组件确定数据库中目标治理参数已更新。

具体地，当用户通过管理服务组件对数据库中目标服务治理参数进行增、删、改等操作时，管理服务组件确定数据库中目标服务治理参数已更新。

步骤2、管理服务组件向配置中心组件发送第一消息。

具体地，管理服务组件在确定数据库中目标服务治理参数已更新后，向配置中心组件发送第一消息，以告知配置中心数据库存在目标服务治理参数更新事件。

步骤3、配置中心组件从数据库中获取最新的目标服务治理参数。

具体地，配置中心组件向数据库发送最新的目标服务治理参数获取请求，数据库基于该请求向配置中心组件发送最新的目标服务治理参数。

步骤4、配置中心组件向通讯组件发送第二消息。

具体地，配置中心组件在获取到最新的目标服务治理参数后，向通讯组件发送第二消息，以告知通讯组件配置中心组件存在目标服务治理参数更新事件。

步骤5、各业务服务监听到通讯组件接收到目标服务治理参数更新事件。

具体地，各业务服务会监听通讯组件，判通讯组件是否接收到与服务治理参数更新事件相关的消息，若监听到该类消息，则会根据该消息判断此次服务治理参数更新是否与自身相关，若相关，则执行步骤6，否则，流程终止。

例如，在SDK中预设指定监听接口(或监听函数)，在监听到通讯组件接收到与服务治理参数更新事件相关的消息后，SDK将监听到的信息告知各业务服务，各业务服务根据该消息进行后续是否与自身相关的判断。

步骤6、目标业务服务从配置中心组件获取最新的目标服务治理参数。

具体地，目标业务服务向配置中心组件发送最新的目标服务治理参数获取请求，配置中心组件在接收到该请求后，向目标业务服务发送最新的目标服务治理参数。

步骤7、目标业务服务加载获取到的最新的目标服务治理参数。

具体地，可以在预设SDK中预先编写服务治理参数加载的逻辑，在初始化SDK时，确定出各服务治理参数在业务代码中的应用位置，那么，在监听到目标服务治理参数的更新事件时，会生成对应的目标更新事件，首先，基于确定出的各服务治理参数在业务代码中的应用位置，确定该目标服务治理参数在业务代码中的目标应用位置，然后，在检测到该目标更新事件时，执行该更新事件，即将目标应用位置使用得参数替换为最新的目标服务治理参数。

示例性的，参阅图3所示，为本申请实施例提供的一种服务治理参数更新装置的结构示意图，该装置应用于分布式系统，所述分布式系统包括至少运行有各类业务服务，管理服务组件，配置中心组件，数据库和通讯总线的若干服务器，所述装置包括：

监测单元30，用于在监测到所述数据库存在服务治理参数的更新事件时，向所述配置中心组件发送第一消息，其中，所述第一消息携带有所述更新事件；

获取单元31，用于从所述数据库获取更新后的服务治理参数，并向所述通讯组件发送第二消息，其中，所述第二消息携带有所述更新事件；

更新单元32，用于在监听到所述通讯组件接收到所述第二消息时，判断自身是否与所述更新事件相关联，若判定相关联，则从所述配置中心获取所述更新后的服务治理参数，并基于所述更新后的服务治理参数进行更新处理。

可选地，在监测所述数据库存在服务治理参数的更新事件时，所述监测单元30具体用于：

在确定接收到用户触发的服务治理参数更新操作，并将更新的服务治理参数存储至所述数据库时，确定监测到所述数据库存在服务治理参数的更新事件。

可选地，所述分布式系统为基于Spring Cloud框架的系统，所述配置中心组件为Spring Cloud Config，所述通讯组件为Spring Cloud Bus。

可选地，所述服务治理包括Hystrix提供的熔断能力和限流能力，Ribbon提供的超时重试能力。

可选地，所述分布式系统中预设有软件开发工具包SDK，所述SDK预设有用于监听所述通讯组件是否接收到消息的接口和用于服务治理参数热更新的执行逻辑；所述SDK初始化时，基于所述执行逻辑确定各服务治理参数在业务代码中的位置；目标业务服务从所述配置中心获取所述更新后的服务治理参数时，生成对应的更新待办任务；

各类业务服在监到所述通讯组件是否接收到所述第二消息时，所述更新单元32具体用于：

各业务服务基于预设的包SDK监听所述通讯组件是否接收到所述第二消息；

在基于所述更新后的服务治理参数进行更新处理时，所述更新单元32具体用于：

确定需进行更新处理的目标服务治理参数，并基于所述各服务治理参数在业务代码中的位置确定所述目标服务治理参数在业务代码中的目标位置；

在检测到生成所述更新待办任务时，将业务代码中所述目标服务治理参数替换为更新后的所述目标服务治理参数。

以上这些单元可以是被配置成实施以上方法的一个或多个集成电路，例如：一个或多个特定集成电路(Application Specific Integrated Circuit，简称ASIC)，或，一个或多个微处理器(digital singnal processor，简称DSP)，或，一个或者多个现场可编程门阵列(Field Programmable Gate Array，简称FPGA)等。再如，当以上某个单元通过处理元件调度程序代码的形式实现时，该处理元件可以是通用处理器，例如中央处理器(CentralProcessing Unit，简称CPU)或其它可以调用程序代码的处理器。再如，这些单元可以集成在一起，以片上系统(system-on-a-chip，简称SOC)的形式实现。

进一步地，本申请实施例提供的服务治理参数更新装置，从硬件层面而言，所述服务治理参数更新装置的硬件架构示意图可以参见图4所示，所述服务治理参数更新装置可以包括：存储器40和处理器41，

存储器40用于存储程序指令；处理器41调用存储器40中存储的程序指令，按照获得的程序指令执行上述方法实施例。具体实现方式和技术效果类似，这里不再赘述。

可选地，本申请还提供一种服务器，包括用于执行上述方法实施例的至少一个处理元件(或芯片)。

可选地，本申请还提供一种程序产品，例如计算机可读存储介质，该计算机可读存储介质存储有计算机可执行指令，该计算机可执行指令用于使该计算机执行上述方法实施例。

这里，机器可读存储介质可以是任何电子、磁性、光学或其它物理存储装置，可以包含或存储信息，如可执行指令、数据，等等。例如，机器可读存储介质可以是：RAM(RadomAccess Memory，随机存取存储器)、易失存储器、非易失性存储器、闪存、存储驱动器(如硬盘驱动器)、固态硬盘、任何类型的存储盘(如光盘、dvd等)，或者类似的存储介质，或者它们的组合。

上述实施例阐明的系统、装置、模块或单元，具体可以由计算机芯片或实体实现，或者由具有某种功能的产品来实现。一种典型的实现设备为计算机，计算机的具体形式可以是个人计算机、膝上型计算机、蜂窝电话、相机电话、智能电话、个人数字助理、媒体播放器、导航设备、电子邮件收发设备、游戏控制台、平板计算机、可穿戴设备或者这些设备中的任意几种设备的组合。

为了描述的方便，描述以上装置时以功能分为各种单元分别描述。当然，在实施本申请时可以把各单元的功能在同一个或多个软件和/或硬件中实现。

本领域内的技术人员应明白，本申请的实施例可提供为方法、系统、或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本申请实施例可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

本申请是参照根据本申请实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可以由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其它可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其它可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

而且，这些计算机程序指令也可以存储在能引导计算机或其它可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或者多个流程和/或方框图一个方框或者多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其它可编程数据处理设备上，使得在计算机或者其它可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其它可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

以上所述仅为本申请的较佳实施例而已，并不用以限制本申请，凡在本申请的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本申请保护的范围之内。

Claims (10)

1.一种服务治理参数更新方法，其特征在于，应用于分布式系统，所述分布式系统包括至少运行有各类业务服务，管理服务组件，配置中心组件，数据库和通讯总线的若干服务器，所述方法包括：

所述管理服务组件在监测到所述数据库存在服务治理参数的更新事件时，向所述配置中心组件发送第一消息，其中，所述第一消息携带有所述更新事件；

所述配置中心组件从所述数据库获取更新后的服务治理参数，并向所述通讯组件发送第二消息，其中，所述第二消息携带有所述更新事件；

所述各类业务服务在监听到所述通讯组件接收到所述第二消息时，判断自身是否与所述更新事件相关联，若判定相关联，则从所述配置中心获取所述更新后的服务治理参数，并基于所述更新后的服务治理参数进行更新处理。

2.如权利要求1所述的方法，其特征在于，管理服务组件监测所述数据库存在服务治理参数的更新事件的步骤包括：

所述管理服务组件在确定接收到用户触发的服务治理参数更新操作，并将更新的服务治理参数存储至所述数据库时，确定监测到所述数据库存在服务治理参数的更新事件。

3.如权利要求1所述的方法，其特征在于，所述分布式系统为基于Spring Cloud框架的系统，所述配置中心组件为Spring Cloud Config，所述通讯组件为Spring Cloud Bus。

4.如权利要求1所述的方法，其特征在于，所述服务治理包括Hystrix提供的熔断能力和限流能力，Ribbon提供的超时重试能力。

5.如权利要求1所述的方法，其特征在于，所述分布式系统中预设有软件开发工具包SDK，所述SDK预设有用于监听所述通讯组件是否接收到消息的接口和用于服务治理参数热更新的执行逻辑；所述SDK初始化时，基于所述执行逻辑确定各服务治理参数在业务代码中的位置；目标业务服务从所述配置中心获取所述更新后的服务治理参数时，生成对应的更新待办任务；

各类业务服在监到所述通讯组件是否接收到所述第二消息的步骤包括：

各业务服务基于预设的SDK监听所述通讯组件是否接收到所述第二消息；

基于所述更新后的服务治理参数进行更新处理的步骤包括：

确定需进行更新处理的目标服务治理参数，并基于所述各服务治理参数在业务代码中的位置确定所述目标服务治理参数在业务代码中的目标位置；

在检测到生成所述更新待办任务时，将业务代码中所述目标服务治理参数替换为更新后的所述目标服务治理参数。

6.一种服务治理参数更新装置，其特征在于，应用于分布式系统，所述分布式系统包括至少运行有各类业务服务，管理服务组件，配置中心组件，数据库和通讯总线的若干服务器，所述装置包括：

发送单元，用于在监测到所述数据库存在服务治理参数的更新事件时，向所述配置中心组件发送第一消息，其中，所述第一消息携带有所述更新事件；

获取单元，用于从所述数据库获取更新后的服务治理参数，并向所述通讯组件发送第二消息，其中，所述第二消息携带有所述更新事件；

更新单元，用于在监听到所述通讯组件接收到所述第二消息时，判断自身是否与所述更新事件相关联，若判定相关联，则从所述配置中心获取所述更新后的服务治理参数，并基于所述更新后的服务治理参数进行更新处理。

7.如权利要求6所述的装置，其特征在于，在监测所述数据库存在服务治理参数的更新事件时，所述监测单元具体用于：

在确定接收到用户触发的服务治理参数更新操作，并将更新的服务治理参数存储至所述数据库时，确定监测到所述数据库存在服务治理参数的更新事件。

8.如权利要求6所述的装置，其特征在于，所述分布式系统为基于Spring Cloud框架的系统，所述配置中心组件为Spring Cloud Config，所述通讯组件为Spring Cloud Bus。

9.如权利要求6所述的装置，其特征在于，所述服务治理包括Hystrix提供的熔断能力和限流能力，Ribbon提供的超时重试能力。

10.如权利要求6所述的装置，其特征在于，所述分布式系统中预设有软件开发工具包SDK，所述SDK预设有用于监听所述通讯组件是否接收到消息的接口和用于服务治理参数热更新的执行逻辑；所述SDK初始化时，基于所述执行逻辑确定各服务治理参数在业务代码中的位置；目标业务服务从所述配置中心获取所述更新后的服务治理参数时，生成对应的更新待办任务；

各类业务服在监到所述通讯组件是否接收到所述第二消息时，所述更新单元具体用于：

各业务服务基于预设的SDK监听所述通讯组件是否接收到所述第二消息；

在基于所述更新后的服务治理参数进行更新处理时，所述更新单元具体用于：

确定需进行更新处理的目标服务治理参数，并基于所述各服务治理参数在业务代码中的位置确定所述目标服务治理参数在业务代码中的目标位置；

在检测到生成所述更新待办任务时，将业务代码中所述目标服务治理参数替换为更新后的所述目标服务治理参数。

Images