到目前为止已经实现了一个基于微服务的,前后端分离(这里我用的jquery做的,并不是真的前后端分离,因为我不会vue和angular所以没用)的架构。在网关上做了限流、认证、审计、授权等安全机制,在前端应用上也做了SSO单点登录,

现在的架构存在的问题是:

1,在网关做限流。

  在网关上做限流是有问题的,比如订单服务限流是100,库存服务限流也是100,订单服务又调了库存服务。如果网关上给订单转了100个请求,给库存转了100个请求,订单又调了库存,这时候库存就同时接到了200个请求,库存服务就可能挂掉了。

2,身份认证。

  现在的做法是,经过了一个OAuth流程以后,给前端服务器发了一个令牌。每次前端发请求的时候都会拿着这个令牌,在网关上,会调用认证服务器校验这个令牌,对应的用户信息是什么。然后在请求头里放了username,去调用其他微服务,其他微服务从请求头里获取到username,就知道当前用户是谁了。

  存在的问题是

  a) 效率低,在网关上每一个请求都要去认证服务器验令牌。多一次网络请求的开销,认证服务器压力也会变大,同时认证服务器要保证高可用,一旦认证服务器挂了,所有请求就没法验令牌了,所有请求就都没法处理了。

  b) 不安全,在代码里传递用户信息的时候,是在请求头里加了个用户名username字段,网关转发到订单服务,是在授权过滤器(最后一个过滤器)里,将token里的username字段放在了请求头,订单服务从请求头拿出来username,就认为是谁。这样其实是不安全的,你说你是张三,订单服务就认为你是张三,你说你是李四,订单服务就认为你是李四。【不能根据请求/请求头里的一个明文的参数来判断一个用户是谁的】  

  

 

 

   c)用户身份传递麻烦。网关调用订单服务,在请求头放了一个username,订单服务再调用库存服务,需要再将用户名放入请求参数,库存服务才能知道用户是谁,传递起来比较麻烦。

3,授权。

  授权的问题和限流的问题类似,在网关上,你控制住了只能调用订单服务,但是订单服务又调用了库存服务。你一访问订单服务实际上又访问到了库存服务了。权限实际上是越权了,没控制住。

4,服务雪崩

  通关网关进行调用的时候,当一个服务出现问题的时候,把其他服务都给带死了。比如因为某些原因(网络,数据库),库存服务的响应变慢了,就会导致订单服务也变慢,然后所有调库存服务的服务都变慢,这堆线程都在这等待着,然后这些线程可能又都是通过网关进来的,所以网关上也有一堆线程等待着,最后导致网关上所有的线程都被占住,导致大量的服务都不可用,但是最根上只是一个库存服务导致的。这就是服务雪崩。

本章就是要解决这些个问题。

 代码  https://github.com/lhy1234/springcloud-security

 

欢迎关注个人公众号一起交流学习: