[[397838]]

我們用網(wǎng)關(guān)做了這些事情：

• 1.實(shí)現(xiàn)路由功能；
• 2.整合Swagger API文檔；
• 3.文件URI的全局修改；
• 4.統(tǒng)一校驗(yàn)Token；
• 5.統(tǒng)一校驗(yàn)資源訪問(wèn)權(quán)限；
• 6.對(duì)外開(kāi)放API統(tǒng)一簽名校驗(yàn)。

實(shí)現(xiàn)路由功能

實(shí)現(xiàn)路由功能的目的是統(tǒng)一流量入口，為前端屏蔽后端多個(gè)微服務(wù)的存在，無(wú)需為后端每個(gè)微服務(wù)都通過(guò)域名將接口暴露于外網(wǎng)。

之前我們項(xiàng)目是通過(guò)nginx實(shí)現(xiàn)請(qǐng)求路由功能，但我們需要的不僅僅是路由功能，路由功能只是網(wǎng)關(guān)的最基礎(chǔ)功能。

整合Swagger API文檔

項(xiàng)目微服務(wù)化后接口文檔也隨之分散，前期由于我們是使用nginx做路由，配置swagger路由又太過(guò)麻煩，前端同事也需要記住路由規(guī)則，因此我們放棄通過(guò)配置路由訪問(wèn)接口文檔。

在沒(méi)有網(wǎng)關(guān)之前，前端同事無(wú)法訪問(wèn)測(cè)試環(huán)境的接口文檔，我們只能在本地啟動(dòng)微服務(wù)讓前端同事通過(guò)局域網(wǎng)訪問(wèn)API接口文檔。

引入網(wǎng)關(guān)后我們希望能統(tǒng)一API文檔入口。詳細(xì)的整合步驟筆者已單獨(dú)整理出一篇教程《在網(wǎng)關(guān)實(shí)現(xiàn)合并多個(gè)微服務(wù)Swagger接口文檔的詳細(xì)步驟》，最終實(shí)現(xiàn)的效果如下圖所示。

文件URI的全局修改

由于域名、路由前綴都有修改的可能，一般圖片上傳后我們只存儲(chǔ)圖片的相對(duì)路徑到數(shù)據(jù)庫(kù)，但響應(yīng)給前端的必須是完整的url，否則圖片無(wú)法訪問(wèn)，因此我們必須要在響應(yīng)前為所有圖片url拼接上域名與路由。

以修改用戶(hù)頭像為例，前端需要先調(diào)用文件上傳接口上傳圖片并獲取到圖片上傳后的url，再攜帶圖片url調(diào)用修改用戶(hù)頭像的接口。由于前端可能需要實(shí)現(xiàn)上傳后回顯，因此文件上傳接口響應(yīng)的圖片url也必須是完整的，這樣就導(dǎo)致前端調(diào)用修改用戶(hù)頭像接口傳的圖片url也是完整的，我們不得不在修改用戶(hù)頭像的接口實(shí)現(xiàn)去掉頭像url的域名和路由。

一個(gè)接口可以這樣，很多個(gè)接口呢？如果不怕麻煩，那確實(shí)每個(gè)接口都可以這樣寫(xiě)。

對(duì)于這類(lèi)重復(fù)性操作，我們選擇將其移至網(wǎng)關(guān)統(tǒng)一實(shí)現(xiàn)，并且當(dāng)路由、域名修改后其它微服務(wù)也不需要做任何的改動(dòng)。

想要實(shí)現(xiàn)為圖片url去掉或拼接域名與路由并不難，難的是我們?nèi)绾螐恼?qǐng)求body以及從響應(yīng)body中識(shí)別出哪些字段是文件url。

首先是如何從請(qǐng)求body識(shí)別出哪個(gè)字段傳的是文件url。由于前端傳的文件url是完整的，因此可根據(jù)域名、路由和文件名后綴使用正則匹配替換。域名、路由、文件名后綴這三個(gè)條件缺一不可。匹配域名和路由是避免匹配到第三方網(wǎng)站的圖片鏈接或是以前上傳的圖片（向后兼容），匹配文件名后綴是確保這是一個(gè)文件鏈接，而不是接口鏈接。

其次是如何從響應(yīng)body識(shí)別出哪個(gè)字段傳的是文件鏈接。我們只能通過(guò)后綴名去匹配，當(dāng)匹配上后綴名后還需要判斷鏈接是否已經(jīng)是完整的鏈接，對(duì)于完整的鏈接就無(wú)需做拼接。

在實(shí)現(xiàn)過(guò)程中需要注意的地方：當(dāng)我們修改請(qǐng)求或響應(yīng)body時(shí)，其長(zhǎng)度可能會(huì)發(fā)生變化，因此必須要記得修改請(qǐng)求或響應(yīng)頭的ContentLength。

