在springcloud架構中，實現授權功能有兩種實現方式：
很抱歉，看完這篇文章你也不一定能得到你想要的答案，因為結論是並沒有最優方案，兩種方案各有千秋，只有根據自身業務選擇對應的方案。本文我們將兩種方案做乙個簡單對比，以便大夥在做方案決策有個選擇參考。
首先我們看看兩種方案實現的原理：如果對具體實現方式有疑問的同學可以參考這篇文章：springcloud alibaba微服務實戰十九 - 整合rbac授權
基於閘道器授權我們又叫基於路徑匹配器授權，請求在經過閘道器的時候校驗當前請求的路徑是否在使用者擁有的資源路徑中。
在基於路徑匹配器授權時需要考慮restful風格的訪問路徑，如/account-service/blog/user/或/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欄位就可以解決。
如果你的系統規模比較大，有很多資源需要授權那就建議採用微服務授權模式，為了避免每個微服務都需要處理許可權校驗的邏輯，我們需要抽取乙個公共的許可權認證模組供後端服務引用。
微服務架構之 API閘道器
在微服務架構的系列文章中，前面已經通過文章 架構設計之 服務註冊 介紹過了服務註冊的原理和應用，今天這篇文章我們來聊一聊 api閘道器 api閘道器 是任何微服務架構的重要組成部分。有了它我們可以在乙個獨立的模組上方便的處理一些非業務邏輯，可以讓微服務本身專注在自身特定的功能上，使得每個微服務的開發...
微服務架構 BFF和閘道器
bff backend for frontend 和閘道器gateway是微服務架構中的兩個重要概念，這兩個概念相對比較新，有些開發人員甚至是架構師都不甚理解。本文用假想的公司案例 圖示的方式，解釋bff和閘道器是什麼，它們是怎麼演化出來的。希望對架構師設計和落地微服務架構有所啟發。我們先把時間推回...
微服務架構 去中心化的微服務閘道器
這篇文章主要還是想談如果僅僅是內部多個微服務模組間的介面服務整合，是否能夠實現一種去中心化的微服務閘道器，或者也可以理解為實現一種去中心化的輕量服務匯流排能力。要知道，在微服務模組間的介面服務呼叫中，涉及到安全，日誌，路由，監控，限流等能力，我們還是希望有乙個統一的微服務閘道器來處理。在前面的文章裡...