如果說用戶的流量就像波濤洶涌的海浪，那網(wǎng)關(guān)就是防御沖擊的堤壩。在大型的互聯(lián)網(wǎng)項(xiàng)目里，網(wǎng)關(guān)必不可少，是我們目前最好用的防御手段。通過網(wǎng)關(guān)，我們能把大量的流量分流到各個(gè)服務(wù)上，如果配合使用 Lua 腳本引擎提供的一些能力，還能大大降低系統(tǒng)的耦合度和性能損耗，節(jié)約我們的成本。一般來說，網(wǎng)關(guān)分為外網(wǎng)網(wǎng)關(guān)和內(nèi)網(wǎng)網(wǎng)關(guān)。外網(wǎng)網(wǎng)關(guān)主要負(fù)責(zé)做限流、入侵預(yù)防、請(qǐng)求轉(zhuǎn)發(fā)等工作，常見方式是使用 Nginx + Lua 做類似的工作；而最近幾年，內(nèi)網(wǎng)網(wǎng)關(guān)發(fā)展出現(xiàn)了各種定制功能的網(wǎng)關(guān)，比如 ServiceMesh、SideCar 等方式，以及類似 Kong、Nginx Unit 等，它們的用途雖然有差異，但是主要功能還是做負(fù)載均衡、流量管理調(diào)度和入侵預(yù)防這些工作。

外網(wǎng)網(wǎng)關(guān)功能

我們先從外網(wǎng)網(wǎng)關(guān)的用法說起，我會(huì)給你分享兩類外網(wǎng)網(wǎng)關(guān)的實(shí)用設(shè)計(jì)，兩個(gè)設(shè)計(jì)可以幫助我們預(yù)防入侵和接觸業(yè)務(wù)的依賴。

蜘蛛嗅探識(shí)別

在處理大流量網(wǎng)站時(shí)，常見的安全問題包括非法引用和機(jī)器人抓取。為了防止這些問題，我們可以采取一些有效的策略，例如通過網(wǎng)關(guān)實(shí)現(xiàn)限速和入侵檢測(cè)功能。

非法引用防范：非法引用通常會(huì)導(dǎo)致我們網(wǎng)站的資源被濫用。一種常見的防范方法是檢查請(qǐng)求中的 referer 字段。如果請(qǐng)求的 referer 不是本站域名，就拒絕該請(qǐng)求。這能有效降低資源被未經(jīng)授權(quán)訪問的風(fēng)險(xiǎn)。

機(jī)器人抓取防范：機(jī)器人抓取是另一個(gè)常見的問題。為了識(shí)別和防止機(jī)器人的抓取，我們可以采取以下幾種方法：

1. 分析匿名用戶的請(qǐng)求：對(duì)于匿名用戶，我們可以通過統(tǒng)計(jì)其 IP 地址和請(qǐng)求的時(shí)間段，識(shí)別出請(qǐng)求頻率異常的 IP 地址。高頻次的請(qǐng)求 IP 應(yīng)該被標(biāo)記為重點(diǎn)關(guān)注對(duì)象。
2. 分析登錄用戶的行為：對(duì)于已登錄用戶，我們可以通過時(shí)間塊統(tǒng)計(jì)用戶的請(qǐng)求次數(shù)。如果某個(gè)用戶的請(qǐng)求頻率超過正常范圍，我們可以拒絕其請(qǐng)求，并將其列入“可疑名單”進(jìn)行后續(xù)調(diào)查。
3. 動(dòng)態(tài)注入 JS 嗅探代碼：為了更準(zhǔn)確地識(shí)別機(jī)器人，我們可以在網(wǎng)關(guān)層針對(duì)可疑的用戶或 IP 動(dòng)態(tài)注入 JS 嗅探代碼。該代碼會(huì)在用戶的 Cookie 或 LocalStorage 中寫入特定的密文，并要求前端 JS 代碼檢測(cè)該密文。如果密文存在且符合特定模式，前端會(huì)進(jìn)入“反機(jī)器人模式”，檢查客戶端是否有鼠標(biāo)移動(dòng)或點(diǎn)擊行為。這一檢測(cè)能夠幫助我們確認(rèn)該用戶是人工操作還是機(jī)器人行為。如果用戶長(zhǎng)時(shí)間沒有相應(yīng)的動(dòng)作，系統(tǒng)會(huì)將其列為待封禁對(duì)象，并且封禁該請(qǐng)求。
4. 白名單策略：由于這種反機(jī)器人設(shè)計(jì)可能會(huì)影響搜索引擎的抓取，特別是對(duì)于 SEO（搜索引擎優(yōu)化）不友好，因此我們可以采取白名單策略，允許一些常見的搜索引擎機(jī)器人訪問網(wǎng)站。我們可以根據(jù) UserAgent 來放行主流搜索引擎的爬蟲，并定期審核其 IP 地址。
5. 接口加簽策略：對(duì)于一些核心的接口，可以引入“必須附帶時(shí)間戳簽名”的規(guī)則，只有正確簽名的請(qǐng)求才能訪問。這一做法可以有效防止一些簡(jiǎn)單的爬蟲通過直接訪問接口來抓取數(shù)據(jù)。

