在SpringCloud架構中，實現受權功能有兩種實現方式：html
-
在網關層進行受權java
-
由後端微服務本身受權spring
兩種方式在此係列文章中都有實現方案，那麼問題來了：哪一種纔是最優方案，哪一種方案更合理呢？後端
很抱歉，看完這篇文章你也不必定能獲得你想要的答案，由於結論是並無最優方案，兩種方案各有千秋，只有根據自身業務選擇對應的方案。本文咱們將兩種方案作一個簡單對比，以便大夥在作方案決策有個選擇參考。服務器
解決方案對比
首先咱們看看兩種方案實現的原理：若是對具體實現方式有疑問的同窗能夠參考這篇文章：
SpringCloud Alibaba微服務實戰十九 - 集成RBAC受權微信
網關受權
基於網關受權咱們又叫基於路徑匹配器受權，請求在通過網關的時候校驗當前請求的路徑是否在用戶擁有的資源路徑中。restful
在基於路徑匹配器受權時須要考慮restful風格的訪問路徑，如 /account-service/blog/user/{id} 或 /account-service/blog/**等，因此在網關進行受權主要是基於通配符匹配。架構
微服務受權
微服務受權咱們又叫基於方法攔截，在資源上打上對應的方法標識而後分配給用戶。在請求方法上經過對應的註解判斷當前用戶是否有訪問此方法的權限。如SpringSecurity中的 @PreAuthorize("hasAuthority('')")註解，Shiro中的 @RequiresPermissions('')註解。不論是SpringSecurity仍是Shiro他們實現原理都是基於關鍵字徹底匹配。微服務
優缺點對比
網關受權
優勢性能
使用網關受權的優勢很明顯，後端全部微服務只須要是普通的服務便可，再也不須要依賴權限那一套。
缺點
-
通配符匹配在網關作性能比較差，通配符要拆分，先匹配前綴，前綴匹配了再匹配通配符。這裏你們能夠看看
org.springframework.util.AntPathMatcher#doMatch()的實現邏輯。 -
對於Restful風格的URL路徑，不能精細化控制權限
例如一個微服務有以下API
GET /v1/pb/user
POST /v1/pb/user
PUT /v1/pb/user
這樣在網關經過request.getURI().getPath()方法獲取到用戶請求路徑的時候都是同一個地址，給一個用戶授予/v1/pb/user權限後他就擁有了GET、PUT、POST三種不一樣權限，很顯然這樣不能知足精細權限控制。至於如何解決這個問題，原來專門寫過一篇文章討論，感興趣的同窗能夠看看：SpringCloud Alibaba微服務實戰二十五 - Restful接口攔截
微服務受權
優勢：
上面提到網關受權的缺點其實是微服務受權的優勢，基於方法攔截是徹底匹配，cpu消耗不多，並且也不存在RestFul的問題。
缺點：
實現較爲複雜，在 SpringSecurity Oauth2體系中須要所有引入資源服務器相關配置，因此通常會創建一個單獨的資源服務器模塊，這也是系列文章下篇內容須要解決的問題。
結論
這裏咱們嘗試對兩種實現方案作一個總結，若是系統功能、業務模塊不是不少能夠採用網關受權模式，這樣實現最簡單也最方便，雖然存在Restful風格不能精細化權限控制問題，可是咱們加一個Method字段就能夠解決。
若是你的系統規模比較大，有不少資源須要受權那就建議採用微服務受權模式，那爲了不每一個微服務都須要處理權限校驗的邏輯，咱們還須要抽取一個公共的權限認證模塊供後端服務引用。
以上，但願對你有所幫助！
本文分享自微信公衆號 - JAVA日知錄（javadaily）。
若有侵權，請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」，歡迎正在閱讀的你也加入，一塊兒分享。