十、TSF配置管理

前面我们已经介绍了TSF的运维管理，服务治理功能，接下来我们看一下TSF的配置管理功能

学习目标

通过本文的学习，你将可以：

掌握TSF配置管理的基本操作
掌握应用配置的基本操作
掌握全局配置的基本操作
掌握配置回调的基本操作
掌握配置模板的基本操作
掌握文件配置的基本操作

第一章配置管理概述

1.1 配置管理概述

配置管理：
- 为了更好的解决分布式环境下多台服务实例的配置不统一问题，TSF 提供了分布式配置功能。
TSF 的配置功能具有如下特点：
- 支持配置的分布式化管理
- 支持在控制台上编写 YAML 格式的配置。
- 配置异构系统管理
  - 异构系统是指一个应用有多个部署组时（例如开发环境、测试环境的部署组），由于配置不同，从而需要多个部署包的情况。使用分布式配置功能后，用户只需要同一个部署包，不同部署组的配置会自动分配。
- 配置更新自动化：
  - 用户在平台更新配置，使用该配置的系统会自动发现该情况，并应用新配置。
目前 TSF 分布式配置功能仅支持 Spring Cloud 类型的应用。

1.2 配置管理分类

配置管理分类：
- 应用配置
- 全局配置
- 本地配置
应用配置和全局配置属于 TSF 平台上的配置（下面称为远程配置），本地配置是应用程序在代码工程中创建的配置（如 application.yml 和 bootstrap.yml）。应用配置和全局配置的根本区别在于配置发布的范围，应用配置发布的范围是部署组维度，全局配置发布的范围是命名空间维度。
优先级：应用配置 > 全局配置 > 本地配置

第二章应用配置

2.1 使用方式-使用流程

TSF动态配置使用步骤：
如上采用应用配置方式，全部配置使用方式跟应用配置类似，只是优先级不一样。
动态配置使用步骤：
- pom.xml 添加配置依赖项
- 在代码中引用配置
- TSF平台填写配置
- 通过 TSF 平台下发动态配置，配置的作用范围是部署组。

2.1.1 添加依赖

步骤一：

项目根目录pom.xml配置文件中添加依赖项：

<dependency>
		<groupId>org.springframework.cloud</groupId>
		<artifactId>spring-cloud-starter-consul-config</artifactId>
</dependency>
<!-- 使用分布式配置自动刷新功能，需要显示添加actuator的依赖包 -->
<dependency>
		<groupId>org.springframework.boot</groupId>
		<artifactId>spring-boot-starter-actuator</artifactId>
</dependency>

2.1.2 引用配置

步骤二：
- 引用配置，二种方式：
  - @ConfigurationProperties注解方式
  - @Value 注解方式
