2.1.0版本，在集群模式下，使用nginx做负载后，控制台上的操作，实际上每一次请求经nginx转发后，每次都会请求到不同的服务端，
这个时候再去request.getSession()，实际上肯定获取不到，会导致操作失败，例如在控制台上修改密码的过程就会涉及到一行代码，
if (Objects.isNull(request.getSession().getAttribute(AuthConstants.NACOS_USER_KEY))) { return false; }
把request.getSession() 所有相关代码都做相应修改，集群模式下，不应从session中获取任何信息
一共有8处调用getSession()的地方，有两处是测试代码，有两处是往session里写对象，这4处都可用直接干掉，还有4处，经查都是从session中获取用户信息
在 nacos.core.auth.enabled=true 时，在控制台中操作，每一次请求都会带着 accessToken 这个参数，这是一个JWT，而jwt的第二段经base64 decode后也可以得到username, 所以说username的获取完全可以从jwt中得到，session也就可以全部干掉
集群模式下 nacos.core.auth.enabled=false 时，每一次请求是否都会带着 accessToken 这个参数还有待验证
也可以配置nginx的ip_hash的负载均衡策略来解决
老版本在 AuthFilter 里涉及 @Secured 注解的接口会走一遍 authManager.login(req)，login 实现里有 setSession 操作，所以每次拿 session 也没啥问题。 新版本改了这个逻辑，要用 session 的话可能要加上 setSession 操作。
因为老版本只有http接口， 新版本还有grpc接口，不能依赖于Request和Session。
我感觉保存到session中是个不太好的做法，会过于依赖某个体系导致不好扩展，最好的办法还是讲身份信息通过其他手段保存在一个上下文里