本文分享自华为云社区《如何利用动态配置中心在JavaAgent中实现微服务的多样化治理》，作者：华为云开源 。

一、前言

随着 JavaAgent 在微服务治理方面的广泛应用和发展，我们可以在运行时对微服务进行监控、管理和调整，以满足不同的业务需求和运行环境。然而，随着微服务架构的复杂性增加，管理和配置微服务的治理变得越来越困难，因此利用动态配置中心在 JavaAgent 中实现微服务多样化治理变得至关重要。

Sermant 是基于 Java 字节码增强技术的无代理服务网格，支持通过动态配置实现微服务的多样化治理。以下是 Sermant 的微服务架构：

Sermant 虽然不直接提供动态配置中心，但是 Sermant 基于不同的配置中心实现了动态配置功能，基于该功能 Sermant 不仅可以监听主流配置中心配置信息的修改、也可以针对不同的场景进行配置监听，例如：Sermant 不仅可以监听服务的配置变更，还可以监听应用的全局配置变更。基于该功能可以更好的帮助开发人员和运维人员管理微服务治理的能力。

二、Sermant 的动态配置模型

Sermant 动态配置模型是一种基于分层模型设计的配置管理方案，它的核心组件包括 Group 和 Key。

Sermant 通过不同的 Group（分组信息）来对配置项进行隔离，使配置管理更具灵活性和可扩展性；同时，通过 Key 对配置项进行具体属性的标识，实现了对配置项的精准控制和高效维护。

在 Sermant 动态配置模型中，Group 的数量不宜过多。Sermant 动态配置模型中 Group 的实现是基于配置中心的数据模型，例如：Nacos 的 namespace，Nacos 的 namespace 是用于实现租户隔离的，不宜过多，因此 Sermant 动态配置模型的 Group 数量也不宜过多。

与 Group 相比，Sermant 动态配置模型允许创建多个 Key，但单个实例订阅的 Key 不宜太多。这是因为在配置项的订阅和维护过程中，如果单个实例订阅的 Key 过多，可能会导致服务的性能出现问题，甚至引发配置更新不及时或者配置冲突的问题。因此，控制单个实例订阅的 Key 的数量是保证配置管理高效性和可用性的关键因素之一。

Sermant 动态配置模型通过 Group 和 Key 的有机结合，实现了对复杂配置场景的全面覆盖和高效支撑。同时，通过控制 Group 和 Key 的数量，简化了配置项的订阅和更新流程，提高了系统的可用性和可维护性。

Sermant 的动态配置模型如下图所示：

• 基于 Zookeeper 的配置模型实现

Zookeeper 采用树状的数据模型，会将数据信息保存在一个个数据节点上，这些节点被称为 Znode，Znode 是 Zookeeper 中最小数据单位，一个 Znode 可以有多个子节点。可以通过路径确定的一个唯一的 Znode，如/zookeeper/key1。如下图所示：

Sermant 的动态配置模型基于 Zookeeper 配置中心的实现方式如下所示：

Group（分组信息）：Znode 节点的父节点路径信息作为 Group 信息

Key（配置项名称）：Znode 节点的节点名称作为配置项的 Key，节点数据作为具体的配置内容。

Znode 节点可以通过不同的路径进行隔离，不同路径下可以存在节点名称相同的节点。保证 Sermant 通过不同的 Group（分组信息）来对配置项进行隔离，同一个 Group（分组信息）下可以有相同 Key（配置项名称）。

• 基于 Nacos 的配置模型实现

Nacos 数据模型为层次模型，对于 Nacos 配置管理，通过 Namespace、Group、Date ID 能够定位到一个配置集。如下图所示：

Namespace（命名空间）主要用于不同环境的配置隔离，Group（配置分组）主要用于不同的项目或者应用，配置集可以包含了系统的各种配置信息，每个配置集的 ID 即 Data Id。配置集中包含的一个个配置内容就是配置项。它代表了一个具体的可配置的参数与其值域，通常以 key=value 的形式存在

Sermant 的动态配置模型基于 Nacos 配置中心的实现方式如下：

Group（分组信息）：将 Nacos 的 Namespace（命名空间）和配置分组（Group）组合起来作为 Sermant 的动态配置模型的分组信息。

Key（配置项名称）：Nacos 的配置集 ID（Data Id）作为 Sermant 的动态配置模型的配置项名称。

