apache通过mod_rewrite和mod_proxy实现旧api透明转发与平滑迁移,核心是路径接管、header透传、灰度分流及故障兜底,禁用301跳转,采用内部代理([p]标志)确保客户端无感切换。

服务器迁移时让老旧客户端请求平滑过渡,关键不是“跳转”,而是“接管+透传+渐进切换”。Apache 要在不改客户端代码、不中断调用的前提下,把旧路径请求原样导到新服务,同时保留原始上下文(如 Host、Cookie、Header),并支持灰度验证和故障兜底。
用 mod_proxy + mod_rewrite 实现透明转发
禁用 301 跳转,改用内部代理:客户端仍访问 /api/v1/user/123,Apache 拦截后直接转发给新后端 http://new-api:8080/v2/users/123,响应再原路返回。这样无重定向延迟、不暴露新地址、不丢失 Referrer 和 Cookie。
- 必须启用模块:
mod_rewrite、mod_proxy、mod_proxy_http - 在
<virtualhost></virtualhost>中开启:ProxyPreserveHost On(保持原始 Host 头) - 关键规则示例:
RewriteRule "^/api/v1/(.*)$" "http://new-api:8080/v2/$1" [P,L]ProxyPassReverse "/api/v1/" "http://new-api:8080/v2/"
按客户端特征做灰度分流
不一刀切全量切换,而是根据真实请求信号控制流量走向。比如只让新版 App(带 X-App-Version: 3.2+)或内测用户(Cookie 含 beta=on)走新服务,其余继续走旧系统。
Apache Superset 是一个广泛采用的开源 BI 平台,用于 SQL 探索、图表构建和仪表板交付。当代理需要查询仓库数据、组装仪表板或使用成熟的分析界面解释指标而不是临时笔记本代码时,此技能非常有用。
- 匹配 Header:
RewriteCond %{HTTP:X-App-Version} ^3\.2RewriteRule "^/api/(.*)$" "http://new-api:8080/$1" [P,L] - 匹配 Cookie:
RewriteCond %{HTTP:Cookie} "beta=on"RewriteRule "^/api/(.*)$" "http://new-api:8080/$1" [P,L]
保留旧接口直通能力与降级策略
迁移期间,部分核心接口(如 /health、/login)仍需由旧服务响应;新服务不稳定时,要能自动切回或返回友好提示,避免雪崩。
- 显式直通旧路径:
ProxyPass "/health" "http://legacy:8000/health" - 配置健康检查与自动兜底:
<proxy></proxy>BalancerMember http://legacy:8000 retry=60 timeout=5BalancerMember http://new-api:8080 retry=60 timeout=5 hcexpr=ok - 添加响应头提示升级:
Header always set X-API-Deprecated "true" "expr=%{REQUEST_URI} =~ m#^/api/v1/#"
上线前验证与可观测性保障
仅测状态码不够,要确认请求是否真抵达目标、Header 是否完整透传、响应是否被篡改。同时记录每条路径的调用量,辅助判断下线节奏。
- 开启重写日志(调试阶段):
LogLevel alert rewrite:trace3(Apache 2.4+) - 统计新旧路径调用比:
LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\" %{X-Forwarded-For}i %{X-API-Backend}e" combined
在日志中用%{X-API-Backend}e标记实际转发目标 - 用 curl 验证透传效果:
curl -H "Authorization: Bearer xyz" -H "X-Trace-ID: 123" https://old-domain.com/api/v1/me→ 检查新服务日志是否收到这两个 Header










