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

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

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

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的基础上进行二次开发，实现了配置版本的有效控制，对微服务的配置管理起到了良好的辅助作用。