[Feature Request] Cache token to improve performance 缓存Token来提高接口的性能

[MajorHe1]

ISSUE #9859 从token生成的角度来优化服务端的性能表现，取得了一定的效果，但是token的验证依然是非常耗时的。

在实际使用的场景中，默认 auth.enable = true 开启鉴权，客户端携带token访问服务端的查询接口（无论是配置发现还是服务发现），在服务端 4C8G的配置下，实测QPS都在两千上下。如果关闭鉴权，QPS在一万三左右。

鉴权这一块最主要的耗时是要验证token的合法性，需要解析token。
现在有一个简单的设想，如果把token缓存起来，直接内存字符串比对而不是解析，是不是就能大幅提升性能了？
实测，直接内存字符串比对，同等配置QPS接近关闭鉴权的效果。
并且，缓存token的方案，我们在生产上已经稳定运行了超过一年的时间。
跟@hujun-w-2 大佬对方案进行过简单的讨论和review，现在考虑发起社区讨论是否将这个能力提交给社区。

实现方案简述：

• 服务端缓存token；
• 服务端新增一个实体类TokenEntity，主要字段就是token string 和 token的过期时间；
• 服务端维护两个数据接口，一个 userMap<username, TokenEntity>，一个tokenMap<tokenStr, TokenEntity>;
• 当用户访问login接口时，若userMap里面存在该user，返回已经存在的token；否则，创建一个token返回，并将该token对应的TokenEntity存入userMap和tokenMap。（将token与username绑定，目的是大幅度减少新的token生成）；
• 当用户携带token访问服务端的接口时，判断tokenMap中是否存在该token，若存在，则直接返回；如果不存在，再转入原来的token解析流程，解析出来的token合法，就存入tokenMap（不要存userMap）再返回，不合法就返回AccessException；
• 服务端是以集群模式部署的，在token有效期内，一个服务端进程对同一个username颁发的token是一样的，userMap的最大元素数目等于在服务端login的账号数目，tokenMap的最大元素数目等于账号数目乘以服务端节点数；
• 服务端对定时扫描userMap和tokenMap，清除已经过期的token记录；

代码实现简述：
1、新增CachedJwtTokenManager 和 DelegateTokenManager
2、配置文件新增 nacos.core.auth.plugin.nacos.token.cache.enable字段开关，默认关。
3、原生NacosAuthManager中的tokenManager 的bean改成DelegateTokenManager
4、在DelegateTokenManager中进行cache开关判断。如果不开启，走原始的JwtTokenManager逻辑。如果开启，走CachedJwtTokenManager 逻辑。

方案缺陷：
缓存Token一定会带来额外的内存开销

请大家看一下这个方案是否有实现的必要，或者需要改进的地方，谢谢。

[hujun-w-2]

实测鉴权tps可以到9000，大约5倍提升，个人觉得方案可行

[KomachiSion]

前几天不是有PR和ISSUE对这块进行重构了吗？ 研究过那个了吗？

[MajorHe1]

前几天不是有PR和ISSUE对这块进行重构了吗？ 研究过那个了吗？

研究和讨论过，跟cache缓存的方案不冲突