在生产环境中进行服务升级或架构重构时，确保新系统能正确处理线上流量是至关重要的一步，但直接切换往往伴随着巨大风险。流量复制测试（也称为影子流量测试）允许将真实的用户请求复制一份发送到待验证的新环境，而客户端完全不受影响，依然从原有后端获得正常响应。Apache HTTP Server 作为一款久经考验的 Web 服务器与反向代理，虽然不像 Nginx 那样提供原生的 mirror 指令，但凭借其强大的模块系统，尤其是 mod_lua 扩展，我们同样可以实现优雅的线上流量镜像。
流量复制测试的挑战与 mod_lua 方案
在 Apache 的反向代理模式下，通常使用 mod_proxy 将请求转发给一个后端服务器，并获取响应返回给客户端。要实现流量复制，最简单的想法是按照某种方式同时把请求发给两个后端，但只采用主后端的响应。然而原生的 mod_proxy_balancer 只能轮询或故障转移，无法在一条连接中发起并行的二次请求。如果尝试用 mod_rewrite 的 [P] 标签发起代理请求，则会替换掉原本的请求处理流程，导致客户端接收到的是影子后端的响应，这显然不符合要求。
幸运的是，从 Apache 2.3/2.4 开始引入的 mod_lua 模块允许我们在请求处理的各个阶段注入 Lua 脚本，这为流量镜像提供了新的思路。我们可以在请求被代理到主后端之前，利用 Lua 的 r:subrequest() 函数创建一个指向影子后端的子请求，并且不必等待其完整响应，从而在不干扰主流程的情况下完成流量复制。这种方式部署简单、侵入性低，非常适合在现有 Apache 环境中实现影子测试。
逐步构建 Lua 流量镜像处理器
要使用 mod_lua，首先需要确认你的 Apache 安装包含了该模块。在大多数基于 RPM 或 Debian 的发行版中，可以通过包管理器安装 mod_lua，或者在编译时添加 --enable-lua 选项。启用模块后，在配置文件中添加 LoadModule lua_module modules/mod_lua.so 即可。
接下来我们编写镜像逻辑的核心脚本。脚本的目标是在每个请求到来时，提取方法、URI、查询字符串和请求头，然后向影子后端发起一个异步子请求。Lua 的 r:subrequest() 函数会创建一个新的子请求，并可以设置超时，避免影子后端响应慢拖垮主流程。以下是一个典型的镜像处理器示例：
require 'apache2'
function mirror_handler(r)
-- 如果请求目标已经是影子后端自身，避免无限复制
if r.uri:match("^/shadow/") then
return apache2.DECLINED
end
local method = r.method
local uri = r.uri
local args = r.args
local headers_in = r.headers_in
-- 影子后端地址，根据实际环境修改
local shadow_host = "http://192.168.1.100:8080"
local shadow_url = shadow_host .. uri
if args then
shadow_url = shadow_url .. "?" .. args
end
-- 发起子请求，设置2秒超时避免阻塞主请求
local res, err = r:subrequest(shadow_url, {
method = method,
headers_in = headers_in,
timeout = 2
})
if err then
r:warn("mirror subrequest failed: " .. err)
end
-- 继续正常代理到主后端
return apache2.DECLINED
end
这段代码首先通过 require 'apache2' 引入 Apache 的 Lua 绑定。在 mirror_handler 函数中，我们检查 URI 是否包含特定前缀以避免将影子后端的请求再次镜像。随后从请求对象中取出方法、路径和头部，构造出指向影子后端的完整 URL，并通过 r:subrequest 发起子请求。传入的 timeout 参数确保即使影子后端出现问题也不会长时间阻塞当前请求。最后返回 apache2.DECLINED，表示该处理器不生成最终响应，而是交由后续的代理模块继续处理。
配置 Apache 虚拟主机整合模块
编写好 Lua 脚本后，我们需要将其集成到反向代理的虚拟主机配置中。关键在于使用 LuaHookTranslateName 指令，将处理器插入到 URI 翻译阶段，这个阶段恰好在 mod_proxy 处理之前，且我们选择的 early 模式可以保证处理器在所有其他模块之前执行。完整的虚拟主机配置如下：
LoadModule lua_module modules/mod_lua.so
LoadModule proxy_module modules/mod_proxy.so
LoadModule proxy_http_module modules/mod_proxy_http.so
<VirtualHost *:80>
ServerName www.ipipp.com
# 主后端代理配置
ProxyPass / http://main-backend.ippipp.com/
ProxyPassReverse / http://main-backend.ippipp.com/
# 加载镜像 Lua 脚本（文件路径根据实际情况调整）
LuaHookTranslateName /etc/httpd/conf/mirror.lua mirror_handler early
# 避免 Lua 文件被当作静态文件提供
<Files "mirror.lua">
SetHandler lua-script
</Files>
ErrorLog logs/ipipp-error.log
CustomLog logs/ipipp-access.log combined
</VirtualHost>
这里通过 ProxyPass 将根路径的请求代理到主后端，LuaHookTranslateName 指向之前编写的 Lua 文件并指定入口函数。注意 early 参数确保 Lua 处理器在代理转发之前运行，从而在请求被主后端处理的同时，影子后端也可以收到一份拷贝。为了安全起见，我们还用 <Files> 块将 Lua 脚本的处理器显式设置为 lua-script，避免源码泄露。
重启 Apache 后，所有到达该虚拟主机的请求都会自动复制一份到指定影子后端，而用户与主后端的交互不受任何影响。通过检查影子后端的访问日志，就可以验证其是否能正确处理线上流量，或者用它来预热缓存、进行压力测试等。
生产环境优化与故障处理
尽管上述方案基本满足了实时流量复制的需求，但在生产环境中部署时还需要考虑几个关键点。首先是性能开销：每个请求都会额外发起一个子请求，这会增加一定的 CPU 和网络消耗。为了降低影响，可以限制子请求的传输内容大小，例如忽略体积过大的 POST 请求体，或者在处理器中通过 r.headers_in 仅传递必要的请求头。其次，影子后端不可用时不应该影响主流程，我们的脚本已经通过超时和错误捕获进行了防护，但仍然建议在 Apache 的事件 MPM（mpm_event）下运行，因为该模式能够更好地处理异步子请求，避免线程阻塞。
另外，如果影子后端的响应时间普遍较长，可以将子请求的超时值设置得更短（如 500 毫秒），并开启主请求的缓冲模式，以防止慢速子请求拖慢连接池。在调试阶段，可以打开 Apache 的 LuaCodeCache 指令来缓存编译后的脚本，提升执行效率；而在频繁修改脚本时，可以临时关闭缓存。当出现镜像丢失的情况时，检查错误日志中的 warn 提示即可快速定位问题。
最后，安全性也是不能忽视的。影子后端通常部署在内网，应避免将其暴露在公网。如果必须通过代理转发包含敏感头部（如 Cookie 或 Authorization）的请求，务必在镜像处理器中添加过滤逻辑，或者将影子后端配置为仅接受来自代理服务器的连接，以降低信息泄露的风险。通过这些优化措施，基于 Apache 的流量复制机制能够在稳定的同时保持较高的可用性，成为日常发布流程中可靠的一环。