應(yīng)用拆分微服務(wù)后，一個(gè)不可避免的問(wèn)題就是權(quán)限問(wèn)題。拆分后的各個(gè)微服務(wù)如何處理權(quán)限，怎么處理才能保證滿足業(yè)務(wù)的需求，怎么處理才能保持架構(gòu)的簡(jiǎn)單及可維護(hù)？今天的文章，讓我們來(lái)深入微服務(wù)架構(gòu)下的權(quán)限處理問(wèn)題，看看這個(gè)沒(méi)有最佳實(shí)踐的領(lǐng)域，如何能夠針對(duì)業(yè)務(wù)需求來(lái)設(shè)計(jì)的較為優(yōu)雅。

1.先來(lái)理解幾個(gè)名詞

關(guān)于權(quán)限，可能有很多相關(guān)名詞，而且這些名詞也很可能會(huì)讓大家混淆或是疑惑（為了避免讓大家產(chǎn)生疑惑，我就不列舉這些名詞了）。

但本文中會(huì)用到幾個(gè)核心的有關(guān)權(quán)限的詞，理解這幾個(gè)詞對(duì)于理解本文必不可少，所以關(guān)于權(quán)限處理至少有下述三個(gè)名詞需要大家先來(lái)理解。（1）認(rèn)證。（2）鑒權(quán)。（3）授權(quán)。先來(lái)說(shuō)說(shuō)認(rèn)證。我們都會(huì)用到各種各樣的系統(tǒng)，并且在進(jìn)入系統(tǒng)之前都需要你輸入用戶名/密碼，點(diǎn)擊登錄后，后臺(tái)做的事就是認(rèn)證，及驗(yàn)證你的用戶名/密碼是否正確，能否登錄系統(tǒng)。這就是認(rèn)證做的事。再來(lái)說(shuō)說(shuō)鑒權(quán)。同樣的系統(tǒng)，不同的人登錄成功后，擁有的權(quán)限是不一樣的，在你進(jìn)行操作時(shí)，后臺(tái)會(huì)驗(yàn)證你是否能夠進(jìn)行相應(yīng)的操作，這就是鑒權(quán)，及校驗(yàn)用戶是否有相應(yīng)資源的操作權(quán)限。最后來(lái)說(shuō)說(shuō)授權(quán)。不同的用戶擁有不同的權(quán)限是通過(guò)系統(tǒng)授權(quán)來(lái)實(shí)現(xiàn)的，授權(quán)就是授予相關(guān)用戶或角色資源操作的權(quán)限。當(dāng)然授權(quán)可能還包含對(duì)第三方系統(tǒng)的授權(quán)，本文暫不討論此類場(chǎng)景。其實(shí)對(duì)于大多數(shù)應(yīng)用系統(tǒng)來(lái)說(shuō)，權(quán)限處理最關(guān)鍵的就是要解決上述三個(gè)詞所描述的問(wèn)題，即系統(tǒng)權(quán)限處理要做的事就是認(rèn)證、鑒權(quán)和授權(quán)。

2.認(rèn)證、鑒權(quán)和授權(quán)，在單體應(yīng)用中如何實(shí)現(xiàn)？

在上文中，我們說(shuō)明了權(quán)限問(wèn)題的核心就是解決認(rèn)證、鑒權(quán)和授權(quán)問(wèn)題。想要知道微服務(wù)架構(gòu)中如何處理權(quán)限問(wèn)題，不如讓我們先看看在單體應(yīng)用中是如何處理上述問(wèn)題的？讓我們來(lái)分別說(shuō)明。（1）認(rèn)證單體應(yīng)用中，對(duì)于用戶登錄，會(huì)先校驗(yàn)用戶的登錄信息（用戶名/密碼），這其中可能會(huì)涉及到密碼的加密處理，一般的判斷是加密后相應(yīng)的密碼是否與數(shù)據(jù)庫(kù)中存儲(chǔ)的密碼相等，如果相等的話，則登錄成功。用戶登錄成功的話，一般會(huì)返回用戶登錄成功相關(guān)憑證。如果是JWT的話，則會(huì)返回Token，如果采用的是會(huì)話的話，則會(huì)通過(guò)Set-Cookie返回SessionId給客戶端。

