一、网关登录校验

1.1 问题描述

单体架构时我们只需要完成一次用户登录、身份校验，就可以在所有业务中获取到用户信息。

登录生成jwt，前端请求时在请求头携带jwt令牌发送给后端，后端使用拦截器拦截请求，判断jwt令牌是否合法，并把jwt解析得到的用户信息(比如用户id)存入threadlocal，然后各个业务就能读取到用户信息了（如用户id）

但是在微服务架构中，很多业务服务都不是在同一台机器上的，各个服务之间是不能直接共享数据的，如果要实现登录校验，难道要在没一个服务上面都写一遍拦截请求判断jwt令牌是否有效的逻辑吗? 这显然是不合理的

1.2 解决思路

思考过程：每个服务本质上就是一个或者多个请求的入口，登录校验其实也就是在请求入口处做校验，既然在每个服务入口上都要写一遍校验逻辑不合理，那么我们是不是在客户端和各种服务之间在写一个或者找“入口”，所有客户端在发请求的时候都要先经过这个“入口”，然后在由这个入口通向具体的微服务，这样我们就只需要在这个“入口”写上我们的校验逻辑就好了。事实上，这个入口已经有技术写好了——网关。

思考

既然网关是所有微服务的入口，一切请求都需要先经过网关。我们完全可以把登录校验的工作放到网关去做，这样之前说的问题就解决了。

那么现在剩下的问题就变成：

• 网关路由是配置的，请求转发是Gateway内部代码，我们如何在转发之前做登录校验？

• 网关校验JWT之后，如何将用户信息传递给微服务？

• 微服务之间也会相互调用，这种调用不经过网关，又该如何传递用户信息？

再思考

从网关到微服务，其实也就是一次新的http请求，所以在网关把请求转发给微服务的时候，只要把用户信息放到请求头里也就可以把用户信息传递给微服务了

而不同微服务之间如何传递用户信息呢?

微服务之间的相互调用其实是根据RPC(远程调用)实现的，其底层也还是发请求来实现的，所以微服务直接的用户信息传递也是可以把用户信息放到请求头里传递过去的

解决思路是一样的，只不过也跟是从网关到微服务，一是微服务到微服务。使用的技术实现不一样。

最终问题变成

如何在网关里自定义过滤器，并且控制过滤器的顺序

在网关中自定义过滤器

如何在网关中编写登录校验的逻辑

在过滤器中网关过滤器中，实现登录逻辑校验就好，跟单体项目的拦截器逻辑校验一样，只不过写到了网关过滤器中而已。

如何把网关中得到的用户信息传递给微服务

在网关过滤器中，把用户信息放入交换对象中，最后把交换对象放入下一个过滤链，最终最终交换对象会

微服务中如何实习用户信息传递