通過這些措施，我們可以有效應(yīng)對(duì)非法引用和機(jī)器人抓取問題，保護(hù)網(wǎng)站的資源和數(shù)據(jù)安全。同時(shí)也能保持對(duì)搜索引擎的友好性，保證 SEO 的正常運(yùn)作。

網(wǎng)關(guān)鑒權(quán)與用戶中心解耦

之前我們討論了如何利用網(wǎng)關(guān)來阻擋非法用戶的騷擾。實(shí)際上，網(wǎng)關(guān)除了防御攻擊、防止資源被惡意消耗外，還能幫助我們解除一些業(yè)務(wù)依賴。比如在用戶登錄的設(shè)計(jì)上，每個(gè)業(yè)務(wù)不需要直接依賴用戶中心來驗(yàn)證用戶的合法性。

用戶鑒權(quán)通常會(huì)通過在各個(gè)子業(yè)務(wù)中集成用戶中心的 SDK 來實(shí)現(xiàn)一致的校驗(yàn)邏輯。這種方式帶來便利的同時(shí)，也產(chǎn)生了新的問題：SDK 的同步依賴和升級(jí)維護(hù)?；A(chǔ)公共組件一般會(huì)通過 SDK 為業(yè)務(wù)開發(fā)提供便捷，而如果僅通過 API 提供服務(wù)，一些特殊的操作可能會(huì)需要重復(fù)實(shí)現(xiàn)。然而，一旦 SDK 發(fā)布，我們就需要做好同時(shí)維護(hù)多個(gè)版本 SDK 在線工作的準(zhǔn)備，以確保兼容性和功能穩(wěn)定。

以下圖展示了使用 SDK 鑒權(quán) token 方式和直接通過用戶中心接口進(jìn)行鑒權(quán)的效果對(duì)比：

圖片

在集成 SDK 的情況下，各業(yè)務(wù)可以自行校驗(yàn)用戶身份，無需頻繁請(qǐng)求用戶中心。然而，這種方案也帶來了一些挑戰(zhàn)。由于 SDK 是嵌入在各個(gè)項(xiàng)目中的組件，項(xiàng)目通常不會(huì)頻繁升級(jí)其版本來保持穩(wěn)定性。這使得用戶中心的后續(xù)升級(jí)面臨阻力，因?yàn)樯?jí)時(shí)必須考慮到所有依賴的業(yè)務(wù)。每次基礎(chǔ)服務(wù)的大規(guī)模升級(jí)都需要大量人力來同步更新 SDK，從而增加了維護(hù)的復(fù)雜性。

為了解決這種耦合問題，我們可以考慮另一種設(shè)計(jì)思路，即將用戶登錄鑒權(quán)功能放到網(wǎng)關(guān)層。這樣一來，業(yè)務(wù)系統(tǒng)不再需要直接依賴用戶中心的 SDK，而是通過網(wǎng)關(guān)完成身份驗(yàn)證和權(quán)限校驗(yàn)。通過這種方式，網(wǎng)關(guān)可以在接收到請(qǐng)求時(shí)直接進(jìn)行用戶鑒權(quán)，只有通過驗(yàn)證的請(qǐng)求才會(huì)被轉(zhuǎn)發(fā)至具體的業(yè)務(wù)服務(wù)，從而解耦了用戶中心與各業(yè)務(wù)系統(tǒng)的直接依賴關(guān)系。

以下圖所示為這一設(shè)計(jì)下的請(qǐng)求流程，請(qǐng)結(jié)合示意圖參考，我將進(jìn)一步分析其工作機(jī)制和優(yōu)點(diǎn)。

圖片

結(jié)合上圖，我們來看這種設(shè)計(jì)的實(shí)現(xiàn)流程。當(dāng)用戶請(qǐng)求業(yè)務(wù)接口時(shí)，網(wǎng)關(guān)首先會(huì)對(duì)請(qǐng)求用戶的身份進(jìn)行鑒定。如果通過驗(yàn)證，用戶信息會(huì)被放入 header 并傳遞給后端服務(wù)，而業(yè)務(wù) API 無需關(guān)注用戶中心的實(shí)現(xiàn)細(xì)節(jié)，直接從 header 中獲取用戶信息即可繼續(xù)工作。

