今天聊一个互联网最特殊的中间件–网关,特殊是因为它与其它中间件相比!
如果你简历上写你懂网关,那么鉴权设计是必问的问题,接下来我们一点点分析鉴权设计时的思考!
在思考前先了解下几个问题:
1.什么是网关
2.网关有什么特殊性
网关是应用的所有流量入口,是分布式高性能中间件,具有屏蔽内部逻辑,请求转发,用户鉴权,负载均衡,反作弊的能力!
1.具有高性能
网关的高性能与其它中间件要求都要高,能提升一点点就要提升一点!我们后面讲功能设计时会扣这个细节。
2.高可用
分布式场景下必备技能,网关也不例外
3.可扩展
也是分布式场景必备技能,要想能够方便快速扩展,那么无状态设计是最容易扩展的,在功能设计时尽可能的无状态化设计
正常流程:用户访问应用时,通过网关做用户鉴权,如果没有鉴权需要跳转登录,登录完存储鉴权信息,下次在访问时携带鉴权信息,鉴权通过直接转发应用系统,如果鉴权失败则直接返回。我们都知道鉴权信息应该存储在服务端,其中思考:用户鉴权的信息应该如何存储?
第一种方案
根据用户的鉴权信息指定在某一个网关交互,这种方案叫Session绑定。看上去这种方案没有毛病,别忘了还可用性和扩展性。
解决可用性问题唯一的办法就是副本冗余,当发生扩容时原来的计算都会失效。很显然这种方案不靠普
第二种方案
为了解第一种方案,我们在把网关的鉴权信息相互复制,每个网关存储所有的数据。这种方案与上一个方案来讲,由于每个网关存储所有的鉴权信息,不依赖于某一个网关。这种方案如果规模小的时没毛病,但当集群大了会造成数据风暴,这种方案也不靠普。
第三种方案
继续优化第二种方案,如果每台都存储那么会引发数据风暴,那么把数据下沉到中间件,由缓存redis 承接。以正常的应用设计方案来说都是这么设计的,为了数据共享把数据由缓存来承接。那这种方案应该没有问题了吧!
这种方案对应用系统来说没问题, 但对于网关来说会多一次网络IO。对于高性能来说就不友好了,每次用户请求都要访问缓存这更不太靠普了。
第四种方案
继续思考,还有没有第四种方案呢?
(1)存储到指定网关不行
(2)网关存储所有数据不行
(3)下沉到缓存不行
(4)如果鉴权信息存储到客户端呢?
当用户登录后把鉴权信息存储到客户端并存储到服务端的缓存Redis中,每次请求携带token,由网关只做鉴权算法,当鉴权成功直接通过,如果鉴权失败在请求缓存,如果缓存还失败直接返回。
在看下高可用有没有问题? 网关只是鉴权校验的算法,不存在固化数据,属于无状态化设计,支持快速扩展
我们生产上网关是采用cookie+token的方式做鉴权信息存储。如果你有更好的方案,可以一起交流,如果这篇文章对你有用,麻烦关注点赞转发,或关注公众号“猿码”了解更多内容,感谢你的支持!