Spring Cloud Zuul 面试题：从入门到精通的全景解析

在回答“Zuul 是如何工作的”这类基础面试题时，不能仅停留在表面。面试官希望听到的是关于 请求生命周期 的深入描述。Zuul 的核心在于“过滤器链”和“路由分发”。

1. 请求处理流程

当客户端发起请求时，请求首先到达 Zuul Servlet。Zuul 会创建一个 ZuulHttpServletProcessor 来处理请求，并将其封装为 ZuulRunner。核心流程如下：

• Pre-filter（前置过滤器）：在请求路由之前执行，用于参数校验、权限认证、日志记录等。如果 Pre-filter 返回错误，请求将不会继续路由。
• Route-filter（路由过滤器）：负责将请求转发到具体的后端微服务实例。这是 Zuul 的核心功能，它利用 Ribbon 或 Eureka 进行服务发现和负载均衡。
• Post-filter（后置过滤器）：在请求路由完成后执行，用于收集统计信息、添加标准响应头、修改响应体等。
• Error-filter（错误过滤器）：如果上述任何阶段发生错误，请求将转发到 Error-filter 进行处理。

2. 核心数据结构：ZuulContext

Zuul 使用 ZuulContext（基于 RequestContext 静态变量）来存储整个请求生命周期的上下文信息。每个请求都有一个独立的上下文，存储了请求参数、响应状态、错误信息、路由目标等。面试官常问：“为什么 Zuul 1.x 是阻塞式 IO？” 答案就在于此，因为 RequestContext 是线程绑定的，且在处理过程中持有线程资源，导致其在高并发下线程消耗巨大。

Spring Cloud Zuul 面试题 中，关于 Filter 的考察频率极高。面试官通常会询问自定义 Filter 的实现步骤以及 Filter 的执行顺序。

1. 过滤器类型对比

2. 过滤器执行顺序（Order）

Zuul 通过 filterOrder() 方法定义执行顺序。数字越小，优先级越高。常见的内置过滤器顺序：

• ServletDetectionFilter (30)：标记 Servlet 容器。
• ServletPreparationFilter (40)：创建请求和响应包装器。
• FormBodyWrapperFilter (50)：解析表单数据。
• DebugFilter (80)：标记调试请求。
• PreDecorationFilter (100)：确定路由目标，设置 RequestContext 中的路由属性。
• RibbonRoutingFilter (200)：通过 Ribbon 转发请求到服务。
• SimpleHostRoutingFilter (500)：通过 HTTP Client 转发请求到具体主机。
• SendErrorFilter (400)：处理错误转发。
• SendResponseFilter (1000)：将后端响应写回客户端。

3. 自定义过滤器示例

面试官常要求手写一个简单的权限校验过滤器。以下是一个标准的 Pre-filter 实现示例：

import com.netflix.zuul.ZuulFilter;
import com.netflix.zuul.context.RequestContext;
import com.netflix.zuul.exception.ZuulException;
import org.springframework.stereotype.Component;
import javax.servlet.http.HttpServletRequest;
@Component
public class AuthFilter extends ZuulFilter {
    @Override
    public String filterType() {
        return "pre"; // 前置过滤器
    }
    @Override
    public int filterOrder() {
        return 0; // 优先级最高
    }
    @Override
    public boolean shouldFilter() {
        return true; // 总是执行
    }
    @Override
    public Object run() {
        RequestContext ctx = RequestContext.getCurrentContext();
        HttpServletRequest request = ctx.getRequest();
        String token = request.getParameter("token");
        if (token == null || token.isEmpty()) {
            ctx.setSendZuulResponse(false); // 阻止路由
            ctx.setResponseStatusCode(401);
            ctx.setResponseBody("Unauthorized: Missing Token");
        }
        return null;
    }
}

在实际项目中，路由配置是 Zuul 最频繁被修改的部分。面试题中常涉及路径匹配规则和负载均衡策略。

1. 基础路由配置

spring:
  cloud:
    zuul:
      routes:
        # 方式一：直接映射服务名
        user-service: /user/
        # 方式二：自定义路径
        order-service:
          path: /order/
          serviceId: order-service
          stripPrefix: false # 是否去除前缀，默认为true

注意：stripPrefix 是一个常见的坑。如果设置为 true，请求 /user/1 将被转发为 /1；如果设置为 false，则转发为 /user/1。面试时需根据后端服务的具体路径要求来选择。

2. 忽略服务

有时我们希望某些服务不经过网关，或者忽略某些路径。可以使用 ignored-services：

spring.cloud.zuul.ignored-services: one-service, service # 支持通配符

3. 前缀统一添加

为了区分内外网或版本控制，Zuul 支持全局前缀：

spring.cloud.zuul.prefix: /api/v1

