版本：3.0.0

配置中心扩展（Aegis.Configuration.ConfigCenter）

当本地 appsettings.json 和附加 JSON 文件已经不足以支撑部署环境差异、集中维护或跨服务共享配置时，可以在基础配置能力之上接入 Aegis.Configuration.ConfigCenter。它的职责不是替代 ConfigManager，而是把远端配置并入现有配置树，让业务和组件仍然沿用同一套读取方式。

组件概览

字段	说明
组件名称	配置中心扩展
真实类库	`Aegis.Configuration.ConfigCenter`
组件定位	把远端配置中心接入当前配置体系
父级组件	`Aegis.Configuration`
引入方式	`Component.deps.json`
组件声明	`ConfigCenter`
核心能力	启动时拉取远端配置、并入统一配置树、继续通过 `ConfigManager` 读取
是否可扩展	是
注册入口	`ConfigCenter` / `AddMetaOsConfigCenter`
中间件阶段	无实际中间件逻辑

这个组件是配置底座上的扩展层，而不是独立配置体系。接入后，业务方不需要改成另一套读取方式，仍然使用 ConfigManager 即可。它属于服务注册阶段能力，组件顺序会影响后续组件能否读到远端配置。

如何引入

NuGet 包

角色	NuGet 包	是否必需	说明
基础层	`Aegis.Configuration`	是	提供统一配置读取底座
扩展层	`Aegis.Configuration.ConfigCenter`	是	把远端配置并入当前配置树

`Component.deps.json`

ConfigCenter 只需要出现在 Services 中，不需要写进 Middlewares：

{
  "Components": {
    "Services": [
      "ConfigCenter",
      "Logging",
      "Swagger"
    ],
    "Middlewares": [
      "Swagger"
    ]
  }
}

其中：

ConfigCenter：把远端配置源并入当前 ConfigurationManager
其他组件：继续按正常方式读取配置

推荐把 ConfigCenter 尽量放在 Services 列表靠前的位置。这样后续组件在注册服务时，就更容易直接读到远端配置，而不是只读到本地配置。

配置说明

接入配置中心前，仍然需要在本地配置里提供 SettingCenter 节点：

节点	类型	是否必填	说明	常见取值 / 示例
`SettingCenter:NetLocal`	string	是	配置中心服务地址	`https://config.example.com/`
`SettingCenter:Namespace`	string	是	配置所属命名空间	`dev`
`SettingCenter:Application`	string	是	当前应用标识	`Aegis`
`SettingCenter:Config`	`string[]`	是	需要读取的配置集合	`["AppConfig", "SysConfig"]`
`SettingCenter:StoragePath`	string	建议是	本地缓存目录	`/data/config-cache`

最小示例：

{
  "SettingCenter": {
    "NetLocal": "https://config.example.com/",
    "Namespace": "dev",
    "Application": "Aegis",
    "Config": [
      "AppConfig",
      "SysConfig"
    ],
    "StoragePath": "/data/config-cache"
  }
}

快速使用

第一步：保留基础配置能力

先确保你的应用仍然通过标准宿主启动，或者已经显式初始化了基础配置能力。ConfigCenter 是在此基础上追加的，不是替代关系。

第二步：在本地配置里准备 `SettingCenter`

{
  "SettingCenter": {
    "NetLocal": "https://config.example.com/",
    "Namespace": "dev",
    "Application": "Aegis",
    "Config": [
      "AppConfig",
      "SysConfig"
    ],
    "StoragePath": "/data/config-cache"
  }
}

第三步：在 `Component.deps.json` 中加入 `ConfigCenter`

{
  "Components": {
    "Services": [
      "ConfigCenter",
      "Logging",
      "Swagger"
    ],
    "Middlewares": [
      "Swagger"
    ]
  }
}

第四步：按原方式读取配置

var sqlConnection = ConfigManager.Get("SqlConnection");
var redisOptions = ConfigManager.GetSection("Redis");
var settingCenter = ConfigManager.Get<SettingCenter>();

接入正确时，你应该能看到这些结果：

应用启动后，远端配置会被并入当前配置树
业务代码仍然使用 ConfigManager 读取配置
依赖配置的后续组件可以直接读取到需要的节点
不需要新增任何中间件配置

具体使用详情

工作方式

当前配置中心扩展会在服务注册阶段把远端配置源加入 ConfigurationManager。之后：

