Java教程

网关的鉴权功能设计思考

本文主要是介绍网关的鉴权功能设计思考,对大家解决编程问题具有一定的参考价值,需要的程序猿们随着小编来一起学习吧!

今天聊一个互联网最特殊的中间件–网关,特殊是因为它与其它中间件相比!

如果你简历上写你懂网关,那么鉴权设计是必问的问题,接下来我们一点点分析鉴权设计时的思考!

在思考前先了解下几个问题:

1.什么是网关

2.网关有什么特殊性

1.什么是网关

网关是应用的所有流量入口,是分布式高性能中间件,具有屏蔽内部逻辑,请求转发,用户鉴权,负载均衡,反作弊的能力!

2.网关有什么特殊性

1.具有高性能

网关的高性能与其它中间件要求都要高,能提升一点点就要提升一点!我们后面讲功能设计时会扣这个细节。

2.高可用

分布式场景下必备技能,网关也不例外

3.可扩展

也是分布式场景必备技能,要想能够方便快速扩展,那么无状态设计是最容易扩展的,在功能设计时尽可能的无状态化设计

鉴权设计方案思考

file

正常流程:用户访问应用时,通过网关做用户鉴权,如果没有鉴权需要跳转登录,登录完存储鉴权信息,下次在访问时携带鉴权信息,鉴权通过直接转发应用系统,如果鉴权失败则直接返回。我们都知道鉴权信息应该存储在服务端,其中思考:用户鉴权的信息应该如何存储?

第一种方案
根据用户的鉴权信息指定在某一个网关交互,这种方案叫Session绑定。看上去这种方案没有毛病,别忘了还可用性和扩展性。
解决可用性问题唯一的办法就是副本冗余,当发生扩容时原来的计算都会失效。很显然这种方案不靠普
file

第二种方案
为了解第一种方案,我们在把网关的鉴权信息相互复制,每个网关存储所有的数据。这种方案与上一个方案来讲,由于每个网关存储所有的鉴权信息,不依赖于某一个网关。这种方案如果规模小的时没毛病,但当集群大了会造成数据风暴,这种方案也不靠普。
file

第三种方案
继续优化第二种方案,如果每台都存储那么会引发数据风暴,那么把数据下沉到中间件,由缓存redis 承接。以正常的应用设计方案来说都是这么设计的,为了数据共享把数据由缓存来承接。那这种方案应该没有问题了吧!
这种方案对应用系统来说没问题, 但对于网关来说会多一次网络IO。对于高性能来说就不友好了,每次用户请求都要访问缓存这更不太靠普了。
file

第四种方案
继续思考,还有没有第四种方案呢?

(1)存储到指定网关不行
(2)网关存储所有数据不行
(3)下沉到缓存不行
(4)如果鉴权信息存储到客户端呢?

file

当用户登录后把鉴权信息存储到客户端并存储到服务端的缓存Redis中,每次请求携带token,由网关只做鉴权算法,当鉴权成功直接通过,如果鉴权失败在请求缓存,如果缓存还失败直接返回。
在看下高可用有没有问题? 网关只是鉴权校验的算法,不存在固化数据,属于无状态化设计,支持快速扩展

我们生产上网关是采用cookie+token的方式做鉴权信息存储。如果你有更好的方案,可以一起交流,如果这篇文章对你有用,麻烦关注点赞转发,或关注公众号“猿码”了解更多内容,感谢你的支持!

这篇关于网关的鉴权功能设计思考的文章就介绍到这儿,希望我们推荐的文章对大家有所帮助,也希望大家多多支持为之网!