配置后，访问 /api/v1/user/1 将被路由到 user-service 的 /user/1（假设 stripPrefix 为 true）。

这是 Spring Cloud Zuul 面试题 中的高频“陷阱题”。面试官会问：“Zuul 1.x 和 2.x 有什么区别？为什么现在推荐 Gateway？”

1. 阻塞式 IO 模型

Zuul 1.x 基于 Servlet 2.5，使用阻塞式 IO。每个请求都需要占用一个 Tomcat 线程。在高并发场景下，线程资源成为瓶颈。一旦后端服务响应慢，Zuul 的线程池会迅速耗尽，导致服务雪崩。

2. 优化方案

虽然 Zuul 1.x 性能不佳，但在无法升级的情况下，可以采取以下优化措施：

• 调整线程池大小：通过配置 ribbon.MaxTotalConnections 和 ribbon.MaxConnectionsPerHost 来增加连接数。
• 启用异步 Servlet：Spring Boot 2.x 默认使用 Tomcat 8+，支持异步 Servlet，但这并不能根本改变 Zuul 1.x 的架构缺陷。
• 超时时间设置：合理设置 ribbon.ReadTimeout 和 ribbon.ConnectTimeout，避免线程长时间阻塞。
• 熔断降级：集成 Hystrix，当后端服务不可用时，快速失败，保护网关本身。

3. Zuul 2.x 的革命

Zuul 2.x 基于 Netty，采用了非阻塞式 IO 和响应式编程模型，性能得到了显著提升，接近 Spring Cloud Gateway。但由于 Netflix 停止维护 Zuul 1.x，且 Zuul 2.x 社区生态较小，Spring Cloud Gateway 成为了更主流的选择。

在实际工作中，Zuul 经常会出现各种奇葩问题。以下列举几个典型的故障场景及解决方案。

1. 404 Not Found 错误

现象：请求网关后返回 404。

原因：

• 路由配置错误，路径匹配不到。
• 后端服务未注册到 Eureka/Nacos，网关无法发现。
• stripPrefix 设置不当，导致后端服务找不到对应 Controller。

解决：检查 actuator/routes 端点，查看实际路由映射；开启 DEBUG 日志，观察 Zuul 的过滤链执行情况。

2. 请求体丢失（Request Body Lost）

现象：在 Pre-filter 中读取了 Request Body 后，路由转发时 Body 为空。

原因：Servlet 的 InputStream 只能读取一次。如果在 Pre-filter 中调用了 request.getInputStream()，流已被消费，后续路由时无法再次读取。

解决：

• 使用 BodyCacheFilter 缓存请求体。
• 自定义 HttpServletRequestWrapper 缓存输入流。

// 示例：缓存输入流
public class CachedBodyHttpServletRequest extends HttpServletRequestWrapper {
    private byte[] cachedBody;
    // ... 实现缓存逻辑
}

3. 跨域问题（CORS）

现象：前端调用网关时报跨域错误。

解决：在 Zuul 中配置全局 CORS 过滤器，或在后端服务中配置 CORS。推荐在网关层统一处理：

@Bean
public CorsFilter corsFilter() {
    final UrlBasedCorsConfigurationSource source = new UrlBasedCorsConfigurationSource();
    final CorsConfiguration config = new CorsConfiguration();
    config.setAllowCredentials(true);
    config.addAllowedOrigin("");
    config.addAllowedHeader("");
    config.addAllowedMethod("");
    source.registerCorsConfiguration("/", config);
    return new CorsFilter(source);
}

在面试中，面试官经常会问：“既然 Zuul 这么流行，为什么 Spring Cloud 要推出 Gateway？” 以下是两者的核心对比：

总结：虽然 Zuul 1.x 已不再推荐用于新项目，但理解其原理对于维护老系统和应对传统大厂面试依然至关重要。对于新项目，强烈建议直接使用 Spring Cloud Gateway。

这是一个综合性的架构设计题。回答要点包括：

• 多实例部署：网关无状态，可通过 Nginx 或 DNS 进行负载均衡。
• 服务发现：集成 Eureka/Nacos，实现动态路由。
• 熔断降级：集成 Hystrix/Sentinel，防止后端故障拖垮网关。
• 限流：使用 Redis + Lua 或 Sentinel 进行接口限流。
• 安全认证：统一 JWT 校验，黑名单过滤。
• 日志监控：收集访问日志，接入 ELK 或 Prometheus+Grafana。

在 Spring Security 5.x 中，Zuul 的过滤器可能与 Security 的过滤器链冲突。通常建议将 Security 过滤器放在 Zuul 过滤器之前，或者在 Zuul 中禁用 Security 的某些过滤器，仅在网关层进行统一的 Token 校验，而非在每个微服务中重复校验，以提高性能。