微服务基于consual的配置管理

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

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

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（热更新）这两种方式来实现。

以上关于consual做微服务的配置管理只是一种解决方案，有更好更具体的方案请大家留言，再次感谢!