灰度发布在MongoDB中需通过嵌入式版本字段、复合索引与聚合管道实现，而非独立版本集合；应用按环境/服务/权重筛选生效版本，MongoDB仅负责高效查询与原子更新。
灰度发布在配置中心场景下，核心不是“存多个版本”，而是“让不同服务实例读到不同版本的配置”。MongoDB 本身不提供内置的灰度路由能力，但可以用文档结构 + 查询逻辑 + 应用层配合实现，关键在于避免把版本控制做成纯时间戳快照堆砌。
用嵌入式版本字段替代独立版本集合
别建 config_versions 集合按时间存全量快照。那样查最新版要 $sort + $limit 1，加灰度条件后索引难覆盖，还容易漏掉生效时间判断。
直接在主配置文档里存多版本内容，例如：
{
"_id": "feature-toggle",
"name": "支付链路优化",
"versions": [
{
"version": "v1.0.0",
"content": { "enabled": true, "timeoutMs": 3000 },
"status": "active",
"生效时间": { "start": "2026-09-01T00:00:00Z", "end": null },
"灰度规则": { "env": ["staging"], "service": ["order-service"] }
},
{
"version": "v1.1.0",
"content": { "enabled": true, "timeoutMs": 2500 },
"status": "pending",
"生效时间": { "start": "2026-09-08T00:00:00Z" },
"灰度规则": { "env": ["prod"], "service": ["order-service"], "weight": 0.2 }
}
]
}
这样一次 find 就能拿到所有候选版本，应用自己按当前环境、服务名、权重做筛选。
- 查询时用
versions.status: "active"+versions.生效时间.start: { $lte: now }过滤有效版本 - 加
versions.灰度规则.env: "prod"和versions.灰度规则.service: "order-service"做精准匹配 - 如果带
weight，由客户端生成随机数决定是否启用该版本，MongoDB 不参与运行时决策
必须为灰度字段建复合索引
没索引时，versions.灰度规则.env 这种嵌套数组字段查询会全表扫描。尤其当配置文档变多、versions 数组变长，性能断崖下跌。
建这个索引：
db.configs.createIndex({
"versions.status": 1,
"versions.生效时间.start": -1,
"versions.灰度规则.env": 1,
"versions.灰度规则.service": 1
})
注意点：
-
"versions.生效时间.start": -1让最近生效的版本排前面，配合$arrayElemAt取第一个匹配项更稳 - 不要对
versions.灰度规则.weight建索引——它只用于客户端计算，MongoDB 不查它 - 如果灰度规则里还有
tags或ipRange字段，且查询频繁，才考虑加进索引；否则索引膨胀快，写入开销大
用聚合管道原子获取生效版本，别靠应用拼逻辑
别让应用先 find 出整个文档，再用 JS 遍历 versions 数组筛版本。网络传输大文档 + 客户端 CPU 拼逻辑，延迟高还难调试。
用 aggregate 一次性筛出目标版本内容：
db.configs.aggregate([
{ $match: { _id: "feature-toggle" } },
{ $unwind: "$versions" },
{
$match: {
"versions.status": "active",
"versions.生效时间.start": { $lte: new Date() },
"versions.灰度规则.env": "prod",
"versions.灰度规则.service": "order-service"
}
},
{ $project: { content: "$versions.content", version: "$versions.version" } }
])
这个管道返回的就是最终生效的 content，应用无需再解析逻辑。
- 如果灰度规则是权重型（
weight: 0.2），就把$match阶段换成$addFields+$rand，再用$expr判断，但注意$rand在分片集群上可能不一致，慎用 - 聚合结果为空，代表没匹配到任何灰度版本——这时应用应 fallback 到默认值或报错，而不是静默返回旧版
更新版本时用 updateOne + arrayFilters 避免读-改-写竞争
上线新灰度版本时，常见错误是先 find 出文档，改完 versions 数组再 save。并发写入会导致丢失更新。
正确做法是用 arrayFilters 直接更新数组内某一项：
db.configs.updateOne(
{ _id: "feature-toggle" },
{
$set: {
"versions.$[v].status": "pending",
"versions.$[v].生效时间.start": new Date("2026-09-08T00:00:00Z")
}
},
{
arrayFilters: [{ "v.version": "v1.1.0" }]
}
)
或者追加新版本（不是覆盖）：
db.configs.updateOne(
{ _id: "feature-toggle" },
{
$push: {
versions: {
version: "v1.2.0",
content: { "enabled": true, "timeoutMs": 2000 },
status: "draft",
"生效时间": { "start": "2026-09-15T00:00:00Z" },
"灰度规则": { "env": ["prod"], "service": ["order-service"], "weight": 0.5 }
}
}
}
)
注意：
-
$push不需要arrayFilters，但得确保应用层生成的version字符串全局唯一（建议用语义化版本+时间戳组合） - 如果要停用某版本，用
$set: {"versions.$[v].status": "inactive"}，别删数组元素——历史审计和回滚依赖完整版本链
最易被忽略的是灰度规则变更后的缓存穿透问题：应用通常会缓存配置结果，但灰度规则变了，缓存却没失效。要么加细粒度缓存 key（含 env+service），要么在更新配置时发消息通知所有实例清缓存。MongoDB 本身不解决这个问题，得靠架构补位。
