1、传统单体架构 基于session的权限校验
1、保存用户信息 到 服务器内存,用于会话保持
2、jsessionId存储到浏览器的cookie里，登录后每次访问都要 带上这个，与用户信息绑定,如果jsessionId被人盗取,容易遭受csrf 跨域攻击。
3、如果登录用户过多, 服务内保存的session信息 占用内存较大
2、分布式session
由于项目组件的变大，往往会把 应用部署多份，再用nginx 做负载均衡，提高系统的并发量。
这时 由服务器来 存储session 就会出现出现问题：
- 第一次登录请求 负载均衡到 tomcat1 , 登录成功,.将会话信息保存在tomcat1
- 第二次请求 负载均衡到tomcat2, tomcat2没有存有会话信息,会被认为是 没有登录。
接下来就引入了 分布式session的 方案：
不讲 session信息存储在 服务器内部,引入第三方中间件如redis,mongodb,将session统一放到 第三方中间件这里，然后 再统一从 这取。
3、微服务项目 基于 Oauth2.0 的权限校验
3.1、权限校验方案
3.1.1、只在网关层做权限校验
因为在微服务应用中,网关是 系统 所有流量的入口。在网关中 进行权限校验，理论上是可行的。
当请求携带登录返回的token时, 请求网关, 由网关来 向认证服务器 发起 校验token 的请求。
- 如果认证服务器返回校验通过,则 继续路由到下游服务器
- 校验不通过, 则直接 返回 无权限。
ip白名单校验
但是这样还有一个很重要的问题, 就是下游服务 不做权限校验的话，那么 下游服务 的接口 就完全相当于裸奔的, 别人知道下游服务的接口地址，就可以直接调用, 非常的危险。
所以，在这种方案中,一般 还会加上ip白名单校验, 下游服务 只允许 网关 发过来的请求,其他 来源不明的请求,直接在防火墙 拦截调。以保证, 下游服务的接口 只能网关转发过来并且 是 网关鉴权通过的。
3.1.2、只在下游服务做权限校验。
理论上 网关 服务器是不需要进行权限校验的，因为 zuul 服务器没有接口， 不需要从 网关 调用业务接口，网关 只做简单的路由工作。下游系统在获取到 token 后，通过 过滤器把 token 发到认证服务器校验该 token 是否有效，如果认证服务器校验通过就会携带 这个 token 相关的验证信息传回给下游系统，下游系统根据这个返回结果就知道该 token 具 有的权限是什么了。
这种方式 不会有 接口裸奔的风险, 也不用加ip白名单校验,更可以 进行方法级别的校验,粒度更细。
3.2、缺点
不管 是只在网关层做权限校验,还是只在下游服务做权限校验,在oauth2.0的权限校验模型中, 所有 校验token的过程,都需要与 认证服务器 进行一次 交互, 这点 不太好,多了一次 网络请求。
