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

外網網關功能

我們先從外網網關的用法說起，我會給你分享兩類外網網關的實用設計，兩個設計可以幫助我們預防入侵和接觸業務的依賴。

蜘蛛嗅探識別

在處理大流量網站時，常見的安全問題包括非法引用和機器人抓取。為了防止這些問題，我們可以采取一些有效的策略，例如通過網關實現限速和入侵檢測功能。

非法引用防范：非法引用通常會導致我們網站的資源被濫用。一種常見的防范方法是檢查請求中的 referer 字段。如果請求的 referer 不是本站域名，就拒絕該請求。這能有效降低資源被未經授權訪問的風險。

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

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

通過這些措施，我們可以有效應對非法引用和機器人抓取問題，保護網站的資源和數據安全。同時也能保持對搜索引擎的友好性，保證 SEO 的正常運作。

網關鑒權與用戶中心解耦

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

用戶鑒權通常會通過在各個子業務中集成用戶中心的 SDK 來實現一致的校驗邏輯。這種方式帶來便利的同時，也產生了新的問題：SDK 的同步依賴和升級維護。基礎公共組件一般會通過 SDK 為業務開發提供便捷，而如果僅通過 API 提供服務，一些特殊的操作可能會需要重復實現。然而，一旦 SDK 發布，我們就需要做好同時維護多個版本 SDK 在線工作的準備，以確保兼容性和功能穩定。

以下圖展示了使用 SDK 鑒權 token 方式和直接通過用戶中心接口進行鑒權的效果對比：

圖片

在集成 SDK 的情況下，各業務可以自行校驗用戶身份，無需頻繁請求用戶中心。然而，這種方案也帶來了一些挑戰。由于 SDK 是嵌入在各個項目中的組件，項目通常不會頻繁升級其版本來保持穩定性。這使得用戶中心的后續升級面臨阻力，因為升級時必須考慮到所有依賴的業務。每次基礎服務的大規模升級都需要大量人力來同步更新 SDK，從而增加了維護的復雜性。

為了解決這種耦合問題，我們可以考慮另一種設計思路，即將用戶登錄鑒權功能放到網關層。這樣一來，業務系統不再需要直接依賴用戶中心的 SDK，而是通過網關完成身份驗證和權限校驗。通過這種方式，網關可以在接收到請求時直接進行用戶鑒權，只有通過驗證的請求才會被轉發至具體的業務服務，從而解耦了用戶中心與各業務系統的直接依賴關系。

以下圖所示為這一設計下的請求流程，請結合示意圖參考，我將進一步分析其工作機制和優點。

圖片

結合上圖，我們來看這種設計的實現流程。當用戶請求業務接口時，網關首先會對請求用戶的身份進行鑒定。如果通過驗證，用戶信息會被放入 header 并傳遞給后端服務，而業務 API 無需關注用戶中心的實現細節，直接從 header 中獲取用戶信息即可繼續工作。

如果業務要求用戶必須登錄才能使用，可以在業務邏輯中增加一個判斷，檢查請求 header 是否包含 uid。若缺少 uid，則返回統一的錯誤碼給前端，提示用戶需要先登錄。這種鑒權服務設計有效解耦了業務模塊和用戶中心。即使用戶中心邏輯變更，也無需業務模塊同步升級。

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

內網網關服務

了解了外網的兩種妙用，我們再看看內網的功能。它可以提供失敗重試服務和平滑重啟機制，我們分別來看看。

失敗重試

在項目發布升級或服務發生故障重啟時，系統可能會短暫不可用。這段期間如果有用戶請求，可能會因為后端未響應而返回 504 錯誤，影響用戶體驗。為提升用戶體驗，可以利用內網網關的自動重試功能。

當請求到達后端，但因服務返回 500、403 或 504 等錯誤時，網關可以避免立即返回錯誤。相反，網關可以讓請求稍作等待，之后再重試；或者直接返回之前緩存的內容。通過這種方式，業務能夠實現平滑的熱更新，讓服務看起來更為穩定，使用戶不會明顯感知到線上升級過程中的波動。

平滑重啟

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

通過這個機制，用戶請求處理就不會被中斷，這樣就能保證正在處理中的業務事務是完整的，否則很有可能會導致業務事務不一致，或只做了一半的情況。有了這個重試和平滑重啟的機制后，我們可以隨時在線升級發布我們的代碼，發布新的功能。不過開啟這個功能后，可能會屏蔽一些線上的故障，這時候可以配合網關服務的監控，來幫我們檢測系統的狀態。

內外網關綜合應用

首先來看網關接口緩存功能，也就是利用網關實現一些接口返回內容的緩存，適合用在服務降級場景，用它短暫地緩解用戶流量的沖擊，或者用于降低內網流量的沖擊。具體實現如下圖所示：

圖片

通過上圖，我們可以看到，網關的緩存機制通常是通過臨時緩存和 TTL（生存時間）方式來實現的。當用戶請求某個服務接口時，如果該接口的響應已被緩存，并且緩存沒有過期，網關就會直接返回緩存的數據給客戶端。這種方法能夠顯著減輕后端數據服務的負擔。

然而，這種方式的選擇是經過權衡的，它犧牲了數據的強一致性以換取性能上的提升。同時，緩存機制對性能要求較高，必須確保網關緩存能夠處理外部流量的高 QPS（每秒查詢數）。為了避免過多的穿透流量，可以定期通過腳本刷新緩存數據。這樣，當網關發現有有效的緩存時，就直接返回；如果緩存沒有命中，才會請求后端服務，并緩存結果。

這種實現方式比單純依賴緩存更為靈活，能夠提高數據一致性，但同時也增加了開發和維護的復雜度，需要額外的代碼和運維來確保系統的穩定性和數據的一致性。

圖片

當然這種緩存的數據長度建議不超過 5KB（10w QPS X 5KB = 488MB/s），因為數據太長，會拖慢我們的緩存服務響應速度。

服務監控

最后，我們來討論利用網關進行服務監控的問題。在沒有鏈路跟蹤的情況下，大多數系統的監控通常依賴于網關的日志。通過分析網關的訪問日志中的 HTTP 狀態碼，我們可以判斷服務是否正常運行。同時，結合請求的響應時間信息，我們能夠實現基本的系統監控功能。

具體來說，網關的訪問日志會記錄每個請求的 HTTP 狀態碼（如 200、500、404 等）和響應時間。這些信息可以幫助我們監控服務的健康狀況，例如判斷是否有異常的錯誤碼（如 500 錯誤）或請求超時，進而及時發現潛在問題。

下面的圖示展示了如何通過網關來監控服務的運行狀態，請結合圖示進行進一步理解，我會繼續分析這個過程的細節。

圖片

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

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