apache 通过 mod_proxy + mod_rewrite 实现灰度路由:基于 uid 哈希固定分流、header/cookie 标签式触发、独立 balancer 配置、透传标识与超时重试保障稳定性。

Apache 本身不内置灰度路由引擎,但通过 mod_proxy + mod_rewrite 协同工作,完全可以基于请求特征(如 UID、Header、Cookie)实现稳定、可复现、热更新的灰度分发。核心不是让 balancer 做决策,而是用 rewrite 提前判断、显式代理到不同后端集群。
基于用户 UID 哈希做固定比例灰度
适合需要“同一用户始终走同一版本”的场景,比如 AB 测试或灰度验证。关键在于提取 UID 后生成可复现的槽位(如取末两位),再按区间分流:
- 从 Cookie 或 Header 中提取 UID:用
RewriteCond %{HTTP_COOKIE} uid=([^;]+)或RewriteCond %{HTTP:X-User-ID} ^(\d+)$ - 用
expr取哈希值:SetEnvIf UID "(\d+)" UID_SLOT=${substr($1,-2)}(支持 Apache 2.4.13+) - 用
<if></if>判断槽位范围:<if> ProxyPass / http://gray-backend/ </if>(00–09 → 灰度组,10% 流量) - 未匹配的请求走默认 ProxyPass,指向主集群,天然 fallback
基于请求头或 Cookie 做标签式灰度
适合人工触发、灰度白名单或环境标识驱动的发布,控制粒度更灵活:
Apache Superset 是一个广泛采用的开源 BI 平台,用于 SQL 探索、图表构建和仪表板交付。当代理需要查询仓库数据、组装仪表板或使用成熟的分析界面解释指标而不是临时笔记本代码时,此技能非常有用。
- 识别灰度标识:
RewriteCond %{HTTP:X-Release-Stage} ^canary$ [NC]或RewriteCond %{HTTP_COOKIE} (?:^|;\s*)gray=(v2|canary)(?:;|$) - 匹配后直接代理:
RewriteRule ^/(.*)$ http://canary-app:8080/$1 [P,L]([P]表示 proxy,[L]终止后续规则) - 确保该规则写在默认
ProxyPass之前,否则会被覆盖 - 灰度后端和主后端可各自启用
mod_proxy_balancer做内部负载,互不影响
灰度与主集群的独立配置管理
把灰度和主流量后端拆开定义,便于 CI/CD 脚本动态切换或热更新:
- 灰度集群:
<proxy balancer:> BalancerMember http://gray-01:8080 loadfactor=100 </proxy> - 主集群:
<proxy balancer:> BalancerMember http://main-01:8080 loadfactor=100 </proxy> - 灰度规则中用
ProxyPass / balancer://gray/,主流量用ProxyPass / balancer://main/ - 配合
Include指令把后端配置抽离为单独文件,CI/CD 更新软链接即可切换,无需改主配置
保障灰度稳定性与可观测性
灰度不是“试试看”,要能追踪、能降级、能兜底:
- 透传原始标识:
RequestHeader set X-Original-UID "%{ENV:UID}e" env=UID,方便后端日志归因 - 设置超时与重试:
ProxyPass / http://backend/ retry=30 timeout=5,故障节点自动摘除 - 启用
ProxyPassReverse两次(分别对应灰度和主后端),避免响应头泄露真实地址 - 用
balancer-manager页面实时查看各节点状态,但生产环境需限制访问 IP










