本文討論分布式架構權限管理的兩種情況，一種是針對統一授權訪問的，一種是跨平臺接口訪問的。

[[271166]]

雖然分布式架構會做業務的切割，將整體的業務切割為獨立的子業務或者子平臺，但是同一平臺下往往會有統一的授權和單點登錄，客戶端而言平臺是整體的，這種是統一授權訪問的權限管理。但是也會遇到多平臺協作的情況，這種情況不用考慮其他平臺的架構，只需要為其提供數據接口跟其對接就可以，這種情況就要考慮跨平臺接口訪問的權限管理。

一、統一授權訪問

前端采用web服務器，nginx或者haproxy之類的都可以，利用nginx做第一層反向代理，用zuul做第二層反向代理，兩層反向代理對于常見的網絡滲透和爬蟲基本可以輕松應對。在這個前提下，我們處理接口授權和訪問安全等問題，而且需要從客戶端和服務端都進行安全控制。

1、用戶通過用戶名、密碼發起登陸請求，這里可以配合驗證碼、短信驗證、微信驗證等提高安全級別，登陸請求訪問到權限中心的ZUUL。

2、由ZUUL反向代理到權限中心的SERVICE。

3、查詢用戶、角色信息，進行查詢匹配。

4、有查詢結果以后反饋，反饋用戶狀態，用戶、角色、權限信息等。

5、生產TOKEN，TOKEN的算法需要自己編寫，建議加入時間戳等信息進行加密。存放在SESSION或者直接放入REDIS中，一般建議放入SESSION中，因為分布式架構要做SESSION共享，必須有一個SESSION共享池，SESSION共享池一般會用REDIS來做，而SESSION可以利用SESSIONID，確認唯一用戶，比較方便。

6、返回給客戶端用戶、角色、權限信息。

7、瀏覽器客戶端通過得到的用戶、角色、權限信息進行前端功能和菜單的渲染，隱藏非授權的功能，并且可以基于這些信息做前端的校驗，但是這種校驗由于都在客戶端，很容易被人篡改，只能做一些基本防護，但是這是必要的。

8、瀏覽器客戶端發送業務請求到服務端，請求會附帶客戶端菜單或者功能的權限信息，服務端通過ZUUL的攔截器攔截業務請求，訪問SESSION共享池。

9、然后通過SESSIONID得到TOKEN信息，通過我們的TOKEN算法進行解密，得到用戶、角色、權限信息。

10、進行匹配校驗，查看本次請求是否有接口訪問權限，校驗通過就可以訪問接口，校驗不通過就不能訪問。

二、跨平臺接口訪問

這里的接口是指一下跨平臺的接口服務，類似webservice這樣，沒有單點登錄，沒有統一的授權，往往是其他平臺跟我們平臺進行遠程交互的，這些往往兩個平臺不是統一的公司或部門，所以接口不是長期使用的，有一定的時間限制。

1、用戶管理員配置外部客戶端用戶及其權限信息。

2、添加用戶信息、權限信息到用戶數據庫之中。

3、外部客戶端接口如果沒有TOKEN，需要先發送授權請求到權限中心。

4、權限中心通過驗證是否配置外部客戶端用戶，并且取得該用戶的權限信息，校驗通過以后通過加密算法生產TOKEN，這里的TOKEN根據實際情況，如果安全要求高最好加入時間戳，讓TOKEN過期作廢，讓對方重新請求。

5、將TOKEN存入REDIS中，形成TOKEN共享池，這里由于沒有瀏覽器的SESSIONID，所以存放在SESSION中意義不大。

6、返回TOKEN給客戶端。

7、客戶端拿到TOKEN以后發送業務請求給業務接口地址。

8、業務接口通過ZUUL攔截請求，并且將TOKEN跟REDIS的TOKEN進行比對。

9、比對成功以后，對TOKEN進行解密，然后看是否有接口授權。

10、如果有接口授權則通過，訪問接口，如果沒有則不能訪問。

Java高級資料需要自己領取，涵蓋了Java、Redis、MongoDB、MySQL、Zookeeper、Spring Cloud、Dubbo高并發分布式等教程!!!