Zuul 2 主体的架构跟 Zuul 1 差别不大。
协议
协议上支持 HTTP/2 和双向 TLS，并且实现了可配置的连接池。
灵活路由
用 Zuul 可以实现非常灵活的路由规则，可以基于根据 URL、query params 或者 HTTP 头做路由。这有一些实用场景：
- 一个服务需要区分不同用户（按地域或者其他条件），到不同的 origin
- 开发者可以把一些流量路由到调试集群，以观察高负载下应用程序是否优雅地降级（类似于腾讯喜欢说的「柔性服务」）
- 开发者发布多个成套的新服务时，可以让特定的用户路由到这套新的服务
- Canary testing or release
负载均衡
Zuul 实现了 adaptive retries，在 origin 返回 HTTP 503 或者连接失败时自动重试。
Zuul 可以用来实现一些特定的负载均衡规则。这里描述的能力可能不是 Zuul 本身就实现的，而是 Netflix 基于 Zuul 做的一些最佳实践：
- Cold instances: 新的 origin 实例上线时，应该慢慢给它导入新的流量，直到他们准备好。这是因为应用可能有懒加载的代码，JIT 也需要应用运行一段时间才达到最佳状态。一口气给它大量的流量，可能会引起服务不稳定。
- High error rates: 一旦一些 origin 实例的错误率提高到一个阈值，Zuul 会限制重试次数并且减少流量。
- Overloaded Instances: origin 在返回数据中添加头部信息，告诉 Zuul 它当前的利用率是多少百分比，以及期望的利用率是多少。Zuul 会根据这些数据来智能决策。这个利用率不限定是具体的机器指标，比如 CPU 密集型应用可以用 CPU 占用率，IO 密集型应用可以用 IO 数据。
调试能力
- Request Passport：一个请求的各种 lifecycle 事件，会被详细地纪录，比如前端请求到了 Zuul 的时间点，Zuul 将其转发到 origin 的时间点等。可以用来定位问题，比如后端超时、后端返回失败等
- Status Categories：比 HTTP 返回码粒度更细的状态码
- Request Attempts：Zuul 将转发过程的详细信息，通过 HTTP 头带给前端，方便定位问题