1. 单体架构

• 最直接的方案, session就保存在 web-server 上

点击查看【processon】

2. 反向代理多服务架构

2.1 session同步方案

• 将session全量保存在 web-server 上
• 当session更新的时候,进行session更新, 同步修改其他所有web-server 上的session信息

  优点

1. 不需要修改任何业务代码

   缺点

2. session同步会有延迟

3. 消耗大量网络和CPU资源
4. 无法进行水平扩展, 服务增多用户量增多, 网络消耗会成几何数量增长

点击查看【processon】

2.2 session保存在cookies中

• 将session保存在客户端的cookies中

优点

1. web-server 不需要处理session的问题

缺点

1. 外网贷款占用太大
2. 安全问题得不到保障
3. 单个session内容大小受cookies限制

点击查看【processon】

2.3 反向代理hash一致性(四层, 七层)

• 通过hash算法, 将session进行分片, 存入不同的 web-server 中
• 有两种分片方式:
• 1. 在第四层协议进行分片, 通过IP分片(如nginx根据IP进行hash路由)
• 1. 在第七次协议进行分片, 应用层找个字段进行分片(如nginx根据HTTP请求中的某项属性进行hash路由)

优点

1. 只需要修改nginx配置,不需要修改应用代码
2. 支持 web-server 的水平扩展
3. 可以起到负载均衡的作用

缺点

1. web-server 重启会丢失一部分session
2. 如果 web-server 进行水平扩展, 会重新hash,相当于还是会导致一部分session丢失

点击查看【processon】

2.4 后端统一存储法

• 将session统一存在某个中间件中
• 可以是DB
• 可以是缓存, 建议使用缓存, session的数据丢失是可以接受的

优点

1. web层可以任意水平扩展
2. 上面几个方案的缺点都没了

缺点

1. 增加了一次网络调用
2. 多维护了一套session的存储设备, 经济上可能会贵一点
3. 需要自己来开发处理session的代码(比如shiro的处理)

点击查看【processon】

2.5 自建通用鉴权授权服务

• 自建一套统一的鉴权授权服务
• 这也是很多大公司的方案

优点

1. 业务系统几乎不需要改造, 只需要引入jar包, 或者标准化的增加filter即可

缺点

1. 需要专人开发一套鉴权授权系统, 成本较大

点击查看【processon】