单体架构时我们只需要完成一次用户登录、身份校验，就可以在所有业务中获取到用户信息。而微服务拆分后，每个微服务都独立部署，不再共享数据。也就意味着每个微服务都需要做登录校验，这显然不可取。
1.1.鉴权思路分析
我们的登录是基于JWT来实现的，校验JWT的算法复杂，而且需要用到秘钥。如果每个微服务都去做登录校验，这就存在着两大问题：
-
每个微服务都需要知道JWT的秘钥，不安全
-
每个微服务重复编写登录校验代码、权限校验代码，麻烦
既然网关是所有微服务的入口，一切请求都需要先经过网关。我们完全可以把登录校验的工作放到网关去做，这样之前说的问题就解决了：
-
只需要在网关和用户服务保存秘钥
-
只需要在网关开发登录校验功能
不过，这里存在几个问题：
-
网关路由是配置的，请求转发是Gateway内部代码，我们如何在转发之前做登录校验？
-
网关校验JWT之后，如何将用户信息传递给微服务？
-
微服务之间也会相互调用，这种调用不经过网关，又该如何传递用户信息？
这些问题将在接下来几节一一解决。
2.2.网关过滤器
登录校验必须在请求转发到微服务之前做，否则就失去了意义。而网关的请求转发是Gateway内部代码实现的，要想在请求转发之前做登录校验，就必须了解Gateway内部工作的基本原理。
如图所示：
-
客户端请求进入网关后由
HandlerMapping对请求做判断，找到与当前请求匹配的路由规则（Route），然后将请求交给WebHandler去处理。 -
WebHandler则会加载当前路由下需要执行的过滤器链（Filter chain），然后按照顺序逐一执行过滤器（后面称为**Filter**）。 -
图中
Filter被虚线分为左右两部分，是因为Filter内部的逻辑分为pre和post两部分，分别会在请求路由到微服务之前 和之后被执行。 -
只有所有
Filter的pre逻辑都依次顺序执行通过后，请求才会被路由到微服务。 -
微服务返回结果后，再倒序执行
Filter的post逻辑。 -
最终把响应结果返回。
如图中所示，最终请求转发是有一个名为NettyRoutingFilter的过滤器来执行的，而且这个过滤器是整个过滤器链中顺序最靠后的一个。如果我们能够定义一个过滤器，在其中实现登录校验逻辑，并且将过滤器执行顺序定义到 NettyRoutingFilter 之前，这就符合我们的需求了！
那么，该如何实现一个网关过滤器呢？
网关过滤器链中的过滤器有两种：
-
GatewayFilter：路由过滤器，作用范围比较灵活，可以是任意指定的路由Route. -
GlobalFilter：全局过滤器，作用范围是所有路由，不可配置。