第12章配置管理的重构

课程目录第12章配置管理的重构

12、配置管理的重构：从硬编码到配置文件、使用libconfig/json-c、运行时配置热加载

说实话，我见过太多C语言项目，配置全写在代码里。

改个IP地址要重新编译，调个超时时间要发版本。这种日子，我过了好几年。直到有一次线上事故——就因为改了个端口号，编译时漏了头文件，整个服务挂了半小时。从那以后，我对硬编码深恶痛绝。

12.1 硬编码的痛点

先看看典型的硬编码长什么样：

#define SERVER_IP   "192.168.1.100"
#define SERVER_PORT 8080
#define TIMEOUT_MS  5000
#define MAX_CLIENTS 100

这种写法有什么问题？我列几个你品品：

改配置 = 改代码：每次调整都要走完整的编译-测试-发布流程
环境隔离难：开发、测试、生产环境参数不同，你得维护多套头文件
运行时调整不可能：系统跑着跑着发现超时太短？对不起，重启吧
安全风险：数据库密码、API密钥全在代码里，代码泄露等于密码泄露

核心原则：代码和配置分离。代码负责逻辑，配置负责参数。两者不该耦合在一起。

12.2 配置文件格式选型

选配置文件格式，我个人习惯看三个维度：可读性、解析库成熟度、嵌套表达能力。

格式	优点	缺点	推荐场景
INI	简单、人类可读	不支持嵌套、无类型	小型工具、嵌入式
JSON	通用、支持嵌套、库多	没有注释（标准JSON）	Web服务、通用场景
libconfig	支持注释、类型安全、C友好	生态不如JSON	C/C++项目、嵌入式
YAML	可读性极强	解析库复杂、缩进敏感	大型配置、K8s生态

我个人最常用的是 libconfig 和 json-c。前者在嵌入式场景下特别好用，后者在通用服务端更流行。

12.3 使用libconfig实战

libconfig的语法很干净。先看配置文件长什么样：

// config.cfg
server = {
  ip = "0.0.0.0";
  port = 8080;
  backlog = 128;
};

timeout = {
  connect_ms = 5000;
  read_ms = 3000;
  write_ms = 3000;
};

database = {
  host = "localhost";
  port = 3306;
  user = "app_user";
  password = "change_me_in_prod";
  pool_size = 10;
};

读取代码也很直接：

#include <libconfig.h>

config_t cfg;
config_init(&cfg);

if (!config_read_file(&cfg, "config.cfg")) {
    fprintf(stderr, "读取配置失败: %s (行 %d)\n",
            config_error_text(&cfg),
            config_error_line(&cfg));
    config_destroy(&cfg);
    return -1;
}

const char *server_ip;
int server_port;
config_lookup_string(&cfg, "server.ip", &server_ip);
config_lookup_int(&cfg, "server.port", &server_port);

printf("服务启动于 %s:%d\n", server_ip, server_port);

config_destroy(&cfg);

我的习惯：配置读取失败时，不要直接exit。打印清晰的错误信息，包括文件名和行号，方便运维排查。我曾经因为这个细节，帮运维省了半小时定位问题的时间。

12.4 使用json-c实战

JSON格式更通用，尤其适合和Web系统对接。json-c的用法也很简单：

{
  "server": {
    "ip": "0.0.0.0",
    "port": 8080,
    "backlog": 128
  },
  "timeout": {
    "connect_ms": 5000,
    "read_ms": 3000,
    "write_ms": 3000
  },
  "database": {
    "host": "localhost",
    "port": 3306,
    "user": "app_user",
    "password": "change_me_in_prod",
    "pool_size": 10
  }
}

#include <json-c/json.h>

struct json_object *root = json_object_from_file("config.json");
if (!root) {
    fprintf(stderr, "无法解析配置文件\n");
    return -1;
}

struct json_object *server_obj;
json_object_object_get_ex(root, "server", &server_obj);

struct json_object *ip_obj, *port_obj;
json_object_object_get_ex(server_obj, "ip", &ip_obj);
json_object_object_get_ex(server_obj, "port", &port_obj);

const char *ip = json_object_get_string(ip_obj);
int port = json_object_get_int(port_obj);

printf("服务启动于 %s:%d\n", ip, port);

