Spring Cloud微服務下的許可權架構調研
隨著微服務架構的流行，系統架構調整，專案許可權系統模組開發提上日程，需要對許可權架構進行設計以及技術選型。所以這段時間看了下相關的資料，做了幾個對比選擇。
一、架構圖
初步設想的架構如下，結構很簡單：eureka為服務註冊中心，config是服務配置中心，redis做為快取服務，gateway是後端閘道器。目前只設計了一套節點，考慮系統高併發高可用性後續可部署多套節點，Nginx做負載均衡以及增加熔斷、失敗重試等。系統流程為：客戶端請求經Nginx轉發到後端閘道器，閘道器直接轉發到許可權系統進行認證授權，統一在閘道器做鑑權，鑑權通過則轉發到對應微服務。
二、技術選型
① 使用者許可權
在傳統的單體應用中，很多專案用的是shiro，畢竟shiro功能強大又靈活。而在Spring Cloud微服務架構中，好像大家更喜歡用Spring Security，所以瞭解了一下這兩個框架的區別，大致如下：
- Shiro比Spring更容易使用、實現和理解。
- Spring Security更加知名是因為品牌名稱。
- 很多人發現Spring Security使用比較麻煩。
- Spring Security有更好的社群支援。
- Apache Shiro在Spring Security處理密碼學方面有一個額外的模組。
- Spring Security 對Spring 結合較好，並且不能脫離Spring，如果專案用的SpringMVC ，使用起來很方便。
- Shiro 功能強大、且 簡單、靈活。是Apache 下的專案比較可靠，且不跟任何的框架或者容器繫結，可以獨立執行。
- Spring Security支援Oauth、OpenID
- Spring Security的許可權細粒度更高（關於這點，從我翻閱到的部落格來看，大家一致表示還未發現高在哪裡）
從以上幾點來看，各有優劣，根據具體專案需求進行選擇。綜合多種原因，我們選用了Spring Security。
② 使用者認證
傳統的單體應用都是通過session來做使用者認證，在前後端分離後偏向基於token認證。在微服務流行後，Spring Security 結合 OAuth 被推行。關於OAuth可以看看這篇文字 -
OAuth2分為認證伺服器和資源伺服器：在這個架構中，Auth Server作為認證伺服器，負責對客戶端進行認證授權，為客戶端頒發令牌。Gateway作為資源伺服器，負責對token進行驗證來判斷是否允許客戶端的訪問操作。
OAuth2包含4種授權模式：
- 授權碼（認證碼）模式 （Authorization code)
- 簡化（隱形）模式 (Impilict
- 密碼模式 (Resource Owner Password Credential)
- 客戶端模式 (Client Credential)
根據專案業務情況，我們這裡目前採用密碼模式，隨著專案運作模式的改變、版本的大更新，後面不排除會使用其他授權模式。
③ JWT認證協議
JWT（JSON Web Token）是一種認證協議，是目前最流行的跨域身份驗證解決方案。它將使用者資訊加密到token裡並由客戶端儲存，伺服器不儲存任何使用者資訊。伺服器通過使用儲存的金鑰驗證token的正確性，只要正確即通過驗證。
JWT優點是可以解決Session共享問題，提高後端服務的可用性和擴充套件性；缺點是無法作廢已頒發的令牌，雖然可以通過其他途徑實現，但是不免有些麻煩，而且違背了JWT的初衷。結合我們的專案來看，我認為使用JWT的弊是大於利的，所以這裡我不打算使用JWT，延續以往的實現方式，在Redis中維護token。
三、系統工作流
簡單畫了下訪問系統時系統的工作流：
系統架構的設計相對簡單，後續可能還要經過討論進行調整。架構需要達到業務需求並且具備高併發、高可用、可擴充套件性，不能因為專案的變更或者使用者體量上升等等原因出現不可擴充套件、重構、大調整等問題。