隨着微服務架構的流行，系統架構調整，項目權限系統模塊開發提上日程，需要對權限架構進行設計以及技術選型。所以這段時間看了下相關的資料，做了幾個對比選擇。
一、架構圖
初步設想的架構如下，結構很簡單：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可以看看這篇文字 - 理解OAuth 2.0
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。
三、系統工作流
簡單畫了下訪問系統時系統的工作流：
系統架構的設計相對簡單，后續可能還要經過討論進行調整。架構需要達到業務需求並且具備高並發、高可用、可擴展性，不能因為項目的變更或者用戶體量上升等等原因出現不可擴展、重構、大調整等問題。