个推基于Consul的配置管理

发表于:2019-3-05 20:05

字体: | 上一篇 | 下一篇 | 我要投稿

 作者:个推    来源:思否

  在微服务架构体系中,由于微服务众多,服务之间又有互相调用关系,因此,一个通用的分布式配置管理是必不可少的。一般来说,配置管理需要解决配置集中管理、在系统运行期间可实现动态配置、配置修改后支持自动刷新等问题。
  在大多数微服务体系中,都会有一个名为配置文件的功能模块来提供统一的分布式配置管理。构建配置中心,统一对应用中各个微服务进行管理,对微服务体系的意义重大。
  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的基础上进行二次开发,实现了配置版本的有效控制,对微服务的配置管理起到了良好的辅助作用。

     上文内容不用于商业目的,如涉及知识产权问题,请权利人联系博为峰小编(021-64471599-8017),我们将立即处理。
《2023软件测试行业现状调查报告》独家发布~

关注51Testing

联系我们

快捷面板 站点地图 联系我们 广告服务 关于我们 站长统计 发展历程

法律顾问:上海兰迪律师事务所 项棋律师
版权所有 上海博为峰软件技术股份有限公司 Copyright©51testing.com 2003-2024
投诉及意见反馈:webmaster@51testing.com; 业务联系:service@51testing.com 021-64471599-8017

沪ICP备05003035号

沪公网安备 31010102002173号