网关的鉴权功能设计思考

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

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

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

1.什么是网关

2.网关有什么特殊性

1.什么是网关

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

2.网关有什么特殊性

1.具有高性能

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

2.高可用

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

3.可扩展

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

鉴权设计方案思考

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

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

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

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

第四种方案 继续思考，还有没有第四种方案呢？

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

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

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

本文由博客一文多发平台 OpenWrite 发布！