（2）鑒權(quán)單體應(yīng)用一般會(huì)通過(guò)攔截器（Spring Security、Apache Shrio本質(zhì)上都是攔截器），攔截用戶請(qǐng)求，這里同樣會(huì)根據(jù)鑒權(quán)方案是JWT還是HTTP會(huì)話分別處理，如果是JWT的話，則會(huì)通過(guò)解密來(lái)獲得用戶信息，如果是采用的會(huì)話的方式，則會(huì)根據(jù)會(huì)話ID，從存儲(chǔ)中（這里一般是Redis）來(lái)獲得用戶信息，不論是哪種方案，最終都是根據(jù)用戶信息來(lái)對(duì)相應(yīng)的請(qǐng)求進(jìn)行權(quán)限校驗(yàn)。這里需要注意的是，鑒權(quán)一般有兩種方式，但都是基于角色的。一種是基于角色的隱式鑒權(quán)，即根據(jù)角色直接判斷是否擁有相應(yīng)資源的操作權(quán)限，比如你的角色是管理員，你就可以刪除用戶，你的角色是普通用戶，你只能查看用戶信息。這種一般在簡(jiǎn)單的系統(tǒng)中比較適用，常用的方式是通過(guò)注解，表明哪個(gè)接口可以給哪個(gè)角色訪問(wèn)。但這種方式在復(fù)雜的系統(tǒng)中就會(huì)變得難以維護(hù)。另一種是基于角色的精準(zhǔn)鑒權(quán)，此種鑒權(quán)方案，一般會(huì)給角色分配明確的權(quán)限，相應(yīng)的鑒權(quán)方式為根據(jù)用戶角色查出具體的權(quán)限集合，然后進(jìn)行進(jìn)一步判斷。此種方式在復(fù)雜系統(tǒng)中更加有效方便。

（3）授權(quán)在單體應(yīng)用中，授權(quán)即修改用戶相關(guān)角色信息，或者修改角色相關(guān)權(quán)限信息。一般在用戶重新登錄后，最新的權(quán)限信息生效。

3.在微服務(wù)架構(gòu)下如何實(shí)現(xiàn)上述功能?

其實(shí)在微服務(wù)中，權(quán)限處理的認(rèn)證、授權(quán)功能實(shí)現(xiàn)，跟單體應(yīng)用沒(méi)什么區(qū)別。

從微服務(wù)的基于業(yè)務(wù)拆分的原則上，對(duì)于用戶相關(guān)的業(yè)務(wù)，我們都會(huì)單獨(dú)創(chuàng)建一個(gè)用戶服務(wù)，用戶服務(wù)作為一個(gè)單獨(dú)的微服務(wù)，在實(shí)現(xiàn)認(rèn)證、授權(quán)功能時(shí)，和單體應(yīng)用保持一致即可，即相應(yīng)的用戶登錄信息校驗(yàn)、用戶角色修改、角色的權(quán)限修改，在用戶服務(wù)中獨(dú)立實(shí)現(xiàn)即可。所以在微服務(wù)架構(gòu)下權(quán)限處理唯一與單體應(yīng)用不同的便是鑒權(quán)方式。鑒權(quán)方式為什么變得不同了呢？因?yàn)殍b權(quán)不再集中在單體應(yīng)用中了，鑒權(quán)被分散在了各個(gè)微服務(wù)中。所以現(xiàn)在問(wèn)題的關(guān)鍵就變成了從哪里獲取用戶相關(guān)信息，然后在哪里進(jìn)行鑒權(quán)。下面讓我們來(lái)看幾種微服務(wù)架構(gòu)下的鑒權(quán)方案：第一種方案為，從用戶服務(wù)獲取用戶信息，然后各個(gè)微服務(wù)分別鑒權(quán)。如下圖所示：

上圖中有三個(gè)微服務(wù)，分別是倉(cāng)儲(chǔ)服務(wù)、訂單服務(wù)、以及用戶服務(wù)，對(duì)于每個(gè)微服務(wù)的訪問(wèn)都需要進(jìn)行鑒權(quán)，相應(yīng)的鑒權(quán)方式為，所有對(duì)微服務(wù)的訪問(wèn)在經(jīng)過(guò)網(wǎng)關(guān)后都統(tǒng)一先訪問(wèn)用戶服務(wù)獲取用戶相關(guān)信息，包括角色信息、角色權(quán)限信息，然后分別在各個(gè)微服務(wù)中進(jìn)行鑒權(quán)，判斷用戶是否有權(quán)限進(jìn)行相應(yīng)的操作。

