排查结果表明JWT集中过期和重新生成时候使用RSA算法进行签名是CPU密集型操作，同时重新生成大量JWT会导致服务所在机器的CPU超负载工作。初步的解决方案是：
JWT生成的时候，过期时间添加一个随机数，例如360000(1小时的毫秒数) ~ 8640000(24小时的毫秒数)之间取一个随机值添加到当前时间戳加7天得到exp值
这个方法，对于一些老用户营销场景（老用户长时间没有登录，他们客户端缓存的JWT一般都已经过期）没有效果。有时候运营会通过营销活动唤醒老用户，大量老用户重新登录有可能出现爆发性大批量重新生成JWT的情况，对于这个场景提出两个解决思路：
首次生成JWT时候，考虑延长过期时间，但是时间越长，风险越大
提升API网关所在机器的硬件配置，特别是CPU配置，现在很多云厂商都有弹性扩容方案，可以很好应对这类突发流量场景
小结主流的JWT方案是JWS，此方案是只编码和签名，不加密，务必注意这一点，JWS方案是无状态并且不安全的，关键操作应该做多重认证，也要做好黑名单机制防止JWT泄漏后造成安全性问题。JWT不存储在服务端，这既是它的优势，同时也是它的劣势。很多软件架构都无法做到尽善尽美，这个时候只能权衡利弊。