今天聊一個互聯網最特殊的中間件--網關，特殊是因為它與其它中間件相比！

如果你簡曆上寫你懂網關，那麼鑒權設計是必問的問題，接下來我們一點點分析鑒權設計時的思考！

在思考前先了解下幾個問題：

1.什麼是網關

2.網關有什麼特殊性

網關是應用的所有流量入口，是分布式高性能中間件，具有屏蔽内部邏輯，請求轉發，用戶鑒權，負載均衡，反作弊的能力！

1.具有高性能

網關的高性能與其它中間件要求都要高，能提升一點點就要提升一點！我們後面講功能設計時會扣這個細節。

2.高可用

分布式場景下必備技能，網關也不例外

3.可擴展

也是分布式場景必備技能，要想能夠方便快速擴展，那麼無狀态設計是最容易擴展的，在功能設計時盡可能的無狀态化設計

正常流程：用戶訪問應用時，通過網關做用戶鑒權，如果沒有鑒權需要跳轉登錄，登錄完存儲鑒權信息，下次在訪問時攜帶鑒權信息，鑒權通過直接轉發應用系統，如果鑒權失敗則直接返回。我們都知道鑒權信息應該存儲在服務端，其中思考：用戶鑒權的信息應該如何存儲？

第一種方案

根據用戶的鑒權信息指定在某一個網關交互，這種方案叫Session綁定。看上去這種方案沒有毛病，别忘了還可用性和擴展性。

解決可用性問題唯一的辦法就是副本冗餘，當發生擴容時原來的計算都會失效。很顯然這種方案不靠譜

第二種方案

為了解第一種方案，我們在把網關的鑒權信息相互複制，每個網關存儲所有的數據。這種方案與上一個方案來講，由于每個網關存儲所有的鑒權信息，不依賴于某一個網關。這種方案如果規模小的時沒毛病，但當集群大了會造成數據風暴，這種方案也不靠譜。

第三種方案

繼續優化第二種方案，如果每台都存儲那麼會引發數據風暴，那麼把數據下沉到中間件，由緩存redis 承接。以正常的應用設計方案來說都是這麼設計的，為了數據共享把數據由緩存來承接。那這種方案應該沒有問題了吧！

這種方案對應用系統來說沒問題， 但對于網關來說會多一次網絡IO。對于高性能來說就不友好了，每次用戶請求都要訪問緩存這更不太靠普了。

第四種方案

繼續思考，還有沒有第四種方案呢？

（1）存儲到指定網關不行

（2）網關存儲所有數據不行

（3）下沉到緩存不行

（4）如果鑒權信息存儲到客戶端呢？

當用戶登錄後把鑒權信息存儲到客戶端并存儲到服務端的緩存Redis中，每次請求攜帶token，由網關隻做鑒權算法，當鑒權成功直接通過，如果鑒權失敗在請求緩存，如果緩存還失敗直接返回。

再看下高可用有沒有問題？ 網關隻是鑒權校驗的算法，不存在固化數據，屬于無狀态化設計，支持快速擴展

我們生産上網關是采用cookie token的方式做鑒權信息存儲。如果你有更好的方案，可以一起交流，如果這篇文章對你有用，麻煩關注點贊轉發，或關注公衆号“猿碼”了解更多内容，感謝你的支持！

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!