作者：个推应用平台基础架构高级研发工程师 阿飞

在微服务架构体系中，由于微服务众多，服务之间又有互相调用关系，因此，一个通用的分布式配置管理是必不可少的。一般来说，配置管理需要解决配置集中管理、在系统运行期间可实现动态配置、配置修改后支持自动刷新等问题。

在大多数微服务体系中，都会有一个名为配置文件的功能模块来提供统一的分布式配置管理。构建配置中心，统一对应用中各个微服务进行管理，对微服务体系的意义重大。

Consul 为什么适合做配置管理

Consul 作为轻量级的分布式 K/V 存储系统，搭建方便，可用性高，并且支持多数据中心，提供 Web UI 进行 K/V 管理。此外 Consul 还可以结合 Consul-Template 或者在代码中引入 Consul Client 的相关依赖创建 Watcher 来实时 Watch K/V 的变化，是配置管理的不二之选。

下图为个推微服务体系基于 Consul 配置管理的整体设计。其中，CCenter 就是在 Consul 的基础上进行二次开发的配置中心。

微服务体系下配置的分类和组织形式

在实践中，不同产品线的配置会放置在 Consul 的不同路径下，实现不同产品线配置之间的隔离。

按照配置的用途，可将同一产品线下的配置分为三类：

1.API 网关相关配置；

2.服务注册与发现相关配置；

3.应用相关配置。

其中，每类配置会对应 Consul 上的不同目录。

按照配置的变化特性，可将配置分为两类：

1.环境相关的全局配置

如 MySQL 等外部依赖相关的配置和其他与环境相关的配置，这类配置在开发测试生产环境中存在差异，需要为不同环境配置不同的值。 2.应用本身的配置

一般为不经常性发生变化、可动态调整、开关的配置。这类配置比较稳定，在初始化后，只有在需要时才会改动，通常会设置默认值。这两类配置在 Consul 上会放在不同的子目录下。这样 QA、运维只需要关注环境差异部分即可。

基于以上对配置的分类，最终 Consul 上的 Key 的格式如下：

/ProductLine_Prefix/Usage_Prefix/Environmental_Correlation_Prefix/Config_Item_Path

其中，

ProductLine_Prefix：用来隔离不同产品线的配置；

Usage_Prefix：用来区分配置的用途；

Environmental_Correlation_Prefix：用来分隔与环境相关的配置；

Config_Item_Path：具体的配置项。

配置在 Consul 上的组织形式有以下两种：

1.以配置文件的形式组织，Consul 上的一个 K/V，对应一个配置文件，如 nginx 的配置文件。

2.以配置项的形式组织，将配置文件模板化，拆成一个个的配置项，每个配置项对应 Consul 上的一个 K/V，多个配置项对应一个配置文件。大部分配置文件本身都是以 K/V 的形式组织的，均适合模板化，模板化后即可以按照配置项的特性，在 Consul 上分成不同的类别进行管理。

如何实现配置更新

Consul 上的 K/V，要如何生成可加载的应用，或可使用的配置呢？

1.用 Node 和 Lua 实现的微服务的配置更新，使用 Consul-Template 来实现；

2.用 Java 实现的微服务的配置更新，通过 Consul-Template 工具（需要重启应用）和在代码中引入 Consul Client 的依赖创建 Watcher（热更新）这两种方式来实现。

Consul-Template 如何使用？

Consul-Template 是一个后台进程，它可以根据 Watch Consul 上 K/V 的变化，更新任意数量的模板，同时生成对应的文件，之后还可以运行任意的命令。要使用 Consul-Template 一般需要定义两个文件：

1.模板文件

模板文件一般按照 Go Template 的格式进行编写，示例如下：

config-tree.ctmpl:

{{ tree /consul/path/to/configFiles | explode | toJSONPretty }}

该模板在 /consul/path/to/configFiles 路径下的配置发生变化时，会渲染出一个 Json 格式的字符串，其中包含了 /consul/path/to/configFiles 下所有的 K/V.

config-kv.ctmpl:

return { host='{{ printf "%s/mysql/host" (env "CONSUL_CONFIG_PREFIX") | key }}', port={{ keyOrDefault (printf "%s/mysql/port" (env "CON-SUL_CONFIG_PREFIX")) "3306" }}, user='{{ printf "%s/mysql/user" (env "CONSUL_CONFIG_PREFIX") | key }}', password='{{ printf "%s/mysql/password" (env "CON-SUL_CONFIG_PREFIX") | key }}' }

该模板是按照配置项来渲染的，在该模板中使用了 Consul-Template 定义两个方法 key 和 keyOrDefault。其中，key 会在 Consul 上对应的 K/V 创建后，再进行渲染模板；keyOrDefault 则会在 Consul 上没有对应的 K/V 时，使用默认值代替。

模板中还使用了 " CONSUL_CONFIG_PREFIX " 这个环境变量，这样，不同的产品线便可以使用同一个模板文件，只需要修改" CONSUL_CONFIG_PREFIX "这个环境变量的值即可。

2.配置文件

配置文件是按照 HashiCorp Configuration Language (HCL) 编写的，示例如下：

template { source = "config-tree.ctmpl", destination = "config-tree.json", command = "sh updateAndReload.sh config-tree.json ” }

template { source = "config-kv.ctmpl", destination = "config-kv.lua", command = "sh updateAndReload.sh config-kv.lua ” }

该配置文件的作用是使用" source"指定的两个模板文件进行渲染，将渲染的结果分别保存在" destination"指定的文件中，保存成功后，分别运行" command"指定的命令来更新并加载配置文件。

配置的更新方式

在个推的微服务体系中，配置的更新方式有两种：

1.替换配置文件，reload 服务

2.调用服务接口直接更新内存中的配置

而在 Java 实现的微服务中，热更新配置通常是在代码中引入 Consul Client 的依赖，在应用启动时，会初始化一个 Watcher 来监听 Consul 上对应目录下 K/V 的变化，相关的 K/V 发生变化时，Watcher 会负责将其拉取下来，然后调用相关的代码进行配置的更新。

基于 Consul 的二次开发-CCenter

配置中心 CCenter 在 Consul 上提供了更友好的 WEB UI，并且增加版本控制，每次配置的更新都会生成一个版本，在应用版本后，配置才真正生效，可以更加方便地进行配置版本间的差异比较，应用任意版本的配置。

总结

以上就是个推在微服务实践中，基于 Consul 实现的一套配置管理的方案，作为轻量级的分布式 K/V 存储系统，Consul 非常适合用于配置管理，可以帮助开发者们方便、快速地搭建配置中心，结合 Consul-Template 则可以方便地实现配置的实时更新，在 Consul 的基础上进行二次开发，实现了配置版本的有效控制，对微服务的配置管理起到了良好的辅助作用。