开发工具 个推基于 Consul 的配置管理

GeTui · 2019年02月25日 · 最后由 qrgeng 回复于 2019年05月28日 · 7688 次阅读

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

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

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

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

让我对 consul 有了新的认识,感谢!但后半部分有点没看懂,麻烦解答下,谢谢。 consul templete 的模板文件 config-tree.ctmpl,该模板在 /consul/path/to/configFiles 路径下的配置发生变化时,会渲染出一个 Json 格式的字符串,其中包含了 /consul/path/to/configFiles 下所有的 K/V.。这个配置发生变化,是指 配置文件被修改,会自动重新加载所有配置项吗?我现在搭了一个小集群,想做配置文件的动态更新,看到 consul templete 就蒙圈。请指点指点,多谢

需要 登录 后方可回复, 如果你还没有账号请 注册新账号