微服务统一认证方案：Session 共享 vs Token 方案

你有没有想过这样一个问题：用户在你的电商网站登录了一次，为什么访问商品详情、购物车、订单列表这些不同的微服务，都能保持登录状态？

这不是因为每个微服务都「认识」这个用户，而是有一个统一的机制，让每个服务都知道「当前请求是谁发来的」。

这就是微服务认证要解决的核心问题。

问题的本质

在单体架构下，用户登录后信息存在应用服务器的 Session 中，后续请求带着 Cookie，服务端从 Session 取用户信息，一切都很自然。

但微服务架构下，一个请求可能经过网关、商品服务、订单服务、支付服务等多个节点。每个节点都是独立的进程、独立的应用服务器——Session 存在哪个节点？其他节点怎么知道用户已经登录了？

这就是分布式认证的起点。

方案一：Session 共享

最直接的想法是：既然 Session 不能存在单机，那就把它存到一个所有服务都能访问的地方。

Redis，成了天然的选择。

核心原理

用户登录 → 生成 Session → 存入 Redis
请求到达 → 各服务从 Redis 读取 Session → 获取用户信息

所有微服务都连接同一个 Redis，Session 数据天然共享。

优点

与单体应用架构一致，对现有代码改动小。Session 的生命周期管理（过期、销毁）由 Redis 处理，逻辑清晰。用户主动登出时，只需删除 Redis 中的 Session 即可。

缺点

跨域问题：Session 依赖 Cookie，Cookie 有域限制。如果你有 api.example.com 和 web.example.com 两个域名，需要设置 Cookie 的 Domain 为 .example.com，这对子域名有限制。

序列化开销：Session 数据需要序列化和反序列化。Java 默认的序列化效率低，换成 JSON 后又要处理类型丢失问题。

Cookie 大小限制：Cookie 本身有 4KB 限制。如果 Session 数据过大，存不进去。

性能瓶颈：每次请求都要访问 Redis，虽然是毫秒级，但在高并发下仍可能成为瓶颈。

适用场景

企业内部系统，微服务数量不多，团队对 Session 模式更熟悉。

方案二：Token 方案

Token 方案的核心思路完全不同：不要服务端存储，让客户端带着「身份证明」来访问。

JWT 的结构

最常用的是 JWT（JSON Web Token），它由三部分组成：

Header.Payload.Signature

• Header：存储算法和类型，{"alg": "HS256", "typ": "JWT"}
• Payload：存储用户信息、过期时间、签发者，{"userId": 123, "exp": 1699999999}
• Signature：用密钥对 Header 和 Payload 签名，防止篡改

三部分分别 Base64 编码，用 . 连接。

Token 的工作流程

用户登录 → 服务端生成 Token（签名）→ 返回给客户端
请求到达 → 验证 Token 签名 → 解析用户信息 → 处理请求

Token 存在客户端，每次请求放在 Header 里（通常是 Authorization: Bearer <token>）。

优点

无状态：服务端不存储 Token，任意节点都能验证。水平扩展友好，新增节点无需共享任何状态。

支持跨域：Token 放在 Header 里，不依赖 Cookie，自然支持跨域访问。

性能好：验证 Token 只是签名运算，不需要网络访问。

缺点

撤销困难：Token 在过期前一直有效。如果用户被禁用，传统方案无法让 Token 立即失效。

Payload 不能存敏感信息：Token 是 Base64 编码的，可被解码。虽然有签名防篡改，但内容是明文的，敏感信息不能放里面。

Token 体积：每次请求都要携带，比 Cookie 多一些网络开销。

适用场景

互联网应用，需要支持跨域、API 开放、水平扩展。

两种方案的对比

维度	Session 共享	Token
存储位置	Redis	客户端
状态	有状态	无状态
扩展性	需要 Redis 支持	天生可扩展
跨域支持	需要特殊处理	原生支持
撤销能力	立即生效	需要额外机制
性能	每次请求一次 Redis	纯本地计算
适用场景	企业内网	互联网应用

实际选型建议

选 Session + Redis：如果你的系统是传统企业应用，微服务数量不多，团队对 Session 模式更熟悉。Spring Session + Redis 的组合已经很成熟，能覆盖大部分场景。

选 Token：如果你是互联网应用，需要 API 开放、跨域支持、移动端登录，或者微服务数量很多、扩展频繁。JWT 是目前的主流选择。

一个常见的误区

很多人觉得 Token 比 Session 「更安全」，这是不对的。

两者只是存储位置不同，安全性取决于实现细节。Token 如果泄露，同样可以被冒用。Session 如果用 HTTPS + HttpOnly + SameSite，同样很安全。

真正需要关注的，是 Token 的有效期设置、敏感信息的保护、以及传输过程中的 HTTPS 加密。

面试追问方向

• Token 泄露了怎么办？（答：短期 Token + 黑名单机制）
• 如何实现 Token 的主动失效？（答：结合 Redis 黑名单或 Token 版本号）
• Session 和 Token 能否混合使用？（答：可以，Token 做认证，Session 做会话管理）

这些追问的答案，我会在后续的 JWT 无状态方案 和 分布式 Session 中详细展开。

微服务认证没有银弹，根据业务场景选对方案，比追新更重要。