第15章配置管理

课程目录第15章配置管理

配置管理：环境变量、配置文件、端口配置、日志级别配置

说实话，配置管理这事儿，看着简单，但坑是真不少。我早期做信令服务器的时候，觉得「不就是几个参数嘛，写死在代码里得了」。结果呢？换了个部署环境，改代码、重新编译、再部署，折腾了半小时。后来我学乖了——配置必须外置，这是底线。

今天咱们就聊聊，怎么把信令服务器的配置管理做得既灵活又靠谱。

为什么配置管理这么重要？

你想想看，一个信令服务器，在开发环境、测试环境、生产环境里跑的其实是同一套代码。但端口可能不一样，日志级别可能不一样，甚至信令协议版本都可能不一样。如果每次切换环境都要改代码，那运维同学怕是要提着刀来找你。

配置管理的核心目标就三个：

环境隔离：代码不动，配置切换环境
安全可控：敏感信息（比如密钥）不硬编码
运维友好：改配置不需要重新编译部署

核心原则：代码和配置分离。代码里永远不要出现环境相关的硬编码值。

配置来源：环境变量 vs 配置文件

配置从哪来？主流就两种：环境变量和配置文件。我个人习惯是两者结合用。

环境变量

环境变量的好处是简单、直接、符合12-Factor App规范。尤其适合容器化部署——Docker里传个环境变量，几秒钟搞定。

我在项目中遇到过一个问题：团队里有人把数据库密码直接写在了代码里，结果代码不小心传到了公开仓库。嗯，那场面……后来我们强制要求所有敏感信息必须走环境变量。

// 读取环境变量
const PORT = process.env.PORT || 8080;
const LOG_LEVEL = process.env.LOG_LEVEL || 'info';
const REDIS_URL = process.env.REDIS_URL || 'redis://localhost:6379';

小技巧：环境变量名建议用大写+下划线，比如 SIGNALING_SERVER_PORT，一目了然。

配置文件

配置文件适合管理复杂的、结构化的配置。比如信令服务器的ICE服务器列表、TURN服务器凭证、WebSocket的路径前缀等等。这些东西写在一行环境变量里，看着就头疼。

我常用的格式是JSON或YAML。JSON原生支持，不用额外解析；YAML可读性更好，适合人工维护。

// config.json
{
  "server": {
    "port": 8080,
    "host": "0.0.0.0",
    "maxConnections": 1000
  },
  "logging": {
    "level": "info",
    "format": "json",
    "output": "stdout"
  },
  "iceServers": [
    { "urls": "stun:stun.l.google.com:19302" },
    { "urls": "turn:turn.example.com:3478", "username": "user", "credential": "pass" }
  ],
  "redis": {
    "host": "localhost",
    "port": 6379,
    "password": ""
  }
}

注意：配置文件里如果包含密码、密钥等敏感信息，一定不要提交到Git仓库。用 .gitignore 忽略掉，或者用环境变量覆盖。

端口配置：别用默认端口

端口配置看似简单，但坑不少。我见过有人直接把端口硬编码成8080，结果部署到生产环境发现8080被别的服务占了。你说尴尬不尴尬？

我的做法是：

开发环境用默认端口（比如8080）
测试环境用环境变量指定
生产环境必须显式配置，不允许用默认值

// 端口配置的最佳实践
const DEFAULT_PORT = 8080;

function getPort() {
  const envPort = process.env.SIGNALING_PORT;
  if (envPort) {
    const port = parseInt(envPort, 10);
    if (isNaN(port) || port < 1024 || port > 65535) {
      console.error(`无效端口: ${envPort}，使用默认端口 ${DEFAULT_PORT}`);
      return DEFAULT_PORT;
    }
    return port;
  }
  // 生产环境不允许使用默认端口
  if (process.env.NODE_ENV === 'production') {
    throw new Error('生产环境必须通过环境变量 SIGNALING_PORT 指定端口');
  }
  return DEFAULT_PORT;
}

建议：端口范围尽量避开1024以下的系统保留端口，以及常见的服务端口（如3306、6379等）。我一般用8080-8099这个区间。

日志级别配置：调试时别被淹死

