zoukankan      html  css  js  c++  java
  • 个推基于Consul的配置管理

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

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

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

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

  • 相关阅读:
    118/119. Pascal's Triangle/II
    160. Intersection of Two Linked Lists
    168. Excel Sheet Column Title
    167. Two Sum II
    172. Factorial Trailing Zeroes
    169. Majority Element
    189. Rotate Array
    202. Happy Number
    204. Count Primes
    MVC之Model元数据
  • 原文地址:https://www.cnblogs.com/evakang/p/10430396.html
Copyright © 2011-2022 走看看