- @ConfigurationProperties 使用类映射多个配置，适合多个配置映射使用
- @Value 单个属性映射配置，适合少量配置映射使用
@ConfigurationProperties支持松散语法， @Value不支持松散语法，松散语法也就是属性命名规则示例如下：
- person.firstName:使用标准方式
- person.first-name:大写用-
- person.first_name:大写用_
- PERSON_FIRST_NAME: 系统属性推荐使用这种写法
@ConfigurationProperties @Validated 支持 JSR303数据校验，@Value不支持
@ConfigurationProperties不支持EL表达式（如：userAge = #{2*6}）
@Value支持EL表达式（如：@Value(userAge=#{2*6})）
在某个业务逻辑中需要获取一下配置文件中的某项值，使用@Value；如果专门编写了一个 javaBean来和配置文件进行映射，我们就直接使用@ConfigurationProperties

2.1.2 引用配置（续）

使用配置类 @ConfigurationProperties
例如下图中使用@ConfigurationProperties方式，代码如下：
- 使用 @ConfigurationProperties 注解来标明这个类是一个配置类。
- 使用@RefreshScope注解开启自动刷新机制。
@ConfigurationProperties 注解中的prefix代表配置的前缀，也就是说需要符合这个前缀配置才能映射到类中的属性
@RefreshScope注解开启自动刷新机制，也就是在配置发生改变的时候回自动刷新，不需要重新应用

2.1.2 引用配置(续）

使用属性配置注解： @Value；代码如下：

1 2	`@Value("${provider.config.name:name1}") private String name;`

如上代码通过@Value注解指定配置的名称为： provider.config.name；然后把provider.config.name配置对应的值注入到name属性中。
provider.config.name:name1：冒号后面的“name1”是默认值
上述代码演示了使用@value方式注入配置。在启动类 ProviderApplication 中，使用 @Value 注解来标识一个配置变量。

2.1.3 配置内容填写

步骤三：
- TSF控制台填写配置
具体操作步骤：
- 登录 TSF 控制台。
- 单击导航栏应用配置。
- 选择新建配置。
- 单击【新建】按钮。

填写配置内容。配置可以按照 YAML 方式进行编辑。YAML 格式规范参考 YAML 格式介绍，官网文档：https://cloud.tencent.com/document/product/649/17925。
单击【提交】按钮。

2.1.4 发布配置

步骤四：
- 发布配置：
在配置版本中选择对应的版本，点击“发布” ，然后选择对应的部署组就可以把配置发布到对应的部署组中。
配置发布以后可以在日志查看对应配置的打印记录也可以通过浏览器访问配置对应链接的url验证配置更新情况

2.2 应用配置管理的功能

应用配置的功能：
- 创建配置项：一个配置项管理多个版本的配置
- 生成新版本：基于历史版本生成新版本
- 发布配置：支持发布配置到部署组
- 回滚：回滚到上一个版本的配置

2.2.1 应用配置管理的功能

应用配置的创建、发布、更新、回滚操作都比较简单，都是直接点击对应的按钮就可以实现了，参考官网文档：https://cloud.tencent.com/document/product/649/15539

2.3 配置优先级

TSF 支持多份应用配置发布到同一个部署组，多份配置会根据发布时间的先后顺序以 key 来进行合并。举例来说，应用 A 有两个应用配置项 config-1， config-2。

config-1 的配置内容：

# config-1配置
username: test_user1
feature.status: false
feature.color: red

config-2 的配置内容：

1
2
3

# config-2配置
username: test_user2
feature.status: true

config-1 和 config-2 先后发布到部署组 group ，会按照 key 来进行合并。

# config-1 与 config-2 合并结果
username: test_user2
feature.status: true
feature.color: red

配置优先级：应用配置 > 全局配置 > 本地配置
多份应用发布到同一个部署组的时候按照优先级，先后循环进行合并；相同的配置项优先级高的替换优先级低的，后发布的配置替换先发布的配置；不同的配置项之间合并

第三章全局配置

3.1 全局配置概述

全局配置：
- 用于动态更新应用代码中的配置。全局配置可以保证配置内容在某个集群或者命名空间中全局生效。
全局配置包括管理配置和发布配置两部分。
- 管理配置包括创建配置、生成新版本配置和删除配置。
- 配置可以发布到命名空间下的所有应用。
全局配置的使用跟前面提到的“应用配置”使用一致；优先级不一样：
优先级：应用配置 > 全局配置 > 本地配置

3.1 全局配置概述（续）

列表页面也跟应用页面一致。其中“新建”按钮可以直接新建配置，导入配置模块需要配置“配置模板”功能使用，在后续会介绍；配置列表右侧的配置发布历史中可以查看配置的发布记录。

第四章配置回调

4.1 配置回调使用场景

配置更新触发回调功能允许程序在不重启的情况下动态修改业务逻辑。
当配置更新时，触发配置回调方法的调用。
配置更新触发回调功能的使用场景包括：
- 程序使用一个防刷开关配置，当开关为启用状态时，启动防刷逻辑，当开关为关闭状态时，停用防刷逻辑。
- 程序使用一个 ReidsConfig 的动态配置类，包含 redis 的 host 和 port，当更新这个配置时，更新 Redis 实例。
- 配置更新后发出通知消息，通知本地或者远程的其他模块执行变更逻辑。
前面我们已经使用了配置项的动态更新，但是如果更新配置项后需要刷新其它业务对象（比如更改Redis配置后需要刷新Redis实例对象）怎么办？这个时候就需要用到我们的配置回调功能。

4.2 使用方式-配置回调

如下图代码：如果配置项“io.test”发生变化，就会触发callback方法：

@ConfigChangeListener(prefix = "io.test")
public class TestConfigListener implements ConfigChangeCallback {
    private Logger logger =
    LoggerFactory.getLogger(SimpleConfigurationListener.class);

    @Override
    public void callback(ConfigProperty lastConfigItem, ConfigProperty
    currentConfigItem) {
    logger.info("config change=====");
    }
}

如上代码实现了监听“io.test”配置，当配置发生变化就触发callback方法打印日志
实现方式：通过实现ConfigChangeCallback 接口（重新callback方法）实现配置回调。

第五章配置模板

5.1 配置模板概述

配置模板
- 是为了方便用户保存常用的配置信息，也提供了 Ribbon, Hystrix, Zuul 等 Spring Cloud 组件的配置模板。用户可以基于已有的配置模板进行修改。
- 用户可以基于配置模板来创建应用配置或者全局配置。

5.2 新建和使用配置模板

具体使用步骤：
- 登录 TSF 控制台。
- 单击左侧导航栏配置管理，再选择配置模板。
- 单击【新建模板】
- 填写配置模板信息。
- 模板名：填写模板名。
- 类型：Ribbon、Hystrix、Zuul 或自定义。
- 配置内容：根据不同的类型，会自动生成对应的配置内容。用户可以进一步修改配置内容。
- 描述：填写描述信息。
- 单击【提交】按钮。

5.2 新建和使用配置模板（续）

用户可以使用配置模板来创建应用配置或者全局配置，下面以全局配置举例。
- 登录 TSF 控制台。
- 单击左侧导航栏配置管理，再选择全局配置。
- 单击【导入配置模板】。
- 选择要导入的配置模板
- 在新建配置页面中，补充全局配置的其他信息

第六章文件配置

6.1 文件配置概述

文件配置：
- 文件配置功能支持用户通过控制台将配置下发到服务器的指定目录。应用程序通过读取该目录下的配置文件来实现特殊的业务逻辑。
文件配置支持如下功能：
- 创建文件配置项：一个文件配置项管理多个版本的配置。
- 生成新版本：基于历史版本生成新版本。
- 发布配置：支持发布配置到部署组。
- 发布情况：查看配置项的发布到哪些部署组。
- 回滚：回滚到上一个版本的配置。

6.1 文件配置概述（续）

使用文件配置的前提条件：
- 对于使用虚拟机部署的应用：只有2018年11月20号之后导入到集群的云主机上会具有满足应用配置功能的环境。
- 对于容器部署的应用：该功能需要用户修改 Dockerfile 和启动脚本
  - Dockerfile 中需要将 tsf-consul-template-docker.tar.gz添加到到 /root/ 目录下
    1
    2
    #copy consul-template ADD tsf-consul-template-docker.tar.gz /root/
  - 启动脚本 run.sh 中，需要执行 /root/tsf-consul-template-docker/script 目录下的start.sh 脚本
    1
    sh /root/tsf-consul-template-docker/script/start.sh
tsf-consul-template-docker.tar.gz下载地址： https://main.qcloudimg.com/raw/fa79996a5c995c35b9f948742df4d9d8/tsf-consultemplate-docker.tar.gz

6.2 文件配置使用场景

定时检查配置是否更新
- 应用程序中包含了读取指定目录配置文件的逻辑，例如定时去检查配置文件是否更新（通过文件 md5 是否变化等方式检查），如果更新了会执行特定逻辑。
- 在控制台上创建文件配置，下发到部署组。
动态替换 PHP 文件
- 通过控制台发布一个 PHP 文件到指定目录，来达到动态替换服务器上 PHP 文件的目的。

6.3 文件配置操作步骤

文件配置的使用步骤：

6.3.1 新建配置

步骤一：
- 新建配置：
具体操作步骤：
- 登录 TSF 控制台。
- 在左侧导航栏中，单击【配置管理】>【文件配置】。
- 在文件配置页面，单击【新建】按钮。

6.3.2 填写配置信息

步骤二：
- 填写配置信息：
文件配置信息
- 配置名称
- 关联应用
- 文件保存编码
- 配置内容：支持上传文件或者控制台编辑
- 配置文件名称：下发到服务器的配置文件的文件名称
- 版本号
- 版本描述

6.3.3 配置下发路径信息以及后置脚本

步骤三：
- 配置下发路径信息以及后置脚本：

配置下发路径：配置下发到服务器的路径
后置脚本（选填）：配置下发到服务器后执行的命令（不需要包含 #! /bin/bash)
点击“完成”后就可以完成文件配置的创建功能，可以登录到具体服务目录下进行查看验证。

6.4 文件配置基本操作说明

基本操作包含：
1. 生成新版本
  - 在配置列表页，单击配置名称进入详情页。
  - 单击某个配置版本旁的【生成新版本】按钮。
  - 填写变更的新版本的配置内容和版本号。
  - 单击【完成】按钮。
2. 发布配置
  - 在配置列表页，单击配置名称进入详情页。
  - 单击某个配置版本旁的【发布】按钮。
  - 选择配置发布的目标部署组，填写发布描述。
  - 单击【提交】。
3. 查看配置发布历史
  - 在文件配置页，单击配置发布历史标签页。
  - 选择目标部署组，单击【查询】。
4. 配置回滚
  - 在文件配置页，单击配置发布历史标签页。
  - 单击配置发布历史列表右侧的【回滚】按钮。
  - 填写回滚说明，单击【提交】。

思考题

TSF配置管理的方式有哪几种？
TSF配置的优先级是怎么样的？

教程

TSF 微服务

本博客所有文章除特别声明外，均采用 CC BY-SA 4.0 协议，转载请注明出处！

十一、TSF与API网关上一篇

九、TSF服务治理下一篇

十、TSF配置管理

十、TSF配置管理

学习目标

第一章 配置管理概述

1.1 配置管理概述

1.2 配置管理分类

第二章 应用配置

2.1 使用方式-使用流程

2.1.1 添加依赖

2.1.2 引用配置

2.1.2 引用配置（续）

2.1.2 引用配置(续）

2.1.3 配置内容填写

2.1.4 发布配置

2.2 应用配置管理的功能

2.2.1 应用配置管理的功能

2.3 配置优先级

第三章 全局配置

3.1 全局配置概述

3.1 全局配置概述（续）

第四章 配置回调

4.1 配置回调使用场景

4.2 使用方式-配置回调

第五章 配置模板

5.1 配置模板概述

5.2 新建和使用配置模板

5.2 新建和使用配置模板（续）

第六章 文件配置

6.1 文件配置概述

6.1 文件配置概述（续）

6.2 文件配置使用场景

6.3 文件配置操作步骤

6.3.1 新建配置

6.3.2 填写配置信息

6.3.3 配置下发路径信息以及后置脚本

6.4 文件配置基本操作说明

思考题

第一章配置管理概述

第二章应用配置

第三章全局配置

第四章配置回调

第五章配置模板

第六章文件配置