AI時代，閘道器更能打了？

2025-05-04 20:46 AI前線

作者 | 澄潭、望宸
閘道器在網路通訊中扮演著諸多角色，包括資料轉發、協議轉化、負載均衡、訪問控制和身份驗證、安全防護、內容稽核，以及服務和 API 顆粒度的管控等，因此常見的閘道器種類有流量閘道器、安全閘道器、微服務閘道器、API 閘道器等。在不同語義下，閘道器的命名也會有所不同，例如 K8s 體系下，有 ingress 閘道器，在 Sping 體系下，有 Spring Cloud Gateway。但不論如何命名，閘道器的管控內容幾乎都離不開流量、服務、安全和 API 這 4 個維度，只是功能側重不同、所遵循的協議有差異。
另外，隨著網際網路從 Web 2.0 邁進到 AI 時代，使用者和網際網路的互動方式，AI 時代下網際網路的內容生產流程都發生了顯著的轉變，這對基礎設施（Infra）提出了新的訴求，也帶來了新的機遇。Infra 包含的內容非常豐富，本文僅從閘道器層面分享筆者的所見所感所悟。
我們先來看一些 AI 時代出現的新場景和新需求：
  • 相比傳統 Web 應用，LLM 應用的內容生成時間更長，對話連續性對使用者體驗至關重要，如果避免後端外掛更新導致的服務中斷？
  • 相比傳統 Web 應用，LLM 應用在服務端處理單個請求的資源消耗會大幅超過客戶端，來自客戶端的攻擊成本更低，後端的資源開銷更大，如何加固後端架構穩定性？
  • 很多 AGI 企業都會透過免費呼叫策略吸引使用者，如何防止黑灰產爬取免費呼叫量封裝成收費 API 所造成的資損？
  • 不同於傳統 Web 應用基於資訊的匹配關係，LLM 應用生成的內容則是基於人工智慧推理，如果保障生產內容的合規和安全？
  • 當接入多個大模型 API 時，如何遮蔽不同模型廠商 API 的呼叫差異，降低適配成本？
在支援大量 LLM 客戶的過程中，我們也看到了一些行業發展趨勢，借本文分享給大家：
  • 網際網路內容的生產機制將從 UGC（User Generate Content） 轉變為 AIGC（Artificial Intelligence Generate Content），網際網路流量增長，除了要考慮傳統的 SEO，還需要考慮 AI 抓取下的 SEO。
  • 目前處於 AI 時代的 Web 1.0 階段，基於靜態內容生成，可以預見，AI 時代的 Web 2.0 不久會到來，基於理解網際網路內容來識別頁面中提供的“可操作能力”，來完成複雜任務，真正的 Web 3.0 也將由 AI 來實現。
  • API 是 LLM 應用的一等公民，並引入了更多流量，催生企業新的生命力和想象空間。
  • LLM 應用對閘道器的需求超越了傳統的流量管控功能，承載了更大的 AI 工程化使命。
AI 場景下的新場景和新需求
相比傳統 Web 應用，LLM 應用在閘道器層的流量有以下三大特徵：
  • 長連線。由 AI 場景常見的 Websocket 和 SSE 協議決定，長連線的比例很高，要求閘道器更新配置操作對長連線無影響，不影響業務。
  • 高延時。LLM 推理的響應延時比普通應用要高出很多，使得 AI 應用面向惡意攻擊很脆弱，容易被構造慢請求進行非同步併發攻擊，攻擊者的成本低，但服務端的開銷很高。
  • 大頻寬。 結合 LLM 上下文來回傳輸，以及高延時的特性，AI 場景對頻寬的消耗遠超普通應用，閘道器如果沒有實現較好的流式處理能力和記憶體回收機制，容易導致記憶體快速上漲。