日志级别这事儿，说白了就是「什么时候该记什么」。我早期做信令服务器时，日志打得特别多，每个信令消息都打印出来。结果呢？一天下来日志文件几十个G，查问题的时候翻都翻不过来。

后来我学乖了，日志级别必须可配置，而且不同环境用不同级别：

环境	推荐日志级别	说明
开发环境	debug	所有细节都打印，方便调试
测试环境	info	记录关键流程和错误
生产环境	warn / error	只记录警告和错误，减少IO开销

// 日志级别配置示例
const LOG_LEVELS = {
  debug: 0,
  info: 1,
  warn: 2,
  error: 3
};

class Logger {
  constructor(level) {
    this.level = LOG_LEVELS[level] || LOG_LEVELS.info;
  }

  debug(...args) {
    if (this.level <= LOG_LEVELS.debug) {
      console.log('[DEBUG]', ...args);
    }
  }

  info(...args) {
    if (this.level <= LOG_LEVELS.info) {
      console.log('[INFO]', ...args);
    }
  }

  warn(...args) {
    if (this.level <= LOG_LEVELS.warn) {
      console.warn('[WARN]', ...args);
    }
  }

  error(...args) {
    if (this.level <= LOG_LEVELS.error) {
      console.error('[ERROR]', ...args);
    }
  }
}

// 使用环境变量控制日志级别
const logger = new Logger(process.env.LOG_LEVEL || 'info');

避坑指南：我曾经在生产环境把日志级别设成了debug，结果信令服务器处理大量并发连接时，日志写入成了性能瓶颈。从那以后，生产环境我最多开到warn级别。

配置加载优先级

当环境变量和配置文件同时存在时，谁说了算？我的规则是：环境变量优先。因为环境变量是运行时注入的，灵活性最高。

加载顺序是这样的：

加载默认配置（代码里写死的默认值）
加载配置文件（覆盖默认值）
加载环境变量（覆盖配置文件）

// 配置加载逻辑
function loadConfig() {
  // 1. 默认配置
  const defaultConfig = {
    port: 8080,
    logLevel: 'info',
    maxConnections: 500
  };

  // 2. 配置文件（如果存在）
  let fileConfig = {};
  try {
    const configFile = process.env.CONFIG_FILE || './config.json';
    fileConfig = JSON.parse(fs.readFileSync(configFile, 'utf-8'));
  } catch (err) {
    console.warn('配置文件加载失败，使用默认配置');
  }

  // 3. 环境变量覆盖
  const envConfig = {
    port: process.env.SIGNALING_PORT ? parseInt(process.env.SIGNALING_PORT) : undefined,
    logLevel: process.env.LOG_LEVEL,
    maxConnections: process.env.MAX_CONNECTIONS ? parseInt(process.env.MAX_CONNECTIONS) : undefined
  };

  // 合并配置（环境变量优先）
  return {
    ...defaultConfig,
    ...fileConfig,
    ...Object.fromEntries(Object.entries(envConfig).filter(([_, v]) => v !== undefined))
  };
}

配置管理的知识体系

说了这么多，咱们用一张图来总结一下配置管理的核心逻辑：

实战建议

最后，分享几个我在实际项目中总结出来的配置管理经验：

配置要有默认值：别让服务因为配置缺失而启动失败。每个配置项都给一个合理的默认值。
配置变更要热加载：生产环境重启服务代价很大。我一般会监听配置文件变化，自动重新加载。
配置要有校验：启动时校验所有配置项，无效配置直接报错退出，别等到运行时才发现。
敏感信息加密：密码、密钥这些，要么走环境变量，要么用Vault之类的密钥管理服务。

个人习惯：我一般会在项目根目录放一个 config.example.json，里面是所有配置项的模板，但敏感信息用占位符代替。这样新同学接手项目，复制一份改改就能用。

配置管理这事儿，说白了就是「把变化的东西从代码里抽出来」。你做得越灵活，后面运维就越省心。别像我早期那样，改个端口都要重新编译——那滋味，真不好受。

📚 课程目录

配置管理：环境变量、配置文件、端口配置、日志级别配置

为什么配置管理这么重要？

配置来源：环境变量 vs 配置文件

环境变量

配置文件

端口配置：别用默认端口

日志级别配置：调试时别被淹死

配置加载优先级

配置管理的知识体系

实战建议