如果是基于Spring Cloud Gateway實(shí)現(xiàn)的網(wǎng)關(guān)，由于是異步響應(yīng)式的，對(duì)于請(qǐng)求數(shù)據(jù)包，先是請(qǐng)求頭被寫(xiě)入InputStream流，再是body，而不是一起寫(xiě)入，所以當(dāng)我們修改body后再修改請(qǐng)求頭的ContentLength已是無(wú)意義。在無(wú)法預(yù)知修改后body的長(zhǎng)度情況下，解決方案可以是將請(qǐng)求頭的ContentLength移除，取而代之的是Transfer-Encoding: chunked。

統(tǒng)一校驗(yàn)Token有效性

在還是使用nginx做請(qǐng)求轉(zhuǎn)發(fā)的時(shí)候，每個(gè)微服務(wù)都需要寫(xiě)一套token校驗(yàn)邏輯，如通過(guò)攔截器校驗(yàn)請(qǐng)求是否攜帶token，以及token是否有效。而獲取用戶(hù)信息需要先從請(qǐng)求頭獲取token，再查redis獲取用戶(hù)身份信息。

在引入網(wǎng)關(guān)后，我們就只需要在網(wǎng)關(guān)做token校驗(yàn)，校驗(yàn)通過(guò)后從redis獲取用戶(hù)信息，并寫(xiě)到請(qǐng)求頭中，同時(shí)將Token從請(qǐng)求頭移除。userId由網(wǎng)關(guān)傳遞給后臺(tái)微服務(wù)，后臺(tái)微服務(wù)不需要再一次根據(jù)Token獲取用戶(hù)ID。

統(tǒng)一校驗(yàn)資源訪問(wèn)權(quán)限

在引入網(wǎng)關(guān)后，除了登錄（Token）校驗(yàn)，用戶(hù)訪問(wèn)資源的權(quán)限校驗(yàn)都可以在網(wǎng)關(guān)實(shí)現(xiàn)，每個(gè)微服務(wù)都不再關(guān)心權(quán)限校驗(yàn)的問(wèn)題。

具體的用戶(hù)資源訪問(wèn)權(quán)限校驗(yàn)依然由用戶(hù)中心完成，網(wǎng)關(guān)只負(fù)責(zé)調(diào)用用戶(hù)中心提供的權(quán)限校驗(yàn)接口完成用戶(hù)資源訪問(wèn)權(quán)限校驗(yàn)。這可能會(huì)影響接口的性能，盡量讓用戶(hù)中心在實(shí)現(xiàn)權(quán)限校驗(yàn)接口時(shí)數(shù)據(jù)來(lái)源全部讀緩存。

對(duì)外開(kāi)放api統(tǒng)一簽名校驗(yàn)

我們對(duì)外開(kāi)放API采用基于簽名機(jī)制實(shí)現(xiàn)身份認(rèn)證，可以控制簽名的有限時(shí)間。筆者之前寫(xiě)過(guò)一篇關(guān)于簽名機(jī)制的文章：《一種基于簽名算法且簡(jiǎn)單安全的API授權(quán)機(jī)制》。

在沒(méi)有引入網(wǎng)關(guān)之前，我們通過(guò)AOP實(shí)現(xiàn)，只需要在開(kāi)放API方法上添加一個(gè)注解。其中key和私鑰、簽名有效期在配置文件中配置。而在引入網(wǎng)關(guān)后，就可以統(tǒng)一在網(wǎng)關(guān)實(shí)現(xiàn)簽名校驗(yàn)。

如果API需要提供給多個(gè)不同主體使用，也就是會(huì)有多個(gè)合作客戶(hù)的系統(tǒng)使用，那么key和密鑰是要在后臺(tái)提供配置功能的，且配置持久化到數(shù)據(jù)庫(kù)，網(wǎng)關(guān)也需要支持根據(jù)key查詢(xún)密鑰再校驗(yàn)簽名。網(wǎng)關(guān)可將key、密鑰字典緩存在內(nèi)存中，定時(shí)刷新?；蛘呔彺娴絩edis，當(dāng)有賬號(hào)的密鑰更新時(shí)同步刷新緩存。

總結(jié)

網(wǎng)關(guān)一般用于統(tǒng)一流量入口、統(tǒng)一認(rèn)證鑒權(quán)、流量控制，除此之外，一些與業(yè)務(wù)無(wú)關(guān)的重復(fù)操作也都可以在網(wǎng)關(guān)統(tǒng)一實(shí)現(xiàn)，如本篇介紹的統(tǒng)一SwaggerAPI文檔入口，為文件url自動(dòng)去掉或拼接域名與路由。內(nèi)部對(duì)外提供的接口也都可以通過(guò)網(wǎng)關(guān)做簽名校驗(yàn)、訪問(wèn)頻率限制等。

本文轉(zhuǎn)載自微信公眾號(hào)「Java藝術(shù)」，可以通過(guò)以下二維碼關(guān)注。轉(zhuǎn)載本文請(qǐng)聯(lián)系Java藝術(shù)公眾號(hào)。