为 Go 服务实现轻量级配置热更新机制

在微服务和云原生时代，配置管理是每个 Go 服务开发者绕不开的话题。从环境变量、配置文件到配置中心，方案层出不穷。但很多时候，我们并不需要引入 etcd、consul 这类重依赖，只是想让服务在本地或单机场景下，修改配置后不用重启进程就能生效。今天我们就来聊聊如何用纯 Go 标准库和少量代码，为服务实现一个轻量级的配置热更新机制。

为什么需要热更新

最常见的痛点是：线上服务跑着，突然发现某个开关的阈值不合理，或者日志级别需要临时调高。如果没有热更新，只能改配置、重新编译（如果配置是内嵌的）、重启服务。重启意味着连接断开、缓存失效、请求抖动，尤其在长连接或定时任务多的服务里，这种代价往往难以接受。

热更新让我们可以把「变更」的代价降到最低。而一个轻量级实现的核心诉求无非三点：不引入外部依赖、变更及时生效、线程安全且无泄漏。

方案一：基于文件监听 + atomic.Value

Go 的标准库 `syscall` 或 `fsnotify` 可以监听文件变化，但 `fsnotify` 属于第三方库。如果不希望任何外部依赖，可以用轮询 + `os.Stat` 或 `time.Ticker` 来做。核心思路是：用一个结构体保存配置，然后用 `atomic.Value` 加载它。每次文件变更时，重新解析配置并 `Store` 新的结构体指针。

我们先定义一个配置结构：

type Config struct {
    Port     int    `json:"port"`
    LogLevel string `json:"log_level"`
    Timeout  time.Duration
}

然后写一个管理配置的 `ConfigManager`：

type ConfigManager struct {
    path string
    val  atomic.Value // 存储 *Config
    m    sync.Mutex   // 防止并发读取文件
}

func NewConfigManager(path string, initial *Config) (*ConfigManager, error) {
    cm := &ConfigManager{path: path}
    cm.val.Store(initial)
    return cm, nil
}

func (cm *ConfigManager) Load() *Config {
    return cm.val.Load().(*Config)
}

核心在 `Reload` 方法，它负责读取文件、解析并更新：

func (cm *ConfigManager) Reload() error {
    cm.m.Lock()
    defer cm.m.Unlock()
    data, err := os.ReadFile(cm.path)
    if err != nil {
        return err
    }
    var cfg Config
    if err := json.Unmarshal(data, &cfg); err != nil {
        return err
    }
    cm.val.Store(&cfg)
    return nil
}

接着使用一个 `time.Ticker` 周期性检查文件修改时间，或者直接调用 `Reload`：

func (cm *ConfigManager) Watch(interval time.Duration, done <-chan struct{}) {
    ticker := time.NewTicker(interval)
    go func() {
        defer ticker.Stop()
        for {
            select {
            case <-ticker.C:
                if err := cm.Reload(); err != nil {
                    log.Printf("[config] reload failed: %v", err)
                }
            case <-done:
                return
            }
        }
    }()
}

使用者只需调用 `cfg := cm.Load()`，获取到的永远是当前最新的配置结构体。因为 `atomic.Value` 保证了指针的原子可见性，无需加锁。

方案二：基于 mtime 的增量检查

上面的轮询每次都会读取整个文件，如果文件较大或读取频繁，稍显浪费。更好的做法是检查文件的 `ModTime` 是否发生变化，只有变化时才真正解析文件。这样可以降低资源占用：

type fileWatcher struct {
    path      string
    lastMod   time.Time
    size      int64
    onChanged func()
}

func (fw *fileWatcher) check() bool {
    info, err := os.Stat(fw.path)
    if err != nil {
        return false
    }
    if !info.ModTime().Equal(fw.lastMod) || info.Size() != fw.size {
        fw.lastMod = info.ModTime()
        fw.size = info.Size()
        return true
    }
    return false
}

然后在 `Watch` 循环中先调用 `check()`，返回 `true` 才执行 `Reload`。这样不仅减少无谓的磁盘读取，还能在配置文件没有变化时保持完全静默。

如何优雅地使用新配置

配置更新后，最大的问题是已经在运行中的逻辑如何处理。比如 HTTP 服务的超时时间、连接池大小，这些在创建时可能已经固化。建议的做法是在每次请求时从 `ConfigManager.Load()` 获取配置，而不是在初始化时拷贝一份。例如：

func (h *Handler) ServeHTTP(w http.ResponseWriter, r *http.Request) {
    cfg := h.cm.Load()
    timeout := cfg.Timeout
    // 使用 timeout 处理请求
}

如果有些组件只能设置一次，例如 `http.Server.ReadTimeout`，那就需要在热更新时额外写一段逻辑去动态调整底层资源。这时可以把 `http.Server` 封装在一个可替换的结构体里，使用同样的 `atomic.Value` 技巧进行整体替换。这实际上从配置热更新变成了组件热替换，实现起来也很有趣，但本文不展开。

别忘了优雅退出

热更新不仅仅是「更新」本身，还涉及旧配置的清理问题。如果你在每次 `Reload` 时创建了新的对象（如新的连接池），那老对象必须被正确关闭，否则会造成 goroutine 泄漏。一个简单的办法是，在配置结构中增加一个 `Close() error` 方法，并在 `Reload` 中先保存旧配置，成功替换后调用旧配置的 `Close`：

func (cm *ConfigManager) Reload() error {
    data, err := os.ReadFile(cm.path)
    // ...
    newCfg := parse(data)
    oldCfg := cm.Load()
    cm.val.Store(newCfg)
    if oldCfg != nil && oldCfg.Close != nil {
        oldCfg.Close()  // 需要保证 Close 不阻塞，且幂等
    }
    return nil
}

但这要小心：如果还有 goroutine 持有旧配置的引用，强制关闭会导致不可预期的问题。稳妥的办法是采用引用计数或延迟回收，不过对于轻量级服务，我们可以约定：配置中的资源都是无状态或可重建的，那这种简单方式就足够。

小结

通过 `atomic.Value`、文件轮询或 mtime 检查，我们就拥有了一个不足百行代码的配置热更新机制。不需要 etcd，也不需要 fsnotify，完全依赖 Go 标准库，就能在大多数单机场景下满足需求。关键在于理解「不可变配置结构 + 原子指针替换」的思想：让配置成为不可变快照，每次更新都是整体替换。这种设计既简单又安全，也容易扩展。当未来真正需要分布式配置中心时，只需替换 `ConfigManager` 的数据源，上层业务代码几乎不用改动。

轻量级工具解决大问题，这才是 Go 社区一贯推崇的哲学。