跳到主要内容
版本：3.0.0

配置

大多数项目在配置这块，先把边界分清就够了：

  • 配置平时放哪
  • 什么情况下本地配置就够了
  • 什么时候再接配置中心

先把边界分清​

在 Aegis 里，常见的配置分成两层：

层级解决什么问题对应组件
本地配置应用怎么读配置Aegis.Configuration
配置中心配置还能从哪里来Aegis.Configuration.ConfigCenter

先按这个理解就够：

  • Aegis.Configuration 管“怎么读”
  • ConfigCenter 管“从哪读”

大多数项目起步只用本地配置​

如果你只是做一个普通业务项目，或者先想把第一版跑通，本地配置通常就够了。

常见做法就是：

  • 主配置写在 appsettings.json
  • 需要拆分时配 LoadConfigurations
  • 代码里统一用 ConfigManager

例如：

{
  "LoadConfigurations": [
    "Configs/"
  ],
  "SqlConnection": "Host=127.0.0.1;Database=aegis_db;Port=5432;Username=postgres;Password=pass"
}

代码里这样读：

var sqlConnection = ConfigManager.Get("SqlConnection");
var redisOptions = ConfigManager.Get<RedisOptions>("Redis");
var databases = ConfigManager.GetArray<DatabaseConfig>("Databases");

什么时候再接配置中心​

一般到了下面这些场景，再考虑配置中心：

  • 环境多了，配置差异越来越大
  • 有些配置想集中管理
  • 多个服务要复用同一份配置

这时再接 Aegis.Configuration.ConfigCenter 会比较合适。

appsettings.json 里通常放什么​

对一个普通业务项目来说，下面这些最常见：

  • 数据库连接
  • Redis 配置
  • Swagger 配置
  • 日志级别
  • 业务配置入口

多环境配置文件​

Aegis 基于 ASP.NET Core 标准机制，支持按环境加载不同的配置文件。框架启动时会自动根据当前环境变量加载对应的 appsettings.{Environment}.json，并覆盖 appsettings.json 中的同名节点。

环境变量通过 ASPNETCORE_ENVIRONMENT（或 DOTNET_ENVIRONMENT）设置：

设置方式命令
启动参数dotnet run --environment Production
环境变量export ASPNETCORE_ENVIRONMENT=Production
launchSettings.json"environmentVariables": { "ASPNETCORE_ENVIRONMENT": "Development" }

文件加载规则：

appsettings.json                <- 所有环境都会加载
appsettings.Development.json    <- Development 环境额外加载，覆盖同名节点
appsettings.Production.json     <- Production 环境额外加载，覆盖同名节点

例如，appsettings.json 中配置了开发环境的数据库连接串，appsettings.Production.json 中只需要写生产环境的覆盖值：

// appsettings.Production.json
{
  "SqlConnection": "Host=prod-db.example.com;Database=aegis_db;Port=5432;Username=prod_user;Password=***"
}

不需要把 appsettings.json 的所有内容复制一遍，只写需要覆盖的节点即可。

ComponentDeps 和 LoadConfigurations 中的 {Environment} 占位符也使用同一个环境变量值。

Component.deps.json 和 appsettings.json 别写混了​

这个地方很容易写混：

  • appsettings.json 放运行配置
  • Component.deps.json 放组件装配

例如：

  • 数据库连接串放 appsettings.json
  • Logging / Swagger / BusinessServices 这些组件开关放 Component.deps.json

不同环境使用不同组件配置​

如果开发、测试、生产环境需要加载不同的组件，可以通过 appsettings.json 中的 ComponentDeps 节点指定按环境区分的文件名：

{
  "ComponentDeps": "Component.deps.{Environment}.json"
}

框架会根据当前环境变量（ASPNETCORE_ENVIRONMENT）自动替换 {Environment}，加载对应的文件（如 Component.deps.Development.json）。如果指定文件不存在，会回退使用默认的 Component.deps.json。

LoadConfigurations 中的路径也支持同样的 {Environment} 占位符。可以用在文件名中，也可以用在目录路径中：

{
  "LoadConfigurations": [
    "Configs/",
    "BizConfigs/BizConfig{Environment}.json"
  ]
}

或者按目录区分：

{
  "LoadConfigurations": [
    "Configs/{Environment}/"
  ]
}

目录方式会在运行时解析为 Configs/Development/、Configs/Production/ 等，框架自动扫描目录下所有 *.json 文件。

接配置中心时，一般怎么配​

如果你们已经用配置中心，最少通常要准备这几个信息：

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

接进来以后，业务代码的读取方式通常不用改，还是走 ConfigManager。

怎么判断配置链路通了​

起步阶段，先看下面几项：

  • ConfigManager.Get(...) 能读到主配置
  • ConfigManager.Get<T>() 能正常绑定对象
  • LoadConfigurations 里的附加配置能读到
  • 依赖配置的组件启动时没有报错

如果你们用了配置中心，再加一条：

  • 远端配置在启动后能正常读取

继续看哪里​