本节介绍了通过配置管理降低配置变更风险的实践方法。

组织配置

ACM 提供了 dataId、group、app、namespace 等四个维度来帮助管理配置。勤于梳理且善用这些维度，能减少在配置管理过程中发生失误，提高系统稳定性。

  • 配置组织方式

    • dataId

      • 用来表示一组相关的 key=value 的配置项的集合。

      • 规范 dataId 命名，例如： com.company.trade.threadpool.params，trade.p1.props。

    • group

      一般使用模块名或者云资源名。若一个应用使用了 Nginx，SLB， 此处 group 命名即 nginx，slb。

    • app

      应用分组，一般是一个简单的业务单元或者微服务分组，由一个小型或中型团队开发和维护。

    • namespace

      粗粒度隔离多个应用的配置，例如多环境。

  • 配置影响分级

    每个配置项的变更对系统的影响均不同。例如：日志级别的变更出现错误，会改变系统的日志量，此外一般不会有其它负面的影响。而连接池、线程池、限流阈值、主机配置等的变更往往是一个 Server 级别或者一个应用服务集群级别的影响。

    分布式系统如全局路由规则、负载均衡策略、网络配置等是重量级的配置，错误的变更往往会带来严重的后果。因此需要按照配置影响力，将配置等级分为 P0~P4。

    以下是示例说明。

    级别 影响力 例子
    P0 全网 全局路由规则，网络配置，负载均衡配置
    P1 应用集群 集群限流阈值，集群服务端点
    P2 主机级别关键配置 主机资源配置，线程池大小
    P3 进程级别非关键配置 日志级别
    P4 无关紧要的配置 版本信息

  • 避免配置项集中于一个文件

    若将应用的所有配置项都放在一个配置里，则意味着所有的人都在一个配置集上修改，这将导致配置变更、推送变得相对频繁，且增加了互相冲突以及误操作的风险，不利于更好的配置授权和分级的变更流程管控。

  • 重要配置变更使用灰度发布

    重要的配置（如 P0、P1 级）需设置变更审核、灰度等发布策略来降低变更风险。

确保配置安全

敏感配置信息请加密后存储在 ACM 里

ACM Server 的主机和配置存储中默认不做数据加密处理。对于一些敏感配置信息，如密码、Token、AccessKey 等信息，必须加密后才可以存储在 ACM 里。

ACM 的 API 和控制台均有提供配置信息加密工具，帮助您将信息加密之后再存储到 ACM 里。