认证系统执行流程细粒度分析一、Session 认证演进1. 本地 Session单机模式┌─────────────────────────────────────────┐ │ Web Server │ │ │ │ User A ──→ Controller ──→ Session A │ │ User B ─→ Controller ──→ Session B │ │ │ │ │ ↓ │ │ service │ ─────────────────────────────────────────┘流程用户提交username passwordController 验证后创建 Session 存储在服务器内存返回 SessionID 给客户端Cookie问题多用户登录时服务器需创建多个 Session加大服务器开销2. Session 外置独立存储┌──────────────────┐ ┌──────────┐ │ Web Server │ │ Redis │ │ │ │ │ │ Controller ────→│────────→│ Session │ │ │ │ │ Session │ │ ↓ │ └────────── │ service │ └──────────────────┘流程用户登录 → Controller → ServiceSession 存储到外部 Rediskv:userId: user对象多服务器可共享 Session问题产生额外硬件成本Redis 宕机 →整个认证系统不可用单点故障二、Token 认证JWT 方案完整执行流程─────────┐ 登录请求 ┌──────────────┐ │ User A │ ────────────────→│ 认证系统 │ │ │ ←────────────────│ │ │ │ 返回 Token │ Token │ └────┬────┘ └──────────────┘ │ │ 3. Token 存入 Pinia │ │ 4. 请求微服务携带 Token ↓ ┌─────────────┐ │ Middleware │ ←── verify ──→ 认证系统 │ │ │ ├─→ 购物车系统 │ └─→ 订单系统 └─────────────┘细粒度流程分析阶段一登录认证1. 用户提交 {username, password} ↓ 2. 认证系统验证身份 ↓ 3. 生成 TokenJWT ↓ 4. Token 通过 Cookie 或 Response Header 返回前端阶段二前端存储1. 前端接收 Token ↓ 2. 存入 Pinia状态管理 ↓ 3. 后续请求自动携带 Token阶段三请求微服务1. 前端从 Pinia 取出 Token ↓ 2. 以 Request Header 方式发送到微服务 ↓ 3. Middleware 拦截请求 ↓ 4. 取出 Header 中的 Token 值 ↓ 5. 远程调用认证系统进行 Token 校验阶段四校验与鉴权4.1 Token None → 返回登录页 ↓ 4.2 Token ≠ None → verify() 校验防篡改 ↓ 4.3 校验成功 → 鉴权判断用户是否有操作权限 ↓ 4.4 鉴权通过 → 放行到目标服务购物车/订单三、Session vs Token 对比维度SessionTokenJWT存储位置服务器内存/Redis客户端 服务端校验扩展性差需共享存储好无状态单点故障Redis 宕机则不可用认证系统可集群跨域需处理 Cookie天然支持性能需查存储本地验签即可四、架构演进总结本地 Session → Session 外置 → TokenJWT 单机开销大 共享单点故障  无状态可扩展推荐方案微服务架构下使用Token Middleware 统一鉴权核心思想认证与业务解耦Middleware 统一处理 Token 校验微服务专注业务逻辑。
