第20章配置管理架构

课程目录第20章配置管理架构

20、配置管理架构：配置文件解析、动态配置、热加载

做嵌入式开发久了，你会发现一个规律：凡是写死在代码里的参数，最后都得改。

我刚入行那会儿，有个产品已经量产了，客户突然说要调整某个通信超时时间。没办法，只能让现场工程师带着烧录器去升级固件。一个客户倒还好，几十个客户跑下来，团队差点崩溃。从那以后，我养成了一个习惯——凡是可能变的参数，一律放到配置文件里。

今天我们就聊聊配置管理架构。说白了，就是怎么让程序更灵活，不用改代码就能调整行为。

为什么需要配置管理？

你想想看，一个嵌入式系统要面对的场景有多复杂：

不同硬件版本，GPIO引脚可能不一样
不同客户，通信参数、阈值可能不同
现场调试时，需要临时调整日志级别
系统升级后，某些参数需要平滑迁移

如果这些全靠改代码、重新编译、重新烧录……嗯，那运维成本就太高了。

核心思想：将可变参数从代码中剥离，放到外部存储（文件、Flash、EEPROM等），程序启动时读取，运行时可以动态修改。

配置文件解析：从文本到结构体

配置文件最常见的格式就是 key=value 的文本形式。简单、直观、人类可读。

我个人的习惯是，先定义一个配置结构体，把所有参数集中管理：

// config.h
typedef struct {
    uint32_t baudrate;
    uint8_t  parity;
    uint16_t timeout_ms;
    uint8_t  log_level;
    char     server_ip[16];
    uint16_t server_port;
} AppConfig_t;

// 全局配置实例
extern AppConfig_t g_appConfig;

然后写一个解析器，把文本文件转换成这个结构体：

// config_parser.c
#include <stdio.h>
#include <string.h>
#include <stdlib.h>

#define CONFIG_LINE_MAX 128

static int parse_line(const char* line, AppConfig_t* cfg) {
    char key[64], value[64];
    if (sscanf(line, "%63[^=]=%63s", key, value) != 2) {
        return -1; // 格式错误
    }

    if (strcmp(key, "baudrate") == 0) {
        cfg->baudrate = atoi(value);
    } else if (strcmp(key, "parity") == 0) {
        cfg->parity = atoi(value);
    } else if (strcmp(key, "timeout_ms") == 0) {
        cfg->timeout_ms = atoi(value);
    } else if (strcmp(key, "log_level") == 0) {
        cfg->log_level = atoi(value);
    } else if (strcmp(key, "server_ip") == 0) {
        strncpy(cfg->server_ip, value, sizeof(cfg->server_ip) - 1);
    } else if (strcmp(key, "server_port") == 0) {
        cfg->server_port = atoi(value);
    }
    // 忽略未知字段
    return 0;
}

int load_config(const char* filename, AppConfig_t* cfg) {
    FILE* fp = fopen(filename, "r");
    if (!fp) return -1;

    char line[CONFIG_LINE_MAX];
    while (fgets(line, sizeof(line), fp)) {
        // 跳过空行和注释
        if (line[0] == '\n' || line[0] == '#') continue;
        // 去掉换行符
        line[strcspn(line, "\n")] = '\0';
        parse_line(line, cfg);
    }
    fclose(fp);
    return 0;
}

避坑指南：我曾经在解析时没处理注释行，结果配置文件里写了#开头的说明，程序直接崩溃。后来我加上了跳过注释的逻辑。另外，sscanf的缓冲区大小一定要限制，防止缓冲区溢出。

动态配置：运行时修改参数

配置文件解析只是第一步。更高级的需求是：系统运行时，能不能动态修改参数？

比如，一个网络设备正在运行，我想临时调整它的心跳间隔。如果必须重启才能生效，那就会造成服务中断。

动态配置的实现思路其实不复杂：

提供一个接口（命令行、网络API、按键等）来修改配置
修改后立即生效，同时可以选择是否保存到持久化存储

我一般会设计一个配置管理模块，提供这样的接口：

// config_manager.h
// 返回值：0成功，-1失败
int config_set(const char* key, const char* value);
int config_get(const char* key, char* value, size_t size);
int config_save(void);  // 保存到Flash/文件
int config_reload(void); // 从存储重新加载

实现时要注意线程安全。如果配置被多个任务访问，需要加锁：

// config_manager.c
#include "config_manager.h"
#include <string.h>

static AppConfig_t s_config;
static int s_dirty = 0; // 是否有未保存的修改

// 假设有一个互斥锁
extern void config_lock(void);
extern void config_unlock(void);

int config_set(const char* key, const char* value) {
    config_lock();
    // 解析并更新对应字段
    if (strcmp(key, "timeout_ms") == 0) {
        s_config.timeout_ms = atoi(value);
        s_dirty = 1;
    }
    // ... 其他字段
    config_unlock();
    return 0;
}

int config_save(void) {
    if (!s_dirty) return 0; // 没有修改，无需保存
    // 将s_config写入Flash或文件
    // ...
    s_dirty = 0;
    return 0;
}

注意：动态修改配置时，一定要考虑参数的有效性。我曾经遇到一个案例，运维人员把超时时间设成了0，导致系统一直等待。所以，set接口里最好做范围检查。

热加载：不重启就生效

热加载是动态配置的升级版。它指的是：配置文件被外部修改后，系统能自动感知并重新加载，无需人工干预。

实现方式有两种：

轮询检测：定时检查配置文件的修改时间或校验和
事件通知：使用文件系统的事件机制（如inotify）

在嵌入式环境里，轮询更常见，因为很多RTOS不支持事件通知。我一般这样实现：

// hot_reload.c
#include <stdio.h>
#include <sys/stat.h>

static time_t s_last_mtime = 0;
static const char* s_config_path = "/flash/config.ini";

int check_config_update(void) {
    struct stat st;
    if (stat(s_config_path, &st) != 0) {
        return -1; // 文件不存在
    }

    if (st.st_mtime != s_last_mtime) {
        s_last_mtime = st.st_mtime;
        return 1; // 文件已更新
    }
    return 0; // 无变化
}

// 在主循环中调用
void main_loop(void) {
    while (1) {
        if (check_config_update() == 1) {
            printf("[Config] 检测到配置文件更新，重新加载...\n");
            load_config(s_config_path, &g_appConfig);
            // 通知其他模块配置已变更
            notify_config_changed();
        }
        // ... 其他任务
        sleep(1);
    }
}

我的经验：热加载虽然方便，但要注意“原子性”。如果配置文件很大，写入一半时系统断电，下次启动时读到的是不完整的配置。我一般会写一个临时文件，写入成功后再重命名覆盖原文件。这样要么全更新，要么不更新。

整体架构图

下面这张图展示了配置管理模块在整个系统中的位置和交互关系：

总结一下

配置管理架构，说白了就是三件事：

解析：把文本配置变成程序能用的结构体
动态：运行时能改，不用重启
热加载：文件改了，程序自动感知

我在实际项目中，一般会把这套机制做成一个独立的模块，所有业务代码都通过这个模块读取配置。这样，配置的存储方式（文件、Flash、KV存储）可以随时切换，业务代码完全不受影响。

嗯，最后提醒一句：配置管理虽好，但别滥用。只有那些确实需要灵活调整的参数才放到配置文件里。核心算法、关键逻辑，还是老老实实写在代码里吧。

📚 课程目录

20、配置管理架构：配置文件解析、动态配置、热加载

为什么需要配置管理？

配置文件解析：从文本到结构体

动态配置：运行时修改参数

热加载：不重启就生效

整体架构图

总结一下