灰度发布的核心逻辑是可控的渐进式上线，依赖可解释、可回滚、可追踪的业务维度标签分流（如地域、设备、会员等级），而非随机切流；通过nginx+lua实现轻量路由，结合三元组版本标识与分钟级监控闭环，支撑自动熔断。
灰度发布的核心逻辑：用户分流不是随机切流
灰度发布本质是“可控的渐进式上线”，关键不在技术多炫酷，而在分流策略是否可解释、可回滚、可追踪。用户分流不是简单按ID尾号或IP哈希切5%，而是基于明确的业务维度（如地域、设备类型、会员等级、新老用户）打标签，再按标签比例放量。比如：先对北京地区安卓端VIP用户推送v2.1版本，同时保留v2.0供其他用户使用；一旦监控发现该群体崩溃率上升1%，立即关闭该灰度通道，不影响全局。
用Nginx+Lua实现轻量级用户分流
无需引入复杂网关，Nginx配合openresty的Lua模块就能完成基础灰度路由。核心思路是：在请求入口解析用户标识（如cookie中的uid或x-device-id），查本地配置或远程规则服务，决定代理到v2.0还是v2.1后端集群。
- 在nginx.conf中启用Lua模块，定义灰度匹配逻辑
- 将用户标识做一致性哈希，映射到0–99区间，按预设比例分配版本（如0–9 → v2.1，其余→ v2.0）
- 支持手动开关：通过共享字典或外部配置中心动态更新分流开关和比例，无需reload Nginx
- 记录灰度标记到响应头（如X-Gray-Version: v2.1），便于前端和日志系统识别
版本控制要绑定环境与配置，不能只靠git Tag
Git Tag只是代码快照，灰度发布的版本控制必须涵盖运行时要素：二进制包版本、配置文件集、数据库迁移状态、依赖服务接口契约。推荐采用“三元组”标识法：v2.1.0-b20240520-prod，其中b20240520是构建时间戳，prod是目标环境别名。
- 每个灰度版本对应独立的docker镜像Tag，并在镜像元数据中标注所用配置分支（如config-v2.1）
- 数据库变更走Flyway/Liquibase，每次灰度前校验目标库schema版本是否就绪
- API接口变更需配套提供兼容模式（如v2.1接口同时支持v2.0请求参数），避免强依赖客户端升级
监控与决策闭环：从“看数据”到“自动熔断”
灰度不是发完就等反馈，而是建立分钟级可观测闭环。重点监控三类指标：基础稳定性（http 5xx、P95延迟）、业务健康度（关键路径转化率、订单创建成功率）、灰度特有行为（新功能点击率、AB测试目标达成率）。
- 用prometheus采集Nginx日志中的X-Gray-Version字段，按版本聚合错误率
- 设置动态阈值告警：若v2.1的下单失败率比v2.0高0.5%且持续3分钟，触发告警并自动调用运维API降级流量
- 所有灰度操作留痕：谁在何时启用了哪条规则、调整了什么比例、依据哪条监控曲线决策，全部写入审计日志