如果業(yè)務(wù)要求用戶必須登錄才能使用，可以在業(yè)務(wù)邏輯中增加一個(gè)判斷，檢查請(qǐng)求 header 是否包含 uid。若缺少 uid，則返回統(tǒng)一的錯(cuò)誤碼給前端，提示用戶需要先登錄。這種鑒權(quán)服務(wù)設(shè)計(jì)有效解耦了業(yè)務(wù)模塊和用戶中心。即使用戶中心邏輯變更，也無需業(yè)務(wù)模塊同步升級(jí)。

此外，除了基本的登錄鑒權(quán)，這種設(shè)計(jì)還可以在網(wǎng)關(guān)層實(shí)現(xiàn)更加靈活的權(quán)限管理。例如，可以為某些域名開啟基于角色的訪問控制（RBAC）或基于屬性的訪問控制（ABAC），為不同的業(yè)務(wù)場(chǎng)景量身定制權(quán)限控制策略。通過網(wǎng)關(guān)，我們還可以為不同用戶提供不同權(quán)限的功能，支持灰度測(cè)試等高級(jí)功能，從而提高系統(tǒng)的靈活性和安全性。

內(nèi)網(wǎng)網(wǎng)關(guān)服務(wù)

了解了外網(wǎng)的兩種妙用，我們?cè)倏纯磧?nèi)網(wǎng)的功能。它可以提供失敗重試服務(wù)和平滑重啟機(jī)制，我們分別來看看。

失敗重試

在項(xiàng)目發(fā)布升級(jí)或服務(wù)發(fā)生故障重啟時(shí)，系統(tǒng)可能會(huì)短暫不可用。這段期間如果有用戶請(qǐng)求，可能會(huì)因?yàn)楹蠖宋错憫?yīng)而返回 504 錯(cuò)誤，影響用戶體驗(yàn)。為提升用戶體驗(yàn)，可以利用內(nèi)網(wǎng)網(wǎng)關(guān)的自動(dòng)重試功能。

當(dāng)請(qǐng)求到達(dá)后端，但因服務(wù)返回 500、403 或 504 等錯(cuò)誤時(shí)，網(wǎng)關(guān)可以避免立即返回錯(cuò)誤。相反，網(wǎng)關(guān)可以讓請(qǐng)求稍作等待，之后再重試；或者直接返回之前緩存的內(nèi)容。通過這種方式，業(yè)務(wù)能夠?qū)崿F(xiàn)平滑的熱更新，讓服務(wù)看起來更為穩(wěn)定，使用戶不會(huì)明顯感知到線上升級(jí)過程中的波動(dòng)。

平滑重啟

在服務(wù)升級(jí)過程中，平滑重啟機(jī)制能夠避免服務(wù)進(jìn)程在接收到 kill 信號(hào)后立即退出。具體做法是先讓服務(wù)停止接收新的請(qǐng)求，同時(shí)等待當(dāng)前正在處理的請(qǐng)求完成。如果請(qǐng)求處理超時(shí)（比如超過 10 秒），則強(qiáng)制退出服務(wù)。這種機(jī)制有助于保證正在進(jìn)行的請(qǐng)求得到妥善處理，減少服務(wù)中斷對(duì)用戶的影響。

通過這個(gè)機(jī)制，用戶請(qǐng)求處理就不會(huì)被中斷，這樣就能保證正在處理中的業(yè)務(wù)事務(wù)是完整的，否則很有可能會(huì)導(dǎo)致業(yè)務(wù)事務(wù)不一致，或只做了一半的情況。有了這個(gè)重試和平滑重啟的機(jī)制后，我們可以隨時(shí)在線升級(jí)發(fā)布我們的代碼，發(fā)布新的功能。不過開啟這個(gè)功能后，可能會(huì)屏蔽一些線上的故障，這時(shí)候可以配合網(wǎng)關(guān)服務(wù)的監(jiān)控，來幫我們檢測(cè)系統(tǒng)的狀態(tài)。

內(nèi)外網(wǎng)關(guān)綜合應(yīng)用

首先來看網(wǎng)關(guān)接口緩存功能，也就是利用網(wǎng)關(guān)實(shí)現(xiàn)一些接口返回內(nèi)容的緩存，適合用在服務(wù)降級(jí)場(chǎng)景，用它短暫地緩解用戶流量的沖擊，或者用于降低內(nèi)網(wǎng)流量的沖擊。具體實(shí)現(xiàn)如下圖所示：

圖片

