Spring Security 3.1.2迁移至6：多微服务升级与Redis token存储问询

一、迁移策略：优先选择分批迁移 #

20多个微服务全量迁移风险太高，分阶段推进更稳妥：

1. 先改网关，做双向兼容 #

网关是所有请求的入口，先把网关升级到Spring Boot3.1.4 + Spring Security6，同时保留对旧TokenStore格式的兼容：

• 新增JSON格式token的生成与解析逻辑，同时保留原TokenStore的读写逻辑
• 网关生成token时，同时往Redis写两份数据：一份是旧的JDK序列化格式（给未升级的老服务用），一份是新的JSON格式（给已升级的新服务用）
• 这样老服务不用动，依然能靠原有TokenStore读取token，新服务用新格式验证

2. 分批次迁业务微服务 #

按业务重要性或依赖关系，每次迁1-3个服务：

• 迁移时删掉原TokenStore相关依赖，改用Spring Security6的资源服务器配置，从Redis读JSON格式token做验证
• 迁完后立刻测该服务和网关、其他新旧服务的调用是否正常，没问题再迁下一批
• 所有服务迁完后，再把网关里的旧TokenStore兼容逻辑删掉，统一用JSON格式

3. 一次性迁移的前提 #

只有当业务能接受较长停机窗口，且全量测试覆盖100%的时候才考虑：

• 先停所有服务，把网关升级到新架构，同时批量把Redis里的旧TokenStore格式token转成JSON格式
• 然后全量升级所有微服务，启动后统一用新的JSON token验证
• 风险极大，一旦出问题全业务瘫痪，必须提前做好回滚预案

二、Redis存JSON格式token替代TokenStore：完全可行 #

Spring Security6支持自定义token验证逻辑，完全可以用JSON格式存在Redis里实现跨服务验证：

1. 设计JSON存储结构 #

Redis里的JSON要包含核心验证字段，比如：

{
  "token": "xxx-xxxx-xxxx",
  "username": "zhangsan",
  "roles": ["ADMIN", "ORDER"],
  "expireAt": 1700000000000,
  "clientId": "mobile-app"
}

• 用token值作为Redis的key，value存上面的JSON对象
• 设置和原token一致的过期时间，自动清理无效token

2. 新服务的验证实现 #

在Spring Security6的资源服务器配置里，自定义验证逻辑：

• 从请求头拿到token，去Redis查对应的JSON数据
• 先检查token是否过期，再验证当前请求的权限是否匹配用户角色
• 把验证通过的用户信息封装成Authentication对象，注入到Spring Security上下文里

3. 兼容期注意事项 #

• 网关必须同时生成两种格式的token，直到所有服务都迁完
• 老服务完全不用改，继续用原TokenStore逻辑读旧格式
• 全量迁移完成后，清理Redis里的旧格式数据，网关停止生成旧格式

三、核心注意点 #

• JDK8→21兼容：跨度很大，要检查代码里的JDKAPI，比如JAXB、JEE相关类，换成Spring提供的替代方案或者JDK21的新API
• Spring Security6配置变化：原有的AuthorizationServerConfigurerAdapter这类配置类已经被移除，要改用OAuth2AuthorizationServerConfigurer等新配置方式
• Redis序列化一致性：旧TokenStore用JDK序列化，新JSON用Jackson，要确保网关和新服务的序列化配置完全一致，避免读不出数据
• 测试要到位：每个迁完的服务都要测接口、权限、跨服务调用，别漏了边缘场景

内容的提问来源于stack exchange，提问作者Sreejesh