重写Tomcat请求处理器添加自定义行为的技术方案咨询

一、重写Tomcat默认请求处理器的可行性 #

可以实现，但强烈不推荐在数百节点的生产环境采用该方案，原因如下：

• Tomcat 6核心代码耦合度高，重写默认请求处理器需要深度修改Coyote容器或Connector的核心逻辑，每个节点都要替换定制化的Tomcat核心包，后续小版本升级都会引发兼容问题，长期维护成本极高。
• 定制代码一旦出现bug，排查难度大，会直接影响整个集群的可用性。

如果一定要尝试，操作步骤如下（仅作技术参考）：

1. 下载对应版本的Tomcat 6源码，定位到请求处理核心类（如org.apache.coyote.http11.Http11Protocol的process方法、org.apache.catalina.core.StandardEngineValve类）。
2. 在请求转发至业务应用前插入你的预处理逻辑。
3. 重新编译Tomcat核心Jar包，替换所有节点的对应文件。
4. 完成全量功能测试，确保原有请求流程不受影响。

二、更推荐的轻量级替代方案 #

以下方案无需修改Tomcat核心，兼容性好、易维护，适合数百节点批量部署：

1. 自定义Tomcat Valve（最推荐） #

Tomcat的Valve机制是官方提供的请求拦截扩展方案，完全兼容原有处理流程：

• 编写继承org.apache.catalina.valves.ValveBase的自定义Valve类，重写invoke方法，在调用getNext().invoke(request, response)前加入预处理逻辑：

public class PreProcessValve extends ValveBase {
    @Override
    public void invoke(Request request, Response response) throws IOException, ServletException {
        // 插入你的预处理逻辑，比如请求头修改、日志记录等
        String requestUri = request.getRequestURI();
        System.out.println("Preprocessing request: " + requestUri);
        
        // 继续执行原有请求链
        getNext().invoke(request, response);
    }
}

• 部署方式：将编译后的class打包成Jar，放到所有Tomcat节点的$CATALINA_HOME/lib目录，然后修改conf/server.xml，在Engine或Host节点下添加Valve配置：

<Engine name="Catalina" defaultHost="localhost">
    <!-- 自定义预处理Valve，需放在原有Valve之前 -->
    <Valve className="com.yourcompany.valve.PreProcessValve" />
    <!-- 原有Realm、Valve配置保持不变 -->
</Engine>

• 优势：官方标准机制，无需改动Tomcat核心，可通过自动化脚本（如Ansible）批量推送Jar包和修改配置，运维成本低。

2. 全局Servlet Filter #

如果应用基于Servlet规范，可采用Java EE标准的Filter实现全局拦截：

• 编写实现javax.servlet.Filter的过滤器类，在doFilter方法中插入预处理逻辑：

public class PreProcessFilter implements Filter {
    @Override
    public void init(FilterConfig filterConfig) throws ServletException {}

    @Override
    public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException {
        // 预处理逻辑
        HttpServletRequest httpRequest = (HttpServletRequest) request;
        System.out.println("Preprocessing filter: " + httpRequest.getRequestURI());
        
        // 放行至原有请求流程
        chain.doFilter(request, response);
    }

    @Override
    public void destroy() {}
}

• 部署方式：将过滤器打包到应用War包，或单独打包成Jar放入$CATALINA_HOME/lib，然后修改配置：
  • 若需全局生效：修改$CATALINA_HOME/conf/web.xml添加过滤器映射；
  • 若仅针对目标应用：修改对应War包内的web.xml。

<filter>
    <filter-name>PreProcessFilter</filter-name>
    <filter-class>com.yourcompany.filter.PreProcessFilter</filter-class>
</filter>
<filter-mapping>
    <filter-name>PreProcessFilter</filter-name>
    <url-pattern>/*</url-pattern>
    <dispatcher>REQUEST</dispatcher>
    <dispatcher>FORWARD</dispatcher>
</filter-mapping>

3. 反向代理层统一处理（集群场景最优） #

如果集群前端有反向代理（如Nginx），可在代理层实现预处理，无需修改Tomcat和应用：

• 示例Nginx配置片段：

server {
    listen 80;
    server_name your-app-domain;

    location / {
        # 预处理逻辑：添加自定义请求头
        add_header X-Preprocessed "true";
        # 复杂逻辑可通过Lua脚本实现
        # access_by_lua_block {
        #     ngx.req.set_header("X-Request-ID", ngx.var.request_id)
        # }

        # 转发至后端Tomcat集群
        proxy_pass http://tomcat-cluster;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

• 优势：仅需修改代理层配置，无需改动数百个Tomcat节点，运维成本极低，适合批量操作。但预处理逻辑受限于代理层能力，不适合依赖应用上下文的复杂场景。

三、方案选型参考 #

• 需与Tomcat内部请求对象深度交互时，优先选自定义Valve；
• 仅需标准Servlet请求预处理且可修改应用配置时，选全局Servlet Filter；
• 预处理逻辑不涉及应用内部状态且有反向代理层时，优先选反向代理层处理（集群场景最优）。

内容的提问来源于stack exchange，提问作者Mark1234