從單體應用到SOA應用再到Spring Cloud微服務構架，應用的安全訪問都是非常重要的問題，怎麼樣設計微服務的許可權控制？首先，許可權控制可以分為三個部分：使用者認證，服務許可權，使用者許可權。

使用者認證

使用者認證，簡單的講，可以簡化為應用對使用者登入狀態的認證。傳統的單體應用，使用session來進行使用者認證，但是這種方式已經不適合微服務的場景了；微服務的結構下，可以通過分散式session來解決，也可以通過和Spring Cloud Security結合很好的OAuth2來解決。

分散式Session

通過單獨開闢一個認證服務或者公共儲存的方式實現。一般流程為：

用分散式session實現時，需要仔細考量的是，校驗token的邏輯在什麼階段校驗比較合適？一般有兩個選擇，放在各自的微服務校驗，和放在zuul閘道器校驗。

在微服務上校驗使用者token的話，還要考慮到要與服務呼叫服務的場景區分，增加了校驗的複雜程度，所以選擇將使用者認證統一放在zuul閘道器校驗。這樣，業務流程就如下圖。

JWT

JWT（JSON Web Tokens），簡單的說就是伺服器不儲存任何資料，將資料儲存在客戶端，每次請求發回服務端。

JWT的原理是，伺服器認證後生成一個json物件（儲存著使用者資訊，登入過期時間等），json物件發回給使用者客戶端，以後客戶端與伺服器進行通訊的時候，都需要帶著json物件，這樣伺服器就可以完成使用者的認證。

這樣，伺服器不儲存任何資料，這樣伺服器就無狀態了，比較易於擴充套件。

但是資料儲存在客戶端，使用者修改JSON物件的資料很不安全，為了保證使用者不篡改json物件的內容，伺服器在生成物件的時候會加上簽名加密。

分散式session和JWT對比

分散式session的問題是，伺服器儲存使用者認證資料，需要擴充套件的成本，如果認證服務或者快取服務出現問題，整個應用就不可用，也就是單點故障問題。session的訪問一般要儲存在記憶體中，來支援快速的讀寫，這樣也就不易於擴充套件。

JWT的缺點是，session只要是伺服器發出去的JSON物件，伺服器都要通過認證。如果使用者資訊量比較大的話，每次通過網路請求也不太合理

服務許可權認證

微服務的一大核心是將服務進行拆分，降低服務的複雜度，拆分後，就會有服務之間的呼叫關係，服務之間的許可權控制也是必要的。一般只需要維繫微服務之間的呼叫關係，微服務呼叫時，呼叫髮帶著自己的服務標識，被呼叫發校驗呼叫方的許可權。

使用者許可權認證

使用者許可權一般分為功能許可權和資料許可權

功能許可權

使用者功能許可權一般採用經典的RBAC（Role Based Access Control）方式進行控制，RBAC的核心就是通過角色來控制使用者許可權，也就是使用者通過角色和許可權產生關聯，再去控制使用者的操作。

RBAC的模型如下，通過這個模型終端使用者和許可權產生關係，結合前後端的許可權校驗，實現功能許可權控制。

資料許可權

使用者的資料許可權需要新建模型去控制，通過資料範圍的模型去控制，核心是通過資料範圍來控制資料許可權，先定義好在哪些維度上進行資料許可權的控制，資料範圍有各個維度資料的資料集，根據這個資料集去控制使用者的資料的訪問範圍。

這樣，整合使用者認證，微服務之間許可權控制，使用者許可權控制後，微服務的許可權控制整體結構為：

（完）