本文討論分布式架構(gòu)權(quán)限管理的兩種情況，一種是針對統(tǒng)一授權(quán)訪問的，一種是跨平臺接口訪問的。

[[271166]]

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

一、統(tǒng)一授權(quán)訪問

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

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

2、由ZUUL反向代理到權(quán)限中心的SERVICE。

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

4、有查詢結(jié)果以后反饋，反饋用戶狀態(tài)，用戶、角色、權(quán)限信息等。

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

6、返回給客戶端用戶、角色、權(quán)限信息。

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

8、瀏覽器客戶端發(fā)送業(yè)務(wù)請求到服務(wù)端，請求會附帶客戶端菜單或者功能的權(quán)限信息，服務(wù)端通過ZUUL的攔截器攔截業(yè)務(wù)請求，訪問SESSION共享池。

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

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

二、跨平臺接口訪問

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

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

2、添加用戶信息、權(quán)限信息到用戶數(shù)據(jù)庫之中。

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

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

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

6、返回TOKEN給客戶端。

7、客戶端拿到TOKEN以后發(fā)送業(yè)務(wù)請求給業(yè)務(wù)接口地址。

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

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

10、如果有接口授權(quán)則通過，訪問接口，如果沒有則不能訪問。

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