先读取本地 SettingCenter
根据应用标识和配置集合去拉取远端配置
把拉回来的键值并入统一配置树
业务方继续通过 ConfigManager 读取

这意味着本地配置并不会消失。至少 SettingCenter 这类启动配置仍然要保留在本地。

下面是一个更完整的本地启动配置示例：

{
  "SettingCenter": {
    "NetLocal": "https://config.example.com/",
    "Namespace": "dev",
    "Application": "Aegis",
    "Config": [
      "AppConfig",
      "SysConfig"
    ],
    "StoragePath": "/data/config-cache"
  },
  "LoadConfigurations": [
    "Configs/"
  ]
}

public class SettingCenter
{
    public string NetLocal { get; set; }
    public string Namespace { get; set; }
    public string Application { get; set; }
    public string[] Config { get; set; }
    public string StoragePath { get; set; }
}

适合的使用场景

这类扩展比较适合：

多环境部署，需要集中管理配置
多个服务共享一组配置约定
希望把连接串、开关或业务参数从本地文件迁出

接入完成后，业务代码里的读取方式不需要变化，例如：

var sqlConnection = ConfigManager.Get("SqlConnection");
var redisOptions = ConfigManager.Get<RedisOptions>("Redis");
var featureToggle = ConfigManager.Get<bool>("Features:EnableReportExport");

当前边界

当前实现更适合“启动时加载配置”的场景。接入时建议按下面思路理解：

它是配置源扩展，不是配置读取 API
它没有额外的中间件链路
它更适合启动阶段加载，而不是把它理解成实时热更新机制

如果你的业务对配置实时刷新要求很高，应先在项目里验证这部分行为是否满足预期，再决定是否作为主方案。

如何扩展

与本地 JSON 叠加使用

最常见的扩展方式不是替换本地 JSON，而是把两者叠加：

本地配置负责启动必需项和兜底值
远端配置负责环境差异和集中管理

这种组合方式通常更稳，也更容易排障。

{
  "SettingCenter": {
    "NetLocal": "https://config.example.com/",
    "Namespace": "prod",
    "Application": "Aegis",
    "Config": [
      "AppConfig"
    ],
    "StoragePath": "/data/config-cache"
  },
  "Redis": {
    "ConnectionString": "127.0.0.1:6379"
  }
}

这种写法里：

本地配置负责把配置中心启动起来
本地也可以保留少量兜底配置
业务代码最终仍然统一从 ConfigManager 读取

让其他组件直接消费远端配置

如果某些组件在注册服务阶段就需要读取远端配置，请把 ConfigCenter 放在 Services 列表靠前位置。这样配置先并入，后续组件再读取，整体行为更可控。

继续沿用类型化配置

即使配置来自远端，业务代码仍然可以继续使用：

ConfigManager.Get<T>()
ConfigManager.Get<T>(string key)
ConfigManager.GetArray<T>(string key)

也就是说，配置来源变了，但应用层的读取习惯不需要跟着改变。

常见问题指南

为什么已经加了 `ConfigCenter`，配置还是没生效？

优先检查三件事：

本地 SettingCenter 是否完整
ConfigCenter 是否已经写入 Services
它在 Services 中的位置是否足够靠前

为什么 `ConfigCenter` 不需要写进 `Middlewares`？

因为它没有实际的请求处理中间件逻辑，主要工作都发生在服务注册阶段。

为什么接了配置中心后，代码里还是继续用 `ConfigManager`？

因为 ConfigCenter 的职责是扩展配置来源，不是替换读取 API。对使用者来说，最理想的状态就是“配置来源变复杂了，但读取方式不变”。

组件概览​

如何引入​

NuGet 包​

Component.deps.json​

配置说明​

快速使用​

第一步：保留基础配置能力​

第二步：在本地配置里准备 SettingCenter​

第三步：在 Component.deps.json 中加入 ConfigCenter​

第四步：按原方式读取配置​

具体使用详情​

工作方式​

适合的使用场景​

当前边界​

如何扩展​

与本地 JSON 叠加使用​

让其他组件直接消费远端配置​

继续沿用类型化配置​

常见问题指南​

为什么已经加了 ConfigCenter，配置还是没生效？​

为什么 ConfigCenter 不需要写进 Middlewares？​

为什么接了配置中心后，代码里还是继续用 ConfigManager？​