通過上圖，我們可以看到，網(wǎng)關(guān)的緩存機(jī)制通常是通過臨時(shí)緩存和 TTL（生存時(shí)間）方式來實(shí)現(xiàn)的。當(dāng)用戶請(qǐng)求某個(gè)服務(wù)接口時(shí)，如果該接口的響應(yīng)已被緩存，并且緩存沒有過期，網(wǎng)關(guān)就會(huì)直接返回緩存的數(shù)據(jù)給客戶端。這種方法能夠顯著減輕后端數(shù)據(jù)服務(wù)的負(fù)擔(dān)。

然而，這種方式的選擇是經(jīng)過權(quán)衡的，它犧牲了數(shù)據(jù)的強(qiáng)一致性以換取性能上的提升。同時(shí)，緩存機(jī)制對(duì)性能要求較高，必須確保網(wǎng)關(guān)緩存能夠處理外部流量的高 QPS（每秒查詢數(shù)）。為了避免過多的穿透流量，可以定期通過腳本刷新緩存數(shù)據(jù)。這樣，當(dāng)網(wǎng)關(guān)發(fā)現(xiàn)有有效的緩存時(shí)，就直接返回；如果緩存沒有命中，才會(huì)請(qǐng)求后端服務(wù)，并緩存結(jié)果。

這種實(shí)現(xiàn)方式比單純依賴緩存更為靈活，能夠提高數(shù)據(jù)一致性，但同時(shí)也增加了開發(fā)和維護(hù)的復(fù)雜度，需要額外的代碼和運(yùn)維來確保系統(tǒng)的穩(wěn)定性和數(shù)據(jù)的一致性。

圖片

當(dāng)然這種緩存的數(shù)據(jù)長(zhǎng)度建議不超過 5KB（10w QPS X 5KB = 488MB/s），因?yàn)閿?shù)據(jù)太長(zhǎng)，會(huì)拖慢我們的緩存服務(wù)響應(yīng)速度。

服務(wù)監(jiān)控

最后，我們來討論利用網(wǎng)關(guān)進(jìn)行服務(wù)監(jiān)控的問題。在沒有鏈路跟蹤的情況下，大多數(shù)系統(tǒng)的監(jiān)控通常依賴于網(wǎng)關(guān)的日志。通過分析網(wǎng)關(guān)的訪問日志中的 HTTP 狀態(tài)碼，我們可以判斷服務(wù)是否正常運(yùn)行。同時(shí)，結(jié)合請(qǐng)求的響應(yīng)時(shí)間信息，我們能夠?qū)崿F(xiàn)基本的系統(tǒng)監(jiān)控功能。

具體來說，網(wǎng)關(guān)的訪問日志會(huì)記錄每個(gè)請(qǐng)求的 HTTP 狀態(tài)碼（如 200、500、404 等）和響應(yīng)時(shí)間。這些信息可以幫助我們監(jiān)控服務(wù)的健康狀況，例如判斷是否有異常的錯(cuò)誤碼（如 500 錯(cuò)誤）或請(qǐng)求超時(shí)，進(jìn)而及時(shí)發(fā)現(xiàn)潛在問題。

下面的圖示展示了如何通過網(wǎng)關(guān)來監(jiān)控服務(wù)的運(yùn)行狀態(tài)，請(qǐng)結(jié)合圖示進(jìn)行進(jìn)一步理解，我會(huì)繼續(xù)分析這個(gè)過程的細(xì)節(jié)。

圖片

為了更方便地判斷線上服務(wù)狀況，可以先對(duì)信息進(jìn)行統(tǒng)計(jì)。具體方法是定期聚合訪問日志中的錯(cuò)誤，并匯總不同接口的請(qǐng)求錯(cuò)誤數(shù)量。例如，通過聚合后我們可以得到類似的數(shù)據(jù)：“30秒內(nèi)發(fā)生 500 錯(cuò)誤 20 次，504 錯(cuò)誤 15 次，某域名接口響應(yīng)時(shí)間超過 1 秒的情況 40 次”。這些統(tǒng)計(jì)數(shù)據(jù)幫助我們快速分析服務(wù)的健康狀態(tài)。

與其他監(jiān)控方式不同，網(wǎng)關(guān)監(jiān)控能夠覆蓋所有業(yè)務(wù)，雖然監(jiān)控的粒度較粗，但仍然是一個(gè)有效的方案。如果結(jié)合 Trace，我們可以在訪問日志中記錄 Trace ID，通過這些 ID 進(jìn)一步排查問題的具體原因。這種實(shí)現(xiàn)方式在一些公司（如好未來和極客時(shí)間）已經(jīng)得到了應(yīng)用，提高了故障排查的便利性。