json_object_put(root);  // 释放内存

注意：json-c的json_object_put是引用计数减一。如果你在多个地方引用同一个对象，小心不要提前释放。我曾经踩过这个坑，导致诡异的段错误，查了两天才找到原因。

12.5 运行时配置热加载

热加载是配置管理的进阶玩法。系统不重启，配置就能生效。怎么做？核心思路就四个字：信号驱动。

我常用的模式是这样的：

主线程监听SIGHUP信号
收到信号后，重新读取配置文件
用原子操作或读写锁更新配置
其他线程读取最新配置

看代码：

#include <signal.h>
#include <pthread.h>

volatile sig_atomic_t reload_flag = 0;
pthread_rwlock_t config_lock = PTHREAD_RWLOCK_INITIALIZER;
AppConfig g_config;  // 全局配置

void sig_hup_handler(int signo) {
    reload_flag = 1;  // 设置重载标志
}

void *config_reload_thread(void *arg) {
    while (1) {
        if (reload_flag) {
            reload_flag = 0;
            
            AppConfig new_config;
            if (load_config_from_file("config.cfg", &new_config) == 0) {
                pthread_rwlock_wrlock(&config_lock);
                g_config = new_config;  // 结构体赋值，原子操作
                pthread_rwlock_unlock(&config_lock);
                
                printf("配置已热加载\n");
            } else {
                fprintf(stderr, "配置重载失败，保留旧配置\n");
            }
        }
        sleep(1);  // 每秒检查一次
    }
    return NULL;
}

// 读取配置的封装
AppConfig get_config(void) {
    AppConfig cfg;
    pthread_rwlock_rdlock(&config_lock);
    cfg = g_config;
    pthread_rwlock_unlock(&config_lock);
    return cfg;
}

使用方式：

int main() {
    signal(SIGHUP, sig_hup_handler);
    
    load_config_from_file("config.cfg", &g_config);
    
    pthread_t tid;
    pthread_create(&tid, NULL, config_reload_thread, NULL);
    
    // 主业务逻辑
    while (1) {
        AppConfig cfg = get_config();
        // 使用cfg处理业务...
        sleep(1);
    }
}

关键点：热加载不是银弹。有些配置改了之后，需要重建连接池、重新分配内存。这种情况下，简单的结构体赋值就不够了。我建议在配置变更时，注册回调函数，让各个模块自己处理变更逻辑。

12.6 配置管理的架构图

下面这张图，是我做配置重构时常用的分层结构：

这个架构的好处是：每一层职责清晰，改动不影响其他层。你想换配置格式？只改加载层。你想加远程配置中心？只改配置源层。

12.7 避坑指南

配置重构看着简单，实际坑不少。我分享几个亲身经历：

配置校验不能省：我曾经没做端口范围校验，有人配了-1，结果bind失败，服务起不来。现在我的习惯是：加载配置后，立即做完整性校验，不通过就报错退出。
热加载要考虑一致性：如果配置有多个关联字段（比如host和port），要保证它们同时更新。用结构体整体赋值，不要逐个字段更新。
默认值要合理：配置文件里没写的字段，代码里要有默认值。我见过一个项目，配置里漏了timeout字段，结果程序用未初始化的值，行为完全随机。
敏感信息要隔离：密码、密钥不要明文写在配置文件里。可以用环境变量覆盖，或者用专门的密钥管理服务。

我的建议：配置重构不要一步到位。先做配置文件和代码分离，再考虑热加载。每一步都经过充分测试，再推进下一步。稳扎稳打，比什么都重要。

配置管理这件事，说白了就是「把变化的部分从代码里抽出来」。你想想看，代码里不该有IP地址、端口号、超时时间这些业务参数。它们应该待在配置文件里，让运维去改，让系统去热加载。这才是C语言项目该有的样子。

公众号:蓝海资料掘金营，微信deep3321

📚 课程目录

12、配置管理的重构：从硬编码到配置文件、使用libconfig/json-c、运行时配置热加载

12.1 硬编码的痛点

12.2 配置文件格式选型

12.3 使用libconfig实战

12.4 使用json-c实战

12.5 运行时配置热加载

12.6 配置管理的架构图

12.7 避坑指南