傳統 Web 應用中普遍使用的 Nginx 閘道器難以應對以上新需求，例如變更配置需要 Reload，導致連線斷開，不具備安全防護能力等。因此國內外均出現了大量基於 Envoy 為核心的新一代開源閘道器，本文將以筆者維護的 Higress (https://github.com/alibaba/higress) 為例展開描述。
Higress 已經為通義千問 APP、靈積平臺 (通義千問 API 服務)、人工智慧平臺 PAI 提供 AI 業務下的閘道器流量接入，以及多個頭部 AGI 獨角獸提供 API 閘道器。這篇文章詳細介紹了 Higress AI 閘道器的能力：《Higress 釋出 v1.4，開放 AI 閘道器能力，增強雲原生能力》
如何實現閘道器配置的熱更新
網際網路從 Web 1.0 演進到 Web 2.0 的時代，網際網路從靜態內容為主，變為動態更新的 UGC 內容為主，大量使用者開始高頻使用網際網路。使用者使用形態，以及網站內容形態的改變，催生了大量技術的變革。例如 HTTP 1.0 到 HTTP 1.1 協議的升級，解決了連線複用的問題。又例如以 Nginx 為代表的基於非同步非阻塞的事件驅動架構的閘道器誕生，解決了 C10K 問題。
到了 AI 時代的網際網路，LLM 驅動的對話式場景，大量採用 SSE/WebSocket/gRPC 等長連線協議來維持會話。閘道器除了要解決併發連線問題，還需要解決配置變更導致連線斷開的問題。配置變更時的連線斷開，不但導致使用者會話斷開，影響體驗，在高併發場景下，斷開後的併發重連風暴很有可能將閘道器和後端業務同時打掛。
而類似 Nginx 這樣 Web 2.0 時代誕生的閘道器，並不能解決此問題，Nginx 的整體配置檔案發生任意變更，都需要重啟 Worker 程序，會同時導致客戶端連線（Downstream）和服務端連線（Upstream）斷開：
筆者參與維護的 Higress 開源閘道器，使用 Envoy 作為資料面，來解決這一問題。Envoy 站在 Nginx 等閘道器的肩膀上，對閘道器配置做了更合理的抽象。例如將處理客戶端連線（Downstream）的監聽器（Listener）配置發現定義為 LDS（Listener Discovery Service），將處理後端服務連線（Upstream）的服務叢集（Cluster）配置發現定義為 CDS（Cluster Discovery Service）。LDS 和 CDS 可以獨立更新，從而 Listener 連線池引數更新不會斷開 Upstream 連線，Cluster 連線池引數更新變了不會斷開 Downstream 連線。
對於跟連線無關的配置，又做了進一步抽象，例如路由配置發現定義為 RDS（Route Discovery Service），TLS 證書 / 金鑰配置發現定義為 SDS（Secret Discovery Service），都可以獨立更新，那麼無論是路由變更，還是 HTTPS 證書變更，都不會導致任何連線斷開：
如何在閘道器層做好安全和流量防護
當前的 AI 技術，尤其是 LLM 正處於快速發展階段。雖然模型壓縮、知識蒸餾等技術正被廣泛應用以提高效率，但 LLM 應用的資源消耗仍然顯著高於傳統 Web 應用。
針對傳統的 Web 應用，服務端處理單個請求的資源消耗通常不會大幅超過客戶端，因此對客戶端來說，發起分散式拒絕服務（DDoS）攻擊的成本相對較高。然而在 LLM 應用的場景中，客戶端透過傳送長文字或提出複雜的推理問題，可以輕易增加服務端的負載，而自身資源消耗甚微。這種情況突顯了在 LLM 應用中部署強大的閘道器安全防護策略的重要性。傳統閘道器，通常具備兩類限流能力：
Higress 不僅支援這些傳統限流能力，例如每秒、每分、每小時和每天的請求次數限制（QPS/QPM/QPH/QPD），還引入了對令牌數量的細粒度管理，採用每分鐘、每小時和每日令牌數（TPM/TPH/TPD）作為衡量指標，除了 QPS，還支援面向 Token 吞吐的限流防護。
“令牌”（Token）在這裡作為一個衡量單位，更準確地量化了 LLM 處理的資料量。對 LLM 應用而言，以令牌而非傳統請求次數來計量使用情況，更能貼切地反映資源消耗和成本開支。同時也支援多種限流統計維度，包括：API、IP、Cookie、請求 Header、URL 引數和基於 Bearer Token 認證的呼叫方。
AI 場景下，後端保護式限流尤其重要，很多 AGI 廠商都有免費的 Web 應用吸引使用者流量，而一些黑灰產可能會爬取頁面呼叫封裝成收費 API 來提供給使用者實現牟利。這種情況下就可以使用 Higress 的 IP、Cookie 等維度的保護式限流進行防護。
此外，當大模型未經過適當的過濾和監控就生成回應時，它們可能產生包含有害語言、誤導資訊、歧視性言論甚至是違反法律法規的內容。正是因為這種潛在的風險，大模型中的內容安全就顯得異常重要。在 Higress 中，透過簡單的配置即可對接阿里雲內容安全服務，為大模型問答的合規性保駕護航。
如何應對大頻寬和高延時的流量特徵
除了能針對 Token 進行限流，基於 Token 的完整可觀測能力，也是 AI Infra 中不可或缺的，例如提供日誌、指標、告警等可觀測能力。下方展示的限流、觀測能力，都依賴對 HTTP 請求 / 響應 Body 的解析處理。
傳統閘道器，如 Nginx/Openresty，以及基於此實現的 Kong/APISIX 等在 Lua 指令碼中處理 Body 時，要求必須對請求 / 響應開啟快取。而基於 Envoy 的開源閘道器，例如 Higress，其外掛擴充套件機制是基於 Wasm 實現的，能夠支援對 Body 的流式處理，以處理請求 Body 為例：

func onHttpRequestBody(ctx wrapper.HttpContext, config Config, chunk []byte, isLastChunk bool, log wrapper.Log) []byte {

log.Infof("receive request body chunk:%s, isLastChunk:%v", chunk, isLastChunk)

return chunk

}

在 AI 場景下，因為大頻寬 / 高延時的流量特徵，閘道器是否對請求 / 響應進行真正的流式處理，影響是巨大的。
首先，LLM 場景下如果閘道器沒有實現流式響應，將嚴重影響使用者受到首個響應的時間，其速度影響能從秒級變到分鐘級，嚴重影響使用者體驗。其次，是對資源開銷的影響。以 Higress 的一個開源使用者 Sealos 舉例（旗下有 FastGPT 等 AI 相關平臺產品），在使用 Nginx 時因為開啟了請求 / 響應快取，在 AI 業務應用被高併發訪問時，閘道器資源水位佔用處於崩潰邊緣。遷移到 Higress 之後，閘道器只需很少資源。因為 Higress 提供了完整的流式轉發能力，而且提供的外掛擴充套件機制也可以流失處理請求 / 響應，在大頻寬場景下，所需的記憶體佔用極低。記憶體雖然相比 GPU 很廉價，但記憶體控制不當導致 OOM，導致業務宕機，損失不可估量。下圖是常態流量下，Sealos 切換前後閘道器使用資源的對比：
如何提升海量域名、海量理由規則下的多租能力
在 AI 場景下，Envoy 的熱更新能力備受青睞，Higress 的一些 AI 平臺場景的使用者，在一開始也選用了基於 Envoy 的閘道器，例如 Contour、Gloo、Istio gateway 等。但大都會遇到兩個問題：
  • 給每個使用者 or 每個模型分配一個域名，數量級達到一萬規模時，新建路由的生效速度至少要 1 分鐘；
  • 對多個租戶域名使用同一本泛域名證書，開啟 HTTP2 時，瀏覽器訪問會遇到 404 問題。
對於第一個問題，其根本原因在於路由規則下發方式不夠精細，社群開發者對此進行過分析。與此相比，Higress 可以在域名級別進行分片載入，即使達到一萬個域名，新增路由的生效時間也只需三秒。此外，Higress 支援按需載入機制，即只有在接收到特定域名的請求時才載入該域名下的路由配置。在配置了大量域名的環境下，這種策略只加載活躍的路由配置，顯著減少了閘道器的記憶體使用。
關於第二個問題，瀏覽器在 HTTP2 環境中會盡量複用連線。兩個請求的域名不同，但解析到的 IP 地址和使用的證書是相同時，連線複用會導致 Host 請求頭與建立連線時的 SNI 不匹配，進而在 Envoy 場景下產生 404 錯誤。多數基於 Envoy 的解決方案是返回 421 狀態碼，提示瀏覽器斷開連線並重新發起請求，但這個解決方案在瀏覽器相容性上存在問題。於是，Higress 借鑑了 Nginx 的辦法，使 SNI 的查詢（TLS 層）與 Host 頭部的查詢（HTTP 層）分離，允許它們不匹配，從而能正確地路由配置（在要求客戶端證書驗證的場景例外）。
Higress 支撐海量域名的能力，也是眾多 MaaS/SaaS 服務用於實現多租的關鍵。比如智算服務 PAI- 靈駿平臺在近期將閘道器從同樣基於 Envoy 實現的 Contour 遷移到了 Higress 之後，新增路由生效的時間從分鐘級變為秒級，同時整體消耗的雲資源也大幅下降。
AI 場景下，閘道器比我們想象中更能打
傳統 Web 應用，閘道器扮演的基礎角色是流量管理。但在 AI 場景下，閘道器正承載著更大的 AI 工程化使命，分別體現著 MaaS/AGI 接入層、應用接入層、和企業內部各類系統對接等。
MaaS/AGI 接入層
整體架構如下，閘道器對接入層進行流量管理，除此之外還具備滿足負載均衡和流量灰度和觀測的能力。
負載均衡：
由於 AI 場景下，閘道器的後端通常是模型服務本身，對閘道器的負載均衡能力提出了特殊要求。由於 LLM 場景具有高延時，且不同請求差異大的特點，傳統的 Round Robin 負載均衡策略無法正確平衡負載。Higress 目前採用基於最小請求數的均衡策略，將請求優先轉發給當前處理中請求最少的後端節點。針對模型服務負載均衡的挑戰，Higress 計劃在未來透過呼叫一個低延時的小引數模型進行旁路預測，以估計每個後端節點的即時負載，從而儘量將請求傳送給負載最低的後端節點。
流量灰度和觀測：
AGI 廠商高度依賴 A/B 測試和服務灰度能力來進行模型迭代。作為流量入口，AI 閘道器需要在流量灰度和觀測方面發揮關鍵作用，包括灰度打標以及入口流量延時和成功率等指標的監測。Higress 憑藉其在雲原生微服務閘道器領域的經驗，已經積累了強大的能力來滿足這些需求。
AI 應用層
整體架構如下：
跟隨 GPT4 等模型的爆火，湧現了大量的優秀的 AI SaaS 應用，例如：
  • makelogo.ai：AI 生成產品 Logo
  • MyMap.ai：AI 輔助規劃 Idea
  • Gamma：AI 生成 PPT
  • Podwise：AI 輔助檢視播客
許多 AI 應用開發者，尤其是獨立開發者，通常不會自己部署模型服務，而是直接利用模型廠商提供的強大 API 來實現創意應用。值得注意的是，許多開發者來自國內。然而，由於底層技術依賴於 OpenAI 等海外 LLM 廠商，這些技術可能不符合國內法規。為了避免潛在的麻煩，這些開發者往往選擇將產品推向國際市場，而不是面向國內使用者。
隨著國內大模型技術逐漸趕上 OpenAI 等廠商，並且國內 API 在價格上具有競爭優勢，越來越多的 AI 應用預計會選擇使用國內廠商的 API 來實現相關功能。這將對閘道器提出特定需求：
  • 透過閘道器的統一協議，遮蔽不同模型廠商 API 的呼叫差異，降低適配成本。
  • 對涉黃涉政等敏感內容進行遮蔽和過濾，更好地符合國內法規要求。
  • 切換模型後的 A/B 測試以及效果觀察和對比，包括延遲、成本、使用者使用頻率等因素。
Higress 目前支援的 LLM Provider 有：通義千問、OpenAI/Azure OpenAI、月之暗面、百川智慧、零一萬物、智譜 AI、階躍星辰、文心一言、騰訊混元、DeepSeek、Anthropic Claude、Groq、MiniMax、Ollama 等，藉助 Higress 活躍的開源開發者社群，支援的型別還在持續增加中。
企業內部 AI 閘道器
整體架構如下：
大量 AGI 廠商在閉源和開源模型能力方面展開競爭，而受益者主要是企業使用者。企業在選擇模型時需要在效能和成本之間做 trade-off。面對眾多模型，尤其是在廠商提供的 API 不一致時，企業需要一個統一的閘道器來遮蔽模型協議的差異，從而提供一個統一介面，便於企業內部系統的對接和使用。在這種場景下，閘道器的架構類似於 ESB（企業服務匯流排）的架構，即所有內部 AI 流量都透過閘道器進行統一治理。這樣的架構帶來了以下好處：
  • 成本分攤計算：藉助閘道器的觀測能力，可以審計企業內部不同業務部門的 Token 消耗量，用於成本分攤並發現不合理的成本。
  • 提高穩定性：基於閘道器提供的多模型對接能力，當主用模型呼叫失敗時，可以自動切換至備用模型，保障依賴 AI 能力的業務穩定性。
  • 降低呼叫成本：在一些固定業務流程中，LLM 介面的輸入輸出相似性較高時，可以基於向量相似性進行快取召回，從而降低企業的 AI 呼叫成本。
  • 認證和限流：透過對企業內員工的 API 呼叫進行限量控制，管理整體成本。
  • 內容安全：實現統一的內容安全管理，禁止傳送敏感資料，防止企業敏感資料洩漏。
這種架構下，閘道器不再只是接入層的流量閘道器，而是要處理來自所有依賴 AI 能力的業務模組的訪問流量。閘道器更能打了。
暢想 AI 時代的網際網路發展
筆者發現在 AI 火了之後，大家已經很少提 Web 3.0 的概念了。而且很有趣的一個事是，CDN 和網路防護提供商 CloudFlare，已經將控制檯內的一級入口 Web 3.0 換成了 AI，並集成了 Workers AI 和 AI Gateway 這兩款產品。而筆者覺得，真正的 Web 3.0 也許將由 AI 帶來。
就像 Web 1.0 到 Web 2.0 的演進，使用者的互動方式和網際網路的內容形式發生了徹頭徹尾的改變，我們其實已經身處在類似的改變之中。例如，筆者的常用搜索工具從 Google 換到了 Perplexity。做網際網路流量增長，除了要考慮傳統的 SEO，還需要考慮 AI 抓取下的 SEO，下面來自 Perplexity 對這一問題的回答：
到並不是說 Perplexity 未來一定會替代 Google，但這種改變其實反應了一種趨勢：
  • 從使用者角度看，使用者從主動參與網際網路轉變為透過 AI 幫助參與。
  • 從內容角度看，不僅需要服務於真實使用者，還要同時服務於 AI。
Perplexity 這樣的工具還只是基於靜態內容，可以類比為 AI 時代的 Web 1.0。可以預見，AI 時代的 Web 2.0 會是：
  • 電商場景下，在使用者瀏覽商品時，AI 將充當導購，根據商品資訊與使用者對話，並在使用者確認後自動下單；
  • 出行場景下：AI 將根據使用者的出行目標地點自動安排旅行計劃，瞭解使用者喜好，預訂沿途餐廳和酒店；
  • OA 場景下：使用者需要操作資源時，AI 將自動提交審批申請，查詢審批狀態，並在獲批後完成資源操作。
在這種模式下，AI 需要理解網際網路內容，並識別頁面中提供的“可操作能力”，從而代替人類執行操作。蘋果宣佈將在 iOS 18 中 大幅提升 Siri 的能力，未來 Siri 將能夠訪問應用程式的各種功能，這也需要應用程式為 AI 提供“可操作能力”的宣告。HTML 也有相關社群提案，讓 AI 可以更方便地識別頁面中的可執行任務，明確其輸入和輸出定義。
未來的網際網路內容，無論是 APP 還是 HTML 場景，都將面向 AI 進行改變。核心在於讓 AI 知道如何操作頁面內容，從而幫助使用者完成複雜任務。為 AI 提供的“可操作能力”宣告，實際上就是 API 宣告。當前，大量網際網路應用，尤其是 ToC 應用，API 僅在內部開發過程中使用，最高頻使用 API 的可能是前端或 BFF 層的開發人員。在國內，由於研發成本普遍低於國外，不會為了降低前後端對接成本，而去最佳化 API 設計，開發過程中往往忽略了 API 的重要性。因此，雖然在海外 API 管理產品的市場競爭已經是一片紅海，但在國內 API 管理以及 API First 的理念並不普及。
隨著 AI 操作網際網路場景的不斷增加，API 將成為 LLM 應用的一等公民，API 管理的重要性將愈發明顯。類似於 Perplexity 在抓取頁面內容時使用清晰的標題、小標題和列表以便 AI 更容易理解和提取內容；定義清晰的 API、明確的輸入輸出引數，以及 API 的版本管理，將變得至關重要。
對閘道器來說，應迴歸本質，在 AI 的加持下，幫助使用者做好 API 的設計、管理將成為核心能力。而透過合理設計的 API，閘道器也可以更深入地瞭解所處理流量的業務含義，從而實現更智慧化的流量治理。
內容推薦
AIGC技術正以驚人的速度重塑著創新的邊界，InfoQ 首期《大模型領航者AIGC實踐案例集錦》電子書，深度對話30位國內頂尖大模型專家，洞悉大模型技術前沿與未來趨勢，精選10餘個行業一線實踐案例，全面展示大模型在多個垂直行業的應用成果，同時，揭秘全球熱門大模型效果，為創業者、開發者提供決策支援和選型參考。關注「AI前線」，回覆「領航者」免費獲取電子書。
活動推薦
AICon 全球人工智慧開發與應用大會，為資深工程師、產品經理、資料分析師等專業人群搭建深度交流平臺。聚焦大模型訓練與推理、AI Agent、RAG 技術、多模態等前沿議題，匯聚 AI 和大模型超全落地場景與最佳實踐，期望幫助與會者在大模型時代把握先機，實現技術與業務的雙重飛躍。
在主題演講環節，我們已經邀請到了「蔚來創始人 李斌」，分享基於蔚來汽車 10 年來創新創業過程中的思考和實踐，聚焦 SmartEV 和 AI 結合的關鍵問題和解決之道。大會火熱報名中，7 月 31 日前可以享受 9 折優惠，單張門票節省 480 元（原價 4800 元），詳情可聯絡票務經理 13269078023 諮詢。
你也「在看」嗎？👇

相關文章