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

组织配置

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 里。