Appearance
商城认证服务怎么拆分更稳
先说结论
- 认证中心优先只做身份校验、令牌签发、刷新和登出，不要把所有用户域能力都塞进来
- 用户资料、会员等级、地址簿、组织权限这类领域信息，应该回到各自服务维护
- 网关和服务内部只保留必要的认证校验，权限详情尽量做缓存，避免每次请求都回源查库
一、先拆清楚三条边界
1. 身份认证边界
它解决的是“这个用户是谁”。
典型能力包括：
- 用户名密码、短信、验证码、第三方登录
- Access Token / Refresh Token 签发与刷新
- 登出、令牌失效、设备会话管理
2. 业务用户边界
它解决的是“这个用户在商城体系里拥有什么业务属性”。
比如：
- 会员等级
- 用户积分
- 收货地址
- 账号绑定关系
- 黑白名单状态
这些数据变化频率、读写场景和一致性要求都和认证中心不同，放到一个服务里通常会越做越重。
3. 权限与资源访问边界
它解决的是“这个身份能访问什么资源”。
如果你是中后台系统，权限往往更复杂；如果你是面向 C 端商城，权限模型反而更轻，更多是：
- 是否登录
- 是否实名
- 是否有某类活动资格
- 是否属于某类用户分群
二、一个更稳的落地方式
对大多数商城项目，我更推荐下面这条链路：
- 认证服务负责登录、签发 token、刷新 token、登出。
- 网关做统一鉴权，解析 token，补充最小身份上下文。
- 业务服务根据用户 ID 读取自己的领域数据，不要求认证中心代查一切。
- 权限或用户态扩展信息放缓存，避免每次请求都串到认证中心。
这样拆的好处是：
- 认证中心职责更稳定
- 用户域演进不会频繁影响登录链路
- 故障影响面更小
- 网关和服务内部都更容易做降级
三、登录态怎么存更合适
1. Access Token 尽量短、信息尽量少
Token 里更适合只放：
- 用户 ID
- 设备标识
- 会话版本
- 少量稳定角色信息
不要把完整权限树、会员信息、组织树一股脑塞进 token。
这会带来两个问题：
- token 膨胀
- 业务字段变化后难以及时失效
2. 刷新与登出要有可控状态
如果你完全走无状态 JWT，登出和强制下线会比较难做。更常见的稳妥方案是：
- Access Token 保持短周期
- Refresh Token 或会话版本放 Redis
- 登出、改密、封禁时通过版本号失效
这样能在性能和可控性之间取得平衡。
四、最常见的几个坑
1. 把认证服务做成“万能用户中心”
最后任何用户相关查询都打到认证服务，登录链路和资料查询链路互相干扰，压力很难隔离。
2. 每个请求都远程校验权限
权限中心一慢，所有业务接口一起抖。更稳的做法是把高频权限结果放本地缓存或 Redis，并配合版本号失效。
3. 在 token 里放太多动态业务字段
字段一改就得重新签发，用户状态变更也不容易即时生效。
4. 登录流程和用户资料写入绑太紧
注册、首登补资料、拉会员信息、发优惠券都塞到登录主链路里，最后登录接口会越来越重。
五、上线时至少要盯的指标
- 登录成功率
- token 刷新成功率
- 网关鉴权 RT
- Redis 会话命中率
- 认证服务 5xx 和限流次数
如果这些指标没有拆开看，认证问题很容易和业务接口问题混在一起。
总结
商城认证服务最稳的拆法，不是做得越大越全越好，而是把身份、业务用户和权限边界分开：认证中心负责身份，业务服务负责领域数据，权限结果尽量缓存化。这样后面无论是扩容、排障还是能力演进，都会轻很多。