上述方式的優(yōu)點(diǎn)是實(shí)現(xiàn)簡(jiǎn)單，對(duì)比單體應(yīng)用的實(shí)現(xiàn)來(lái)說(shuō)，只是換了個(gè)地方獲取用戶信息，權(quán)限相關(guān)的判斷還是保留在各個(gè)微服務(wù)中。對(duì)應(yīng)的缺點(diǎn)也很明顯，用戶服務(wù)需要保證高性能、高可靠以及可擴(kuò)展，并且隨著服務(wù)的增多，每個(gè)服務(wù)都需要與用戶服務(wù)交互，服務(wù)間調(diào)用可能會(huì)顯得略加繁瑣，不夠簡(jiǎn)單優(yōu)雅，同時(shí)每個(gè)微服務(wù)中的權(quán)限判斷邏輯也都重復(fù)冗余。綜上，個(gè)人并不是很推薦這種方式。其實(shí)對(duì)于第一種方案，我們略作修改，就可以得到一個(gè)略微優(yōu)雅的方案，如下圖，看第二種方案：

第二種方案為從用戶服務(wù)獲取用戶信息，然后在網(wǎng)關(guān)進(jìn)行鑒權(quán)，這樣整個(gè)架構(gòu)看起來(lái)是不是就清爽了許多？（美好的東西總是看起來(lái)簡(jiǎn)單的）

大家可能看到，這里將請(qǐng)求往具體的微服務(wù)透?jìng)鞯臅r(shí)候，帶上了用戶信息，這個(gè)用戶信息可以放在HTTP Header中。為什么透?jìng)鞯臅r(shí)候要帶上用戶信息呢？因?yàn)楹蠖司唧w的微服務(wù)業(yè)務(wù)可能需要獲取當(dāng)前用戶的信息，但這里并不是用來(lái)鑒權(quán)，只是業(yè)務(wù)邏輯中用到了而已。第二種方式的優(yōu)點(diǎn)是架構(gòu)簡(jiǎn)單，對(duì)于鑒權(quán)來(lái)講服務(wù)間調(diào)用交互更加簡(jiǎn)潔，并且后端微服務(wù)不需要冗余鑒權(quán)業(yè)務(wù)邏輯。缺點(diǎn)同樣是用戶服務(wù)需要保證高性能、高可靠以及可擴(kuò)展，并且鑒權(quán)邏輯需要在網(wǎng)關(guān)實(shí)現(xiàn)。微服務(wù)的理想狀態(tài)是高內(nèi)聚低耦合，每個(gè)服務(wù)專注于自己的事，各個(gè)服務(wù)間功能獨(dú)立，獨(dú)立演進(jìn)，所以針對(duì)微服務(wù)鑒權(quán)還有沒(méi)有更好的方案？請(qǐng)看第三種方案：

鑒權(quán)要做的事是判斷用戶有沒(méi)有相應(yīng)資源的操作權(quán)限，所以從微服務(wù)的基于業(yè)務(wù)拆分的原則基礎(chǔ)上，鑒權(quán)放在用戶服務(wù)是不是更合適？所以上述方案將鑒權(quán)放在了用戶服務(wù)來(lái)實(shí)現(xiàn)，我們不再需要調(diào)用用戶服務(wù)來(lái)獲取用戶信息然后進(jìn)行鑒權(quán)了，直接將用戶的請(qǐng)求轉(zhuǎn)發(fā)到用戶服務(wù)，在用戶服務(wù)中統(tǒng)一處理鑒權(quán)。此種方案下網(wǎng)關(guān)要做的事也將更加專注，只做請(qǐng)求的轉(zhuǎn)發(fā)即可，后端各個(gè)微服務(wù)也只需專注于自己的業(yè)務(wù)即可。

