微服务面试准备——Zuul

zull

动态路由、请求监控、认证鉴权、压力测试、灰度发布

动态路由：动态路由是动态的将客户端的请求路由到后端不同的服务上，如果没有网关去做统一的路由，那么客户端就需要关注后端 N 个服务。

请求监控：请求监控可以对整个系统的请求进行监控，详细地记录请求响应日志，可以实时统计当前系统的访问量及监控状态。调用量，根据数据分析决定是否要动态限流，分析是否有爬虫请求等多维数据结果。

认证鉴权：认证鉴权可以对每一个访问请求做认证，拒绝非法请求，保护后端的服务。微服务架构下，如果没有使用网关，那么客户端需要直接跟多个服务进行交互，当请求到达对应的服务时，就必须验证当前的请求有没有登录，有没有权限访问。访问 A 服务需要验证一次，访问 B 服务也需要验证一次，每个服务都要做重复的工作。唯一要做的工作就是在网关验证完成后，需要将用户信息传递给后端服务，后端服务默认相信当前的请求已经在网关中通过验证，它不会再去做验证的逻辑，但是当前请求对应的用户信息要告诉后端服务，可以将用户信息通过 HTTP 请求头传递给路由的后端服务。

压力测试：通过 Zuul 可以动态地将测试请求转发到后端服务的集群中，还可以识别测试流量和真实流量，用来做一些特殊处理。对于测试请求，可以在请求头中添加标识，让网关能够识别这是一个测试请求，当识别到测试请求后，根据对应的规则进行路由，这里可以用配置中心存储规则，测试请求路由到测试服务，测试服务会有单独的测试数据库，这样测试的请求就不会影响到正式的服务和数据库了。

灰度发布：灰度发布可以保障整体系统的稳定性，在初始灰度的时候就可以及时发现、调整问题，以降低影响范围。

过滤器：

• pre 过滤器：可以在请求被路由之前调用。适用于身份认证的场景，认证通过后再继续执行下面的流程。

• route 过滤器：在路由请求时被调用。适用于灰度发布的场景，在将要路由的时候可以做一些自定义的逻辑。

• post 过滤器：在 route 和 error 过滤器之后被调用。这种过滤器将请求路由到达具体的服务之后执行。适用于添加响应头，记录响应日志等应用场景。

• error 过滤器：处理请求发生错误时被调用。在执行过程中发送错误时会进入 error 过滤器，可以用来统一记录错误信息。

Zuul 的路由4种方式：

1. 配置的是域名的话，就相当于集中式的负载均衡了
2. 配置多个 URL 负载均衡，本质上还是使用了 Ribbon 来进行负载均衡，所以我们需要通过配置 Ribbon 的 servers 来做负载。
3. 为所有请求加前缀，增加 zuul.prefix=/openapi配置
4. 在 Zuul 中集成 Eureka，在路由转发时可以转发到 Eureka 中注册的服务上，这样就很方便了，不需要我们去关心服务的上下线。

Zuul 自定义过滤器：

Zuul 容错与回退：

Spring Cloud 中，Zuul 默认整合了 Hystrix，我们需要在 Zuul 中实现 FallbackProvider 这个类来实现回退逻辑。

Zuul 小经验分享：

当 @EnableZuulProxy 与 Spring Boot Actuator 配合使用时，Zuul 会暴露一个路由管理端点 /routes。借助这个端点，可以方便、直观地查看以及管理 Zuul 的路由。

在浏览器中访问 /actuator/routes 端点，可以看到当前网关中的路由信息，映射的 URL 和对应的转发地址或者是转发的服务 ID。

除了 routes 端点可以查看路由信息，还有一个 /filters 端点可以查看 Zuul 中所有过滤器的信息。可以清楚的了解 Zuul 中目前有哪些过滤器，哪些被禁用了等详细信息。

请求响应输出：

熟悉 Zuul 的朋友都知道，Zuul 中有 4 种类型过滤器，每种都有特定的使用场景，要想记录响应数据，必须是在请求路由到了具体的服务之后，返回了才有数据，这种需求就适合用 post 过滤器来实现。在过滤器中获取请求的信息和响应的数据进行输出，这个操作需要有开关可以动态调整，否则在高并发下会影响性能。

Zuul Debug：Zuul 中自带了一个 DebugFilter，会将执行过程中的一些信息记录起来，方便调试和问题排查，我们可以通过配置 zuul.include-debug-header=true 来开启这个 Debug 模式，然后在访问请求的时候，在后面追加一个 debug=true 的参数告诉 Zuul 当前请求的调试信息需要通过响应头进行输出，这样在这个请求的响应头中就有了 Debug 相关的信息。

关闭 zuul 全局路由转发:uul.ignored-services=* 关闭

动态过滤器:Groovy