面经策

SSO 系统中，如果认证中心挂了怎么办？如何保证已登录用户不受影响？ ​

  • 标签：后端、系统设计、场景题、单点登录

🏛 业务架构师 ​

认证中心挂了怎么保证已登录用户不受影响——这道题的答案分两半：已登录会话不回源（架构设计）+ 认证中心自身高可用（基础设施），最后讲恢复期的洪水问题。

一、已登录用户不受影响（架构核心：登录态验证去中心化）

方案：网关本地验签（JWT 路线）

  • 认证中心只在登录时刻参与（签发 JWT）；之后每个请求由网关/各系统本地验签（签名校验不需要认证中心在线）
  • 认证中心挂掉：已登录用户完全无感，只有"新登录"和"登出"受影响

方案：会话缓存的本地化兜底（session 路线）

  • 子系统不实时回源认证中心校验会话，而是本地缓存会话结果（有效期 5 分钟~1 小时）
  • 认证中心挂掉期间，缓存内的会话继续有效；代价是"踢人/登出"传播延迟到缓存过期——可用性和实时可控性的权衡，按业务风险定缓存时长

二、认证中心自身高可用（它必须按最高标准建）

  • 同城双活：两机房同时服务，数据库层面同步（登录态写多活存储或单元化）
  • 无状态设计：会话存 Redis 集群/独立存储，认证中心实例随时扩缩容
  • 认证中心是全公司单点，SLA 要求高于任何业务系统（99.99%+），预算优先级也该最高

三、恢复期的洪水问题（容易被忽略的二次事故）

认证中心恢复瞬间，积压的"新登录请求"集中涌入（用户不停重试、客户端重试风暴）——

  • 登录接口限流 + 排队，恢复要缓（慢慢放量）
  • 熔断器半开状态试探性放流量

收尾（验收标准）：我衡量认证体系的标准是"认证中心整体宕机 30 分钟，已登录用户的交易成功率零波动"。达不到，说明存在隐性回源（每请求查认证中心的用法），把它找出来改掉——这靠定期故障演练验证，不靠自信。

🏗 系统架构师 ​

认证中心（SSO）宕机是致命场景：登录不了是小事，把已登录用户踢掉线、拖垮全站是大事。我按可用性设计与降级预案分层。

1. 事前：认证中心自身高可用

  • 集群 + 负载均衡：无状态服务多实例（会话与 code 存 Redis 集群），任意节点挂掉不影响
  • 多机房部署：同城双机房 + GSLB 接入，机房级故障自动切换
  • 依赖降级链：Redis 挂 → 会话降级到本地缓存/DB；DB 挂 → 只读模式（已登录用户不受影响，新登录暂停）

2. 已登录用户为什么不受影响（设计要点，题眼） 关键在token 的验证路径不经过认证中心：

  • JWT 方案：各子系统用本地缓存的公钥（JWKS）自行验签，认证中心挂了，JWT 在有效期内照常可用——这是我把 access token 设计成 15 分钟自包含 JWT 的原因
  • 长会话靠 refresh token 续期：续期接口不可用期间，业务请求不受影响（access token 未过期），只是"过期后无法续期"
  • 传统 session 方案：各子系统有本地会话，登录态校验不依赖认证中心，同理不受影响

3. 影响面收敛（挂了会影响什么）

  • 新登录/登出：不可用——登录页降级为"维护中"提示 + 排队重试
  • token 续期：暂停，已登录用户在 access token 过期前无感
  • 跨系统首次跳转（需要去认证中心领 code）：不可用 明确这个边界后，故障公告与降级动作就清晰了

4. 降级预案（预案要能执行）

  • 静态降级页：登录入口挂维护页，避免用户反复重试打挂恢复中的服务
  • 延长 token 有效期开关：故障期间网关把 access token 校验放宽（比如过期 + 30 分钟内仍放行）——预留这样的应急开关，用配置中心一键开启
  • 只读模式：注册、改密等写操作暂停，登录恢复后补偿
  • 第三方登录（微信/企业微信）可作为降级通道：主认证不可用时引导用户走三方登录（如果账号体系打通）

5. 演练：认证中心宕机是必须每季度演练的剧本，验证"已登录用户零感知、新登录有兜底、恢复后自动续期"三件事。核心思想：验签本地化，把认证中心从关键路径上摘出去。

💻 全栈开发专家 ​

核心思路：让"已登录"不依赖认证中心活着——令牌自包含 + 会话存储解耦 + 认证中心自身高可用。

第一层：已登录用户不感知（关键设计）

  • JWT 本地验签：子系统校验 token 只需公钥（启动时从 JWKS 端点拉取并本地缓存，定时刷新 5~10 分钟）。认证中心挂了，存量 token 照常验证，已登录用户完全无感。
  • 会话外置：若用集中会话，Session 存 Redis 集群（与认证中心部署解耦），认证中心宕机不影响 Redis；子系统读会话不经过认证中心。
  • token 有效期设计：access token 短（如 2 小时）+ refresh token（如 7 天）——只有"刷新"才需要认证中心，挂 10 分钟只影响需要续期的少数用户。

第二层：认证中心自身高可用

  • 无状态服务（登录态在 Cookie/Redis），K8s 多副本跨可用区 + HPA，前置 LB。
  • 依赖的 Redis 集群主从 + 哨兵/Cluster 模式，DB 主备。
  • 监控：登录成功率、QPS、RT、Redis 连接数，SkyWalking 链路覆盖登录链路。

第三层：降级策略

  • 新登录降级：认证中心全挂时新用户登录不了，挂出静态维护页 + 登录排队，别让错误裸奔。
  • 延长 token：极端故障时应急开关——子系统临时接受过期 token（风险窗口受控），保业务可用。
  • 本地兜底配置：JWKS 缓存持久化到本地文件，重启也能验签。

故障演练

定期演练认证中心宕机：验证存量用户访问正常、恢复后自动重连、refresh 积压不雪崩（限流恢复）。没演练过的降级设计等于没有。

一句话：JWT 让"验证"去中心化，Redis 让"会话"去中心化，认证中心只剩"发令牌"一个职责——职责越少，挂的影响越小。