采集任务不想天天改代码重部署？特性开关与配置驱动实践

采集系统上线后，最烦的改动是「改一行参数也要改代码、重部署」。并发档位、缓存 TTL、解析版本、端点开关……这些如果写死在代码里，每次调整都是一次发布。这篇讲特性开关（feature flag）与配置驱动的实践：把「运行参数」从代码里抽出来，改配置即生效，还能快速灰度回滚。

特性开关解决什么

采集系统的三个常见痛点，特性开关都能治：

1. 灰度：新解析逻辑先对 10% 的关键词生效，没问题再放全量
2. 快速回滚：出问题改配置回滚，不用改代码重部署（迁移篇的版本开关就是这个思路）
3. 免部署调参：并发、缓存 TTL、告警阈值，改配置就生效

核心思想：把「运行参数」从代码里抽出来，变成可热更新的配置。

设计：配置驱动 + 开关

先做最基础的「配置文件驱动」：

# config.yaml —— 运行参数集中管理
concurrency: 10
cache_ttl_seconds: 3600
alert_threshold_p50_ms: 2500
retry_max: 3

# config.py —— 加载配置
import yaml

def load_config():
    with open("config.yaml", encoding="utf-8") as f:
        return yaml.safe_load(f)

cfg = load_config()

改动 config.yaml + 重启进程 = 生效。这已经比「改代码重部署」轻很多。

进阶：特性开关（运行时切换）

配置驱动还不够——进程重启也有成本。特性开关让「运行中切换」：

# 特性开关：解析版本、端点路由、灰度比例
FLAGS = {
    "parse_version": "v2",        # v1 / v2，切换即换解析逻辑
    "use_secondary_source": False,
    "new_parser_rollout": 0.1,    # 灰度比例：10% 的关键词用新解析
}

def parse(raw, keyword):
    # 灰度：hash(keyword) 决定是否走新逻辑
    rollout = FLAGS["new_parser_rollout"]
    if hash(keyword) % 100 < rollout * 100:
        return parse_v2(raw)
    return parse_v1(raw)

开关的类型：

• 布尔开关：use_secondary_source —— 开/关一个能力
• 档位开关：concurrency: 10 —— 数值参数
• 灰度开关：rollout: 0.1 —— 按比例放量
• 版本开关：parse_version: v2 —— 切换实现版本

开关放哪：本地文件 or 配置中心

两种承载方式：

1. 本地配置文件（小团队够用）

• YAML/JSON 文件，改文件 + 信号触发重载（SIGHUP），不用重启

import signal

def reload_handler(signum, frame):
    global cfg
    cfg = load_config()
    print("配置已热重载")

signal.signal(signal.SIGHUP, reload_handler)

2. 配置中心（团队/生产）

• 用现成配置中心（如 Apollo、Consul）或简单的环境变量注入
• 支持按环境、按租户、远程改配置

建议：小团队本地文件 + 信号重载就够；团队生产再上配置中心。别一开始就引入重依赖。

应用到采集任务

把特性开关用到采集的三个典型位置：

1. 并发与频率

cfg = load_config()
crawl_batch(keywords, max_workers=cfg["concurrency"], rate=cfg["rate_per_second"])

2. 缓存 TTL（缓存篇的 TTL 参数化）

data = cached_search(params, ttl_seconds=cfg["cache_ttl_seconds"])

3. 告警阈值（质量/探活篇的阈值参数化）

if p50_ms > cfg["alert_threshold_p50_ms"]:
    alert("延迟超标")

所有「运行参数」都从配置读——这就是配置驱动。

踩坑记录

坑 1：配置没校验，改错直接崩。 配置加载时校验类型和值域（concurrency 必须 ≥1、rollout 必须 0-1），别把配置当「任意文本」。

坑 2：开关状态不可见。 线上改了配置不知道生效没。启动时/重载时打印当前配置，运行时暴露 /health 返回配置快照。

坑 3：灰度比例用随机数。 随机灰度导致同一关键词有时 v1 有时 v2，数据不一致。用 hash(keyword) 稳定分流——同一关键词永远走同一逻辑。

坑 4：配置文件路径硬编码。 换个环境就找不到配置。用环境变量指定配置路径，或按环境加载不同的配置文件。

工程清单沉淀

1. 运行参数全部配置驱动，不写死在代码里
2. 开关类型：布尔 / 档位 / 灰度 / 版本
3. 小团队：本地文件 + 信号热重载；团队：配置中心
4. 灰度用 hash(keyword) 稳定分流
5. 配置加载校验 + 运行时可见（health 返回配置快照）

特性开关让采集任务从「改一行代码一次发布」变成「改一个配置立即生效」。灰度、回滚、调参都变成了配置操作——这是采集系统「可运维」的重要一环。

数据源接口的响应字段（作为解析版本开关的切换对象）在 SerpBase 官方文档 里可查。你的采集任务用配置驱动了吗？评论区聊聊各自的开关设计。