动态配置
概述
动态配置指的是 Aidy Gateway 加载的路由配置。与修改后需要重启才能生效的静态配置不同，动态配置会自动监听配置的变化，并实时应用。
配置修改的应用会存在一个 Debounce 窗口（默认为 5s，可通过 --config-debounce 参数配置）。可参考此文章描述的 debounce(immediate=false) 的行为，因此，在连续修改配置的情况下配置应用会有所延迟。
例如，启动时指定 --config-debounce=30s 可将 debounce 时间设置为 30 秒。
配置的本质都是 protobuf 格式 —— 定义于 config.Config ，Proto 文件为 https://git.tophant.com/scc/aidy/blob/master/pkg/models/protomodels/protos/tophant/aidy/gateway/config/config.proto 。
为了方便最终用户使用、上下游监控，Aidy Gateway Dynamic Config Loader 同时支持加载 protobuf 所对应的 ProtoJSON 格式，并进一步支持由该 json 衍生的其他变体（如 yaml）。具体由 conent-type 进行区分。
| 配置格式 | Content-Type | 备注 |
|---|---|---|
| Protobuf | application/protobuf | 默认格式，protobuf 二进制格式 |
| ProtoJSON | application/protobuf+json | ProtoJSON 格式 |
| YAML | application/yaml | ProtoJSON 所对应的 YAML 格式 |
当传递配置时，注意需要同时传递配置内容和对应的 content-type。
配置源
本地文件
在启动时指定 --config-file 即代表使用本地文件作为 Dynamic Config Source（如 --config-file=./config.json）。
当使用本地文件时，将自动基于配置文件扩展名计算 content-type，支持的扩展名包括：
.bin/.pb:application/protobuf.json:application/protobuf+json.yaml/.yml:application/yaml
当使用本地文件作为配置源时，Aidy Gateway 会自动利用 inotify 或 fanotify 监控文件变化，并自动应用变更。
请注意，当使用 Docker 运行 Aidy Gateway 且只挂载了配置文件（而不是配置文件所在的目录）时，Docker 挂载文件实际是挂载了容器启动时该路径对应的 inode。而在利用某些文本编辑工具（如 vim）编辑配置文件时，其并未真实修改原文件而是创建了一个新的文件+替换原有文件，会导致该修改后的文件实际并未挂载入容器中，导致配置变更无法重载。
作为一个特殊的优化，当 Aidy Gateway 启动时，如果配置文件不存在，程序不会报错且不会创建对应的配置文件，而是仅打印「配置文件不存在」的警告。但是需要注意，为了使得 inotify 能够监控到配置文件的变化，配置文件所在的目录必须存在（否则会在启动时报错）。
Redis (v1)
在启动时指定 --config-redis 即代表使用 Redis 作为 Dynamic Config Source（如 --config-redis=redis://localhost:6379/0?key=aidy-gateway-config）。
使用 Redis 作为配置源时，Aidy Gateway 会从 aidy-gateway-config hash 中读取配置（该 key 可由 --config-redis-key 参数 uri 中的 key query param 指定）。
aidy-gateway-config 的类型应当为 hash，并存在 content-type 和 config 两个 field。
当 Aidy Gateway 启动时
- 如果对应的 Redis 无法连接，会报错退出
- 作为一个特殊的优化，当配置的 key 不存在时，程序不会报错，而是仅打印「配置 key 不存在」的警告（当后面该 key 出现时，会自动加载对应的配置）。
- 如果配置的 key 存在，但是其不存在
content-type或configfield，会报错退出
对于 Redis 配置，Aidy Gateway 会自动利用 Redis Keyspace Notifications 能力监控变化。该机制默认不开启，因此需要修改 redis.conf 的 notify-keyspace-events 配置，建议至少开启 Ksh。
Redis (v2)
为了更好的适配 SaaS 等海量路由场景，Aidy Gateway 在 v1.3.0 起增加了 Redis V2 作为动态配置源。具体请参考 动态配置 (Redis V2)。
配置说明
配置入口为 config.Config，其由 routes 和 global_plugin_config 定义。前者定义了路由配置，后者定义了插件的全局配置
global_plugin_config
从 v1.3.0 起，global_plugin_config 的绝大多数内容已迁移为「静态配置」，请在启动时通过 -c config.toml 提供全局插件配置；
动态配置中的该字段仅保留以下两个布尔开关：
log.log_unknown_routeslog.log_unauthenticated_routes
其他字段在动态配置中将被忽略。
global_plugin_config 定义了插件的全局配置，主要包括插件所需的上游服务地址。部分配置也可看作路由的插件配置的默认值，路由级别的插件配置可以覆盖
routes
routes 是一个路由 Route 的数组，代表了 Aidy Gateway 需要代理的路由。具体请参考 Route。
获取配置重载状态
暂不支持
但可以通过在更新配置时修改 hash 字段来跟踪配置变化，配置更新以后 Aidy Gateway 会在命令行打印应用的配置 Hash，同时也可查看 Data Dir 下的 current-config.json 文件，该文件包含了当前正在运行的配置。
配置合法性验证
当配置无效（包括：加载失败、内容缺失、解析失败或验证失败）时，Aidy 会清空当前生效的配置，导致所有请求返回 503（Service Unavailable），直到新的有效配置被加载为止。
为避免错误的配置影响业务，建议在将配置传递给 Aidy 前先进行合法性验证，并仅将通过验证的配置传递给 Aidy。
方案一：利用 protovalidate 进行合法性验证
Aidy 目前已移除所有利用代码实现的自定义验证逻辑而转为将验证逻辑直接以 CEL 的形式写入 proto 文件中。因此，通过了 protovalidate 验证的配置即代表通过了 Aidy 的验证。
方案二：利用 Aidy 的 Management API 进行合法性验证
Aidy 的 Management API 提供了 POST /config/validate 端点用于验证配置是否合法。该端点会返回配置有效性与所有验证错误的列表。