背景

單體應(yīng)用在向微服務(wù)化架構(gòu)演進(jìn)時(shí)，需要考慮如何解決服務(wù)認(rèn)證授權(quán)的問題。如果處理不好，會(huì)引發(fā)架構(gòu)的混亂，帶來安全、性能、難以維護(hù)的問題。 以最典型的包含WEB頁面的具備登錄態(tài)管理的系統(tǒng)為例。在最初階段，登錄鑒權(quán)一般通過cookie+redis分布式session來實(shí)現(xiàn)。

在服務(wù)化過程中，單體系統(tǒng)會(huì)拆分為多個(gè)微服務(wù)，這時(shí)微服務(wù)間會(huì)出現(xiàn)相互調(diào)用。對(duì)于使用Dubbo、Grpc等RPC協(xié)議的系統(tǒng)而言，由于給web頁面提供的是HTTP接口，而給微服務(wù)間調(diào)用提供的RPC接口，架構(gòu)比較清晰。而對(duì)于Springcloud技術(shù)體系，微服間調(diào)用和頁面都是通過HTTP RESTFUL接口，這時(shí)候要解決兩個(gè)問題：

1. web頁面的登錄校驗(yàn)
2. 微服務(wù)之間的鑒權(quán)

解決方案

透?jìng)鱟ookie反模式

這種方案希望保持單體架構(gòu)時(shí)的調(diào)用方式，微服務(wù)間調(diào)用接口復(fù)用了提供給WEB頁面的接口。 為了解決登錄鑒權(quán)問題，微服務(wù)間調(diào)用時(shí)，會(huì)將WEB頁面的cookie透?jìng)髦疗渌?wù)，這樣鑒權(quán)邏輯可以保持不動(dòng)。 很顯然，該方案雖然看上去能很好work，但它是一種反模式設(shè)計(jì)，完全違背了微服務(wù)的初衷，微服務(wù)一定是無狀態(tài)的！

內(nèi)外接口分離模式

很顯然，上述方案是不合理的。如果想繼續(xù)保持服務(wù)間調(diào)用使用RESTFUL域名，則可以將面向前端的接口與面向微服務(wù)的接口區(qū)分開，實(shí)現(xiàn)方式是為兩者加上不同的URL前綴，如/inner、/outer。外部接口是給WEB頁面調(diào)用的，內(nèi)部接口是專門給微服務(wù)間調(diào)用的。在認(rèn)證鑒權(quán)時(shí)，僅針對(duì)外部接口進(jìn)行鑒權(quán)，而內(nèi)部接口直接放行。 該方案的問題是，內(nèi)部接口存在安全隱患，可以被外界肆意攻擊。 如果要緩解該問題，可通過如下方式：

1. 申請(qǐng)一個(gè)額外的生產(chǎn)網(wǎng)段的域名（需做七網(wǎng)隔離，外網(wǎng)/辦公網(wǎng)/生產(chǎn)網(wǎng)段無法互相訪問），專門用于服務(wù)間調(diào)用。
2. 在Nignx側(cè)增加配置，對(duì)于原有的域名，只放行以outer前綴開始的請(qǐng)求。

web和服務(wù)分離模式

上述方案的另外一個(gè)變種，仍是將對(duì)外接口和對(duì)內(nèi)接口分開，但是劃分的更加徹底，新增了一個(gè)專門提供面向前端提供web接口的服務(wù)，如下圖所示。該方案的優(yōu)點(diǎn)：

1. 微服務(wù)不需要關(guān)心如何校驗(yàn)session，所有認(rèn)證都在web服務(wù)做。這個(gè)微服務(wù)是真正無狀態(tài)的。
2. 微服務(wù)間的調(diào)用不做鑒權(quán)。
3. 微服務(wù)是高度通用的，只需要處理領(lǐng)域核心邏輯，不用關(guān)心如何和前端頁面適配，這點(diǎn)對(duì)于平臺(tái)型服務(wù)尤其如此。

對(duì)于該方案中因內(nèi)部接口調(diào)用產(chǎn)生的安全問題，可參考上個(gè)方案，申請(qǐng)一個(gè)額外的生產(chǎn)網(wǎng)段的域名。

網(wǎng)關(guān)鑒權(quán)

對(duì)于有中臺(tái)的技術(shù)團(tuán)隊(duì)而言，一般都會(huì)有提供一個(gè)通用的平臺(tái)網(wǎng)關(guān)。我們希望在網(wǎng)關(guān)解決所有登錄鑒權(quán)的問題，這使得登錄鑒權(quán)問題對(duì)業(yè)務(wù)服務(wù)完全透明。而對(duì)于服務(wù)間調(diào)用的問題，可使用rpc、類rpc方式（ServiceMesh）、內(nèi)部域名來實(shí)現(xiàn)，而這些調(diào)用方式都是零信任無鑒權(quán)的。 對(duì)于這種方案，微服務(wù)的api有很大的通用性和靈活性，接口設(shè)計(jì)不需要區(qū)分接口使用的場(chǎng)景，是目前業(yè)界比較推薦的做法。

總結(jié)

本文介紹了服務(wù)在從單體演進(jìn)到微服務(wù)架構(gòu)過程中，對(duì)于服務(wù)認(rèn)證鑒權(quán)遇到的問題，并提供了開發(fā)人員可能會(huì)用到的解決方案。除方案1外（不大合理、屬于野路子），其他方案在具體實(shí)踐過程中都有較多的case。如今微服務(wù)架構(gòu)已經(jīng)成為事實(shí)上的標(biāo)準(zhǔn)，我們希望微服務(wù)一定是無狀態(tài)的，專注于處理業(yè)務(wù)流程和規(guī)則，而鑒權(quán)認(rèn)證的邏輯應(yīng)交給專門的技術(shù)組件來負(fù)責(zé)，因此讓網(wǎng)關(guān)來統(tǒng)一處理鑒權(quán)是一個(gè)更優(yōu)雅的方案。

來源：
https://juejin.cn/post/7171729686936944654