微服务场景下采用数据库存储HttpSession的会话管理方案是否可行？

这个方案可以在小规模场景下跑通，但绝对算不上适合微服务的优秀方案，核心问题有这几点：

• 性能瓶颈突出：所有需要身份校验的请求都要先查一次会话库，QPS稍高就会让数据库成为全链路的性能卡点，哪怕加了缓存层，也比Token自校验的方案多了至少一次网络IO开销，后续水平扩展时还要额外投入成本优化会话存储的性能，性价比极低。
• 服务耦合严重：所有需要做鉴权的微服务都直接依赖会话库的读写能力，相当于把全链路的可用性和这个数据库绑定，一旦会话库宕机，所有业务服务都无法正常处理请求，完全不符合微服务高内聚、低耦合的设计原则。
• 安全风险更高：会话ID本身只是无签名的随机字符串，没有任何校验信息，一旦会话库被拖库，攻击者拿到任意合法的sessionid+用户名组合就能直接仿冒用户身份，而且大量非法请求的校验请求会直接打向数据库，很容易被攻击者利用做DDoS攻击。
• 维护成本极高：后续如果要新增权限字段、动态调整会话过期规则、接入第三方登录能力，都需要修改会话表结构，所有依赖会话库的服务都要同步适配，迭代效率很低。

微服务没有强制要求必须无状态，无状态只是行业普遍认可的最佳实践：

• 无状态的服务不需要依赖本地存储的会话数据，任意实例都可以对等处理用户请求，水平扩展时不需要做额外的数据同步，扩容成本几乎为零，故障转移时也不会出现用户会话丢失的问题，这也是Token类鉴权方案在微服务领域普及的核心原因。
• 如果你确实有强一致的会话管控需求，比如要支持实时踢人、全局会话查询，更推荐用Redis这类集中式缓存存储会话，性能比关系型数据库高很多，但依然要承担缓存层的可用性风险，整体维护成本还是远高于自包含的Token鉴权方案。

如果你的业务规模很小，服务节点只有2、3个，你描述的方案可以临时凑合用；如果有明确的水平扩展需求、对服务可用性要求高，优先选择JWT这类Token鉴权方案，需要登出能力的话配合短AccessToken+长RefreshToken的机制就能覆盖需求，没必要自己维护独立的会话存储。

内容的提问来源于stack exchange，提问作者Sara