统一认证需由api网关前置实现，而非依赖apache会话保持；网关应统一完成身份识别、token解析与权限初筛，并通过标准header向下游注入可信用户信息，下游服务仅校验header并执行细粒度权限控制。
apache 本身不提供统一认证能力，会话保持（session sticky）只是让同一用户请求固定打到某个后端实例，它解决的是“状态路由”问题，而非“统一认证”问题。微服务拆分后，真正的认证难题在于：用户一次登录，如何让所有服务都能可信识别其身份，且不依赖单点 session 存储或重复校验。
会话保持 ≠ 统一认证
Apache 的 mod_proxy_balancer 支持基于 Cookie 或 IP 的会话粘滞，例如：
-
Cookie 模式：Apache 插入
ROUTEIDCookie，将请求绑定到特定 Tomcat 实例； - IP Hash：按客户端 IP 哈希分配后端，适合无 Cookie 场景。
但这只是把“有状态的 Session”从应用层转移到了负载均衡层，并未消除认证逻辑分散、Token 不互通、跨服务鉴权缺失等本质问题。一旦某实例宕机，粘滞失效，用户仍需重新登录——这恰恰暴露了它不是认证方案，而是临时兼容手段。
真正解决统一认证，得靠网关层收敛
微服务架构下，认证应前置到 API 网关，由网关统一完成身份识别、Token 解析、权限初筛，并将可信用户信息（如 user_id、roles）以标准 Header 注入下游服务。例如：
- 用 Apache APISIX + openid-connect 插件 对接 Authing 或 Keycloak，自动完成 OAuth2.0/OpenID 流程，解析 ID Token 后注入
X-User-ID、X-Roles； - 用 Sa-Token Same-Token 在网关校验 Token 合法性，生成轻量级内网调用凭证，供下游服务间 RPC 调用时快速验签，无需查 Redis；
- 若仍用 JWT，网关解析后可缓存用户基础信息到本地线程变量或轻量上下文，避免每次转发都重解析。
下游服务只需信任网关，不再各自认证
服务内部不再处理登录、密码校验、Session 创建等逻辑，只做两件事：
Apache Superset 是一个广泛采用的开源 BI 平台，用于 SQL 探索、图表构建和仪表板交付。当代理需要查询仓库数据、组装仪表板或使用成熟的分析界面解释指标而不是临时笔记本代码时，此技能非常有用。
- 检查网关注入的 Header 是否存在且格式合法（如非空、base64 可解、签名有效）；
- 根据 Header 中携带的用户标识和角色，执行细粒度权限控制（如 Sa-Token 的
StpUtil.hasRole("admin")）。
这样既解耦了认证职责，又避免了每个服务连 Redis 或调 Auth 服务带来的性能瓶颈和单点风险。
补充：Redis 分布式 Session 是过渡方案，非终极解法
在未上云原生网关的老系统中，确实常用 Apache + Redis 实现 Session 共享：Tomcat 配置 RedisHttpSessionConfiguration，把 Session 写入 Redis，各节点读取同一份数据。但它有明显短板：
- Redis 成为全链路认证的性能瓶颈和故障放大点；
- 无法天然支持服务间调用鉴权（RPC 请求不带 Cookie）；
- Token 过期、强制下线需主动清理 Redis，实时性难保障。
所以它适合平滑迁移阶段，而不该作为微服务长期认证主干。
