如何以规范的配置命名格式来进行限流设置_应用配置管理（文档停止维护）-阿里云帮助中心

迁移到MSE Nacos

ACM进入下线状态，所有配置管理相关的需求由MSE中的Nacos承接（ACM独享版，更好的安全和稳定性）。您需要在ACM控制台导出配置，然后在MSE控制台导入之前导出的配置即可完成迁移。具体操作，请参见将应用配置从ACM迁移到MSE Nacos。

如果是单一应用的单一属性配置，使用以下配置文件即可完成，没有配置规范的问题。

//配置目录结构
--app
   |--src
      |--config
         |--application.properties
//配置内容
RCV_INTERVAL_TIME=20

但是，如果是为分布式 PaaS 服务编写分布式规则，PaaS 服务提供方（而非应用方）在设计配置时会遇到许多问题。以 MQ 限流场景为例，可能遇到的问题有：

以上 MQ 限流场景需求如图所示。

显然，不恰当的配置命名规范将影响以上配置的易用性。

下文详细介绍了以规范的配置命名格式来进行限流设置的方法。为了说明配置命名规范，首先需要介绍配置中心的配置结构组织的能力。

除了集中管理配置和订阅推送等能力，配置中心还具备配置结构化能力，能帮助管理员大幅简化各种复杂应用场景下的配置管理。

1. 配置中心的配置结构能力说明

租户隔离：配置中心根据用户或场景对配置进行隔离。使用租户隔离，不同的配置在不同的租户可以重名，且具有不同的鉴权机制。
最小配置集合：若干配置通过配置中心组合成一个配置集合。使用最小配置集合来更改和发布不同配置，可实现统一发布和统一处理。配置路径的概念类似于文件路径或者网络域名，它让不同配置集合之间具有层级关系。
具体配置的 Key-Value 形式：在配置中心中设置具体配置内容。

2. 配置中心配置结构能力产品比较

为了更直观地说明，我们对比了几个配置中心产品：

阿里云 ACM：阿里云应用配置管理，前身为 Diamond，是中国最早的配置中心产品。目前在 Git 上有不同开源版本，在阿里云上有商业版可供使用。
Spring Cloud Config：Spring Cloud 官方配置中心工具，主要用于 Java Spring 领域。
ZooKeeper：虽然具备部分配置中心能力，但是由于定位于分布式协调信息管理，因此只适合在应用规模不大的情况下用作配置中心。鉴于其使用广泛，此处也将其纳入对比范围。

对比详情如下：


功能	ACM	Spring Cloud Config	ZooKeeper
租户级隔离	采用 Namespace 和 Group 双重隔离，其中不同 Namespace 需要不同 AK/SK 鉴权，Group 则不需要。	一个 Git 项目为一个租户。	没有直接可用的租户隔离技术。
最小配置集合	以 DataID 为标识的配置集为最小配置集合。配置集合没有路径概念，但是通过合理设计结合通配符查询，可以实现间接配置路径的目标。	Git 项目中的配置文件为最小配置集合，没有配置路径概念。	Znode 为最小配置集合，有配置路径概念。
配置 Key-Value	KV 内容由用户在 DataID 下自由组装，格式不限，可以是 properties、JSON、XML 等，管理页面提供校验功能。	通过 Git 项目中 properties 形式的配置文件设置 KV。	通过设置 Znode 的 Value来设置 KV，内容格式无限制。

综上所述，ACM 在租户隔离和最小配置集合方面都有较大的灵活性。下文介绍如何利用 ACM 的 Namespace、Group、DataID 等配置功能来设计一个用于执行 QoS限流策略的合理配置结构。

1. 配置结构

为了满足 MQ 配置的功能需求，结合 ACM 的特点，可采用以下配置方法。

以不同 Namespace 隔离不同环境的 MQ 配置。例如：
- ProdEnv 命名空间用于生产环境，TestEnv 用于测试环境，DevEnv 用于开发环境。
- 不同环境通过 AK/SK 天然隔离，安全性进一步加强。
用 Group 来区分不同集群提供的 MQ 服务，可以达到隔离配置和简化访问形式的效果。
- 例如，对于专门为子部门的核心交易部门服务的 MQ 集群，和为子部门的交易类目部门服务的 MQ 集群，可通过 Group 区分不同的全局配置。这种方法使所有应用采用同一（子）公司的 AK/SK（或类似认证体系密钥），因而简化了部署，有效隔离了不同集群的配置，降低了配置复杂性。
```
DataID: mq.global.qos
Group: Trading

DataID: mq.global.qos
Group: ProductCategory
```
全局配置以全局统一 DataID 命名配置项存放。
- 其中，配置 ID 以 mq 开头，global 表示全局配置，QoS 表示 QoS 方面的配置，Group 可使用默认值。
```
DataID: mq.global.qos
Group: Default_Group
```
应用局部配置以相同后缀 .qos 来命名 ID。
- 配置 ID 以 mq 开头，app.[appname] 表示需要重载的 app 配置项，Group 可使用默认值。
```
DataID: mq.app.app1.qos
Group: Default_Group
DataID: mq.app.app2.qos
Group: Default_Group
```

3. 配置具体 KV 的设置

在很多配置中心产品（例如 Appolo、ACM System Manager Parameter Store）中，每个具体的配置是配置中心最小粒度的管理单元，用户需要在某个粒度上逐一设置配置的 KV，但是 ACM 并没有该限制。常用做法有两种：

仿照以上配置中心，将每个 Key 存在一个独特的 DataID上，例如：
- mq.global.qos.RCV_INTERVAL_TIME 设置为 50
- mq.global.qos.MAX_THREAD 设置为 20
将常用配置聚合成一个 DataID，并编辑为一个配置文件（格式不限，例如 Properties、JSON、XML 等）
- 例如 mq.global.qos 设置如下：
```
//MQ 限流 QoS设置
RCV_INTERVAL_TIME = 50
MAX_THREAD = 20
```

在实践中发现第二种方法不但具有更大的灵活性，而且支持多个配置在一次变更中同时发布，既降低了性能开销，理论上也达到了变更批量变化的原子操作效果。

4. 配置结构示意图

以上设计的配置结构示意图如下：

5. 方案优点总结

通过 Namespace 隔离不同环境，使 MQ 配置项在不同 Namespace 可重复。不同 Namespace 通过管理人员、程序 AK/SK 等权限设置得到隔离保护，达到配置项统一且各个环境互不干扰的效果。
通过 Group 隔离相同环境的不同集群，既能保证不同集群下配置的统一性（如配置名不变等），使代码更加简单，又能在逻辑上隔离不同的集群配置。
通过最小配置集 DataID 的规范命名设置，各 MQ 客户端即可方便地查找 MQ Default 全局配置和应用特殊配置。此外，在配置列表页面上，管理员可通过在关键字两端各加一个星号（*），方便地找出所有 MQ 规则。示例如下：