此種方案，在我看來(lái)是比較推薦的方案，并且應(yīng)該能滿足微服務(wù)架構(gòu)下大多數(shù)系統(tǒng)的權(quán)限處理需求。當(dāng)然缺點(diǎn)是對(duì)用戶服務(wù)的高性能、高可靠以及可擴(kuò)展提出了更高的要求。除了上述三種鑒權(quán)方式，微服務(wù)架構(gòu)下可能還有其他鑒權(quán)方式，比如共享用戶信息緩存的方式，這種方式下，各個(gè)微服務(wù)統(tǒng)一從緩存獲取用戶信息，然后分別在各自進(jìn)行鑒權(quán)?；诖朔N方式也很容易想到一個(gè)優(yōu)化的變種，即從網(wǎng)關(guān)獲取緩存的用戶信息，然后在網(wǎng)關(guān)進(jìn)行鑒權(quán)。

諸如此類的鑒權(quán)方式，我個(gè)人是不太推薦的，當(dāng)然采用此類鑒權(quán)方式的團(tuán)隊(duì)可能也有他們的考慮，更多的可能是出于性能的考慮。至于我為什么不推薦諸如此類的方式呢，我覺(jué)得我們?cè)谧鱿到y(tǒng)架構(gòu)的時(shí)候需要有自己的原則，其實(shí)對(duì)于很多問(wèn)題我們可以有許多種解決方法，哪種方案比哪種好可能并不好說(shuō)，甚至團(tuán)隊(duì)在方案的選擇上還會(huì)有所爭(zhēng)執(zhí)，但如果在架構(gòu)設(shè)計(jì)上團(tuán)隊(duì)有自己的指導(dǎo)原則的話，可能能夠幫助我們?cè)诜桨傅倪x擇上達(dá)成共識(shí)。個(gè)人在架構(gòu)設(shè)計(jì)上的原則包括但不限于可維護(hù)原則、可擴(kuò)展原則、簡(jiǎn)單性原則等，所以與其說(shuō)此類方案不好，倒不如說(shuō)這并不符合我的設(shè)計(jì)原則。

寫(xiě)在最后應(yīng)用拆分微服務(wù)后，一個(gè)不可避免的問(wèn)題是權(quán)限問(wèn)題。

權(quán)限問(wèn)題要解決的核心問(wèn)題是認(rèn)證、鑒權(quán)和授權(quán)。在說(shuō)明微服務(wù)架構(gòu)下如何處理權(quán)限問(wèn)題之前，我們先看了單體應(yīng)用下是如何處理權(quán)限問(wèn)題的認(rèn)證、鑒權(quán)和授權(quán)的。對(duì)于微服務(wù)來(lái)講，權(quán)限問(wèn)題的處理與單體應(yīng)用中的處理最大的不同是鑒權(quán)的方式，至于認(rèn)證、授權(quán)的實(shí)現(xiàn)與單體應(yīng)用并無(wú)太大不同，在微服務(wù)中的用戶服務(wù)下實(shí)現(xiàn)即可。微服務(wù)下鑒權(quán)處理為什么變得不同了呢？因?yàn)殍b權(quán)不再集中在單體應(yīng)用中了，鑒權(quán)被分散在了各個(gè)微服務(wù)中。

所以問(wèn)題的關(guān)鍵是微服務(wù)下該從哪里獲取用戶相關(guān)信息，然后在哪里進(jìn)行鑒權(quán)。我們?cè)敿?xì)介紹了微服務(wù)架構(gòu)下三種鑒權(quán)的實(shí)現(xiàn)，第一種方式是從用戶服務(wù)獲取用戶信息，然后在各個(gè)微服務(wù)中鑒權(quán)。第二種方式是從用戶服務(wù)獲取用戶信息，然后在網(wǎng)關(guān)統(tǒng)一鑒權(quán)。第三種方式不再需要獲取用戶信息，直接通過(guò)網(wǎng)關(guān)轉(zhuǎn)發(fā)請(qǐng)求，在用戶服務(wù)進(jìn)行統(tǒng)一鑒權(quán)，各個(gè)服務(wù)的職責(zé)劃分更加明確，也是個(gè)人推薦的實(shí)現(xiàn)方式。除此之外，還介紹了一些其他的鑒權(quán)實(shí)現(xiàn)方案，問(wèn)題的解決方案并不唯一，有時(shí)候也很難說(shuō)出哪種更好，我們要有自己的設(shè)計(jì)原則。

聊技術(shù)，不止于技術(shù)。