认证系统执行流程细粒度分析
一、Session 认证演进
1. 本地 Session（单机模式）
┌─────────────────────────────────────────┐ │ Web Server │ │ │ │ User A ──→ Controller ──→ Session A │ │ User B ─→ Controller ──→ Session B │ │ │ │ │ ↓ │ │ service │ ─────────────────────────────────────────┘流程：
- 用户提交
username + password - Controller 验证后创建 Session 存储在服务器内存
- 返回 SessionID 给客户端（Cookie）
问题：多用户登录时，服务器需创建多个 Session，加大服务器开销
2. Session 外置（独立存储）
┌──────────────────┐ ┌──────────┐ │ Web Server │ │ Redis │ │ │ │ │ │ Controller ────→│────────→│ Session │ │ │ │ │ Session │ │ ↓ │ └────────── │ service │ └──────────────────┘流程：
- 用户登录 → Controller → Service
- Session 存储到外部 Redis（kv:
userId: user对象） - 多服务器可共享 Session
问题：
- 产生额外硬件成本
- Redis 宕机 →整个认证系统不可用（单点故障）
二、Token 认证（JWT 方案）
完整执行流程
─────────┐ 登录请求 ┌──────────────┐ │ User A │ ────────────────→│ 认证系统 │ │ │ ←────────────────│ │ │ │ 返回 Token │ Token │ └────┬────┘ └──────────────┘ │ │ 3. Token 存入 Pinia │ │ 4. 请求微服务（携带 Token） ↓ ┌─────────────┐ │ Middleware │ ←── verify ──→ 认证系统 │ │ │ ├─→ 购物车系统 │ └─→ 订单系统 └─────────────┘细粒度流程分析
阶段一：登录认证
1. 用户提交 {username, password} ↓ 2. 认证系统验证身份 ↓ 3. 生成 Token（JWT） ↓ 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 对比
| 维度 | Session | Token（JWT） |
|---|---|---|
| 存储位置 | 服务器（内存/Redis） | 客户端 + 服务端校验 |
| 扩展性 | 差（需共享存储） | 好（无状态） |
| 单点故障 | Redis 宕机则不可用 | 认证系统可集群 |
| 跨域 | 需处理 Cookie | 天然支持 |
| 性能 | 需查存储 | 本地验签即可 |
四、架构演进总结
本地 Session → Session 外置 → Token（JWT） （单机，开销大） （共享，单点故障）  （无状态，可扩展）推荐方案：微服务架构下使用Token + Middleware 统一鉴权
核心思想：认证与业务解耦，Middleware 统一处理 Token 校验，微服务专注业务逻辑。
