比来参预了公司 API Gateway 的搭建事情，技术选型是 Netflix Zuul，主要聊一聊此中的一些心得和体会。
本文主要是介绍使用 Zuul 且在不强制使用其他 Neflix OSS 组件时，如何搭建出产环境的 Gateway，以及能使用 Gateway 做哪些事。不筹算介绍任何关于如何快速搭建 Zuul，或是一些等闲集成 Eureka 之类的的要领，这些在官方文档上已经介绍的很明确了。
API GatewayAPI Gateway 是跟着微处事（Microservice）这个观点一起兴起的一种架构模式，它用于解决微处事过于分手，没有一个统一的收支口进行流量打点的问题。
用 Kong 官网的两张图来解释再合适不过。
当使用微处事构建整个 API 处事时，一般会有许许多多职责差此外应用在运行着，这些应用会需要一些通用的成果，例如鉴权、流控、监控、日志统计。
在传统的单体应用中，这些成果一般都是内嵌在应用中，作为一个组件运行。但是在微处事模式下，差别种类且独立运行的应用可能会有数十甚至数百种，继续使用这种方法会造成非常高的打点和颁布本钱。所以就需要在这些应用上抽象出一个统一的流量入口，完成这些成果的实现。
在我看来，API Gateway 的职责主要分为两部分：
对处事应用有感知且重要的成果，例如鉴权。
对处事应用无感知的边沿处事，例如流控、监控、页面级缓存等。
Netflix Zuul对付 API Gateway，常见的选型有基于 Openresty 的 Kong、基于 Go 的 Tyk 和基于 Java 的 Zuul。
这三个选型自己没有什么明显的区别，主要还是看技术栈是否能满足快速应用和二次开发，例如我司原有的技术栈就是使用 Go/Openresty 的平台组和使用 Java 的后端组，讨论后感受 API Gateway 未来还是措置惩罚惩罚业务成果的场景更多些，而且后端这边有很多成果可以直接移植过来，最终就选择了 Zuul。
关于 Zuul，大部分使用 Java 做微处事的人可能城市或多或少了解 Spring Cloud 和 Netflix 全家桶。而对付完全不了解的人，可以暂时将它想象为一个类似于 Servlet 中过滤器（Filter）的观点。
就像上图中所描述的一样，Zuul 供给了四种过滤器的 API，分袂为前置（Pre）、后置（Post）、路由（Route）和错误（Error）四种措置惩罚惩罚方法。
一个请求会先按挨次通过所有的前置过滤器，之后在路由过滤器中转发给后端应用，得到响应后又会通过所有的后置过滤器，最后响应给客户端。在整个流程中如果产生了异常则会跳转到错误过滤器中。
一般来说，如果需要在请求达到后端应用前就进行措置惩罚惩罚的话，会选择前置过滤器，例如鉴权、请求转发、增加请求参数等行为。在请求完成后需要措置惩罚惩罚的操纵放在后置过滤器中完成，例如统计返回值和挪用时间、记录日志、增加跨域头等行为。路由过滤器一般只需要选择 Zuul 中内置的即可，错误过滤器一般只需要一个，这样可以在 Gateway 遇到错误逻辑时直接抛出异常中断流程，并直接统一措置惩罚惩罚返回功效。
应用场景以下介绍一些 Zuul 中差别过滤器的应用场景。
前置过滤器 鉴权一般来说整个处事的鉴权逻辑可以很庞大。
客户端：App、Web、Backend
权限组：用户、后台人员、其他开发者
实现：OAuth、JWT
使用方法：Token、Cookie、SSO
而对付后端应用来说，它们其实只需要知道请求属于谁，而不需要知道为什么，所以 Gateway 可以友善的辅佐后端应用完成鉴权这个行为，并将用户的独一标示透传到后端，而不需要、甚至不应该将身份信息也通报给后端，防备某些应用操作这些敏感信息做错误的工作。
Zuul 默认情况下在措置惩罚惩罚后会删除请求的 Authorization 头和 Set-Cookie 头，也算是贯彻了这个原则。
流量转发流量转发的含义就是将指向 /a/xxx.json 的请求转发到指向 /b/xxx.json 的请求。这个成果可能在一些项目迁移、或是灰度颁布上会有一些用处。
在 Zuul 中并没有一个很好的步伐去改削 Request URI。在某些 Issue 中开发者会建议设置 requestURI 这个属性，但是实际在 Zuul 自身的 PreDecorationFilter 流程中又会被笼罩一遍。