配置集（Data Id）可以通过不同的 Namespace（命名空间）和配置分组（Group）进行隔离，不同的 Namespace（命名空间）和配置分组（Group）下可以存在名称相同的配置集（Data Id）。保证 Sermant 通过不同的 Group（分组信息）来对配置项进行隔离，同一个 Group（分组信息）下可以有相同 Key（配置项名称）。

• 基于 ServiceComb Kie 的配置模型实现

ServiceComb-Kie（ServiceComb Key-Value Store）的数据模型基于键值对（Key-Value）的方式来存储和管理配置信息。ServiceComb-Kie 基于标签来控制配置的生效范围，通过标签和 Key 可以确定唯一的键值对。

Sermant 的动态配置模型基于 ServiceComb-Kie 的实现方式如下：

Group（分组信息）：ServiceComb-Kie 的标签信息作为 Sermant 的动态配置模型的 Group 信息。

Key（配置项名称）：ServiceComb-Kie 的配置项名称作为 Sermant 的动态配置模型的 Key。

ServiceComb-Kie 的配置项可以通过不同的标签信息进行隔离，不同标签下可以存在相同配置项名称的配置，同样的标签信息下可以配置不同的配置项。保证 Sermant 通过不同的 Group（分组信息）来对配置项进行隔离，同一个 Group（分组信息）下可以有相同 Key（配置项名称）。

三、Sermant 动态配置模型的最佳实践

动态配置是 Sermant 的核心功能之一，可以帮助 Sermant 统一管理微服务治理能力，例如：灰度发布、限流降级、链路追踪等。如下图所示：

使用 Sermant 动态配置进行微服务服务治理时，要避免创建过多的 Group（分组信息）和 Key（配置项名称），减少配置的复杂性和混乱度，降低监听过多配置带来的性能消耗，也可以提高配置的可维护性和可读性。

接下来我们通过标签路由插件讲解 Sermant 动态配置的最佳实践方式。

1) 标签路由插件的功能

标签路由插件是 Sermant 实现微服务路由治理功能的基础，标签路由插件通过对服务提供者以服务粒度或者全局粒度配置路由规则，将某一个或多个服务的提供者划分到同一个分组，约束流量只在指定分组中流转，从而实现流量隔离的目的。标签路由插件也是流量染色、蓝绿发布、灰度发布、全链路灰度、同可用区优先调用等场景的能力基础。

2) 标签路由插件的动态配置模型

标签路由插件基于 Sermant 的动态配置模型进行规则配置。在微服务场景中标签路由插件动态配置模型实现如下：

Group（分组信息）：基于应用名称 appName 和环境名称 environment 组成，例如：app=${appName}&environment=${ environment }

Key（配置项名称）：针对服务粒度的规则，key 值为 servicecomb.routeRule.${srviceName}，${ srviceName }为目标应用的微服务名称。针对全局粒度的规则，key 值为 servicecomb.globalRouteRule。

标签路由插件基于 zookeeper 配置中心的配置模型实现如下所示：

通过标签路由插件基于 Sermant 动态配置模型的实现我们可以看出，Sermant 动态配置模型的 Group（分组信息）支持基于应用名称和环境名称生成，此时针对于单个微服务应用只需要创建一个 Group（分组信息），可以避免创建过多的的 Group（分组信息）。Sermant 动态配置模型的 Key(配置项名称)支持基于微服务场景和服务名称生成，此时可以针对单个服务、也可以针对所有服务进行动态配置，保证单个实例不需要监听多个配置项，避免监听多个配置项导致服务性能下降、配置更新不及时或者配置冲突等问题。

四、总结

JavaAgent 中的动态配置在实现微服务的多样化治理中扮演着重要的角色，是实现微服务治理的重要手段之一。通过动态配置，可以对微服务的运行时状态进行动态调整，从而实现微服务的动态治理。例如，可以根据实际负载情况通过动态配置来调整微服务的负载均衡策略，实现更加精细化的负载均衡。

而使用 Sermant 的动态配置模型进行微服务治理，不仅可以实现微服务的动态治理，还可以减少 JavaAgent 在微服务治理时由于 Group 太多或者实例监听的配置项过多带来的消耗，可以提高配置的可维护性和可读性。此外，Sermant 的动态配置模型还支持主流的配置中心 ServiceComb Kie、Zookeeper、Nacos，可以满足不同微服务治理场景下的使用，让用户更方便地进行微服务治理和运维操作。

点击关注，第一时间了解华为云新鲜技术~