作者 | 付家浩、許偉川

關于榮耀

榮耀成立于 2013 年，是全球領先的智能終端提供商。榮耀的產品已銷往全球 100 多個國家和地區，并與 200 多個運營商建立了合作關系。榮耀在全球的體驗店與專區專柜超 52000，在網設備數超 2.5 億。

作為全球領先的 AI 終端生態公司，榮耀致力于變革人機交互方式。憑借涵蓋智能手機、個人電腦、平板電腦、可穿戴設備等多元化的創新產品組合，榮耀旨在賦能每一位用戶，讓每個人都能輕松踏入并享受嶄新的智能世界。

榮耀網關平臺的演進與架構

演進

• 榮耀于 2021 年開始接觸流量網關產品，Q3 開始對 APISIX 進行相關的預研工作，在 Q4 正式引入 APISIX，啟動了榮耀公司內部流量網關平臺的建設。

• 2022 年 APISIX 網關在榮耀內部正式投入商用。Q1 面向 To C 業務的流量接入試點推廣；Q2，開放平臺 API 供部署平臺使用，支持流量調度和容器實例上報。此外，在部署平臺尚未完全構建完成的情況下，能夠通過腳本調用 API 的方式進行流量接入與調度。

• 2023 年，Q1 完成了 APISIX-CP 容器化能力的構建， Q3 上線了 APISIX-DP 彈性伸縮能力。Q4 單集群超千萬連接，年底完成了全量云服務 ToC 業務覆蓋。

• 2024 年，Q1 完成 APISIX-DP 容器化的構建，Q2 運行面架構優化至 2.0，Q4 達成單集群百萬 QPS，年底覆蓋榮耀全量業務。

• 到目前為止，榮耀內部基于 APISIX 的網關平臺的流量峰值達數百萬 QPS，基于 APISIX 的可擴展能力，目前有近百個自定義插件。

• 接下來榮耀技術團隊將探索 AI 與 網關的有效結合。另外，如何實現網關與 Kubernetes 的服務自動上報能力。

網關平臺架構

網關架構詳解

• 內外網支持的協議

榮耀的網關架構分為內網訪問和外網訪問兩部分：

• • 外網支持協議： QUIC 和 HTTPS。

  • 內網支持協議： HTTP、HTTPS 和 gRPC，其中 gRPC 主要承載與 AI 相關的流量，近一年內其 QPS 明顯上漲。

• 負載均衡器與代理選擇

• • 在 APISIX 前端部署了一臺負載均衡器（LB），用于接入公有云的四層代理和七層代理。

  • 四層代理：最初用于發布所有路由，但隨著業務上線，發現四層代理無法解決某些問題，因此切換為七層代理。

• API 集群與插件市場

• • API 集群：不同集群共享 etcd。

  • 插件市場：列出了常見插件，如認證、限流、WAF、染色等。

  • 上游部署：主要以容器為主，少量虛擬機。容器對接部署平臺，平臺在容器部署完成后調用 API 上報流量和實例信息。

• 日志采集與分析：未使用原生 Prometheus 插件，而是通過 Kafka 采集日志，結合 Elk 進行指標分析和告警能力的建設。

• etcd 負載均衡優化：在 etcd 前端增加了一層 LB，解決直接連接 etcd 節點時負載不均的問題（如節點連接數過高）。

網關平臺功能

• 用戶全流程管理：從域名管理、證書管理到路由注冊，覆蓋灰度功能。

• 插件管理：用戶通過插件市場上傳插件，平臺進行審核和部署。

• 智能化部署：屏蔽底層云差異，支持自動化部署和公共云適配。

低損升級

由于平時插件變更頻繁，因而業務比較關心低損升級。通過 LB 將 APISIX 節點摘除，確保流量完全下線后再進行升級，實現無損和自動化升級。

彈性伸縮

應對大流量場景時，通過虛擬機快速擴容和及時恢復，支持自動擴容（如 CPU 超過閾值時自動擴容機器并掛載到 LB）。

插件部署與自動化

• 插件部署：管理面平臺與運行面關聯，通過配置下發到 CP 進行容器化部署。

• CP 和 DP 隔離：CP 和 DP 連接 etcd 集群，實現管理面和運行面的隔離。

榮耀海量業務下的網關實踐

關于 APISIX 在榮耀海量業務下的實踐，最初我們使用 APISIX 的原生插件，隨著業務發展和要求，原生插件已經無法滿足我們的需求。因此我們基于平臺或者用戶基于自身的需求擴展了一些插件，目前已經有 100 多個。

插件主要分為四個部分：流量控制、認證、安全、可觀測。由于我們的集群基本都是通過雙 AZ（Availability Zone，可用區） 部署實現可靠性，因而衍生的問題就是跨 AZ 的時延，這個問題需要網關來解決，通過網關實現同 AZ 就近轉發。

可觀測：流量鏡像

請求處理與流量鏡像

當請求到達 APISIX 后，流量會被繼續轉發至上游。在此過程中，請求會被鏡像至第三方物資平臺。然而，該鏡像過程為阻塞型操作，即當錄制平臺未返回流量時，客戶端請求會被阻塞。若錄制平臺出現故障，將嚴重影響正式流量的穩定性。因此，我們未選擇使用 NGINX 或 APISIX 內置的鏡像能力，而是通過自定義插件實現異步處理。

自定義插件實現

自定義插件的實現方式如下：

• 請求到達時：將請求異步保存至隊列中。

• 上游處理：APISIX 將請求轉發至上游，上游返回響應后，客戶端請求流程結束。

• 異步錄制：通過異步線程從隊列中提取請求，并將其發送至錄制平臺進行數據錄制。由于錄制請求包含時間戳，異步操作不會影響正式流量。

錄制平臺功能

錄制平臺負責收集數據，支持以下功能：

• 回放時調整流量規模（擴大或縮小）。

• 為回放請求添加特定的請求頭，從而實現全鏈路壓測能力。

隊列與線程優化

為確保系統性能，我們支持配置隊列大小和線程性能參數。雖然異步轉發不會直接影響正式請求，但若異步流量過大，仍可能增加 APISIX 的 CPU 負載。因此，建議根據業務需求選擇最優參數，以平衡性能與錄制效率。

流量調度：灰度插件

當前灰度能力已實現平臺化，并對灰度插件進行了優化改造。

灰度插件優化

傳統灰度插件支持基于規則或流量百分比的灰度功能，但其流量百分比灰度可能導致流量分配不一致，例如同一請求在不同時間可能被分配到不同的灰度環境。這種情況在 To C 場景中可能影響業務的穩定性。

為解決這一問題，我們在灰度插件前引入了哈希插件 key-hash，結合灰度插件實現穩定的灰度百分比分配。具體實現方式如下：

• 支持基于特定請求頭或 Cookie 的輸入進行哈希計算。

• 將哈希結果作為灰度插件的輸入，用于確定流量分配的百分比。

通過這種方式，確保流量分配的一致性和穩定性，滿足 To C 場景的業務需求。

全鏈路灰度插件改造

在全鏈路灰度場景中，我們對灰度插件進行了改造，以實現精準的流量調度。如圖所示，服務 A 存在灰度狀態，而服務 B 和 C 處于正式環境。為實現服務 A 到 B 的流量保持當前流向，同時將服務 C 的流量導向灰度環境，這一目標是通過網關能力實現的。以下是具體實現方式。

• 流量打標與請求頭插入：

• • 當流量通過 APISIX 網關時，會根據灰度策略對流量進行打標。

  • 若通過的流量為灰度流量，網關會在請求中插入特定的請求頭（如 honor-tag:gray），標識該請求為灰度流量。

• 服務注冊與標識：

• • 服務 A 在注冊到注冊中心時，會將自己的灰度標識（如 gray）一并注冊。

  • 注冊中心維護了服務的灰度標識與實例的映射關系。

• 服務間調度邏輯：

• • 服務 A 調用服務 B：

  • • 服務 A 收到請求后，首先檢查請求中是否包含灰度標識（如 honor-tag:gray）。

    • 若請求包含灰度標識，服務 A 會根據該標識從注冊中心獲取服務 B 的灰度實例，并優先調度灰度實例。

    • 若服務 B 沒有灰度實例，則降級調度正式實例。

  • 服務 B 調用服務 C：

  • • 服務 B 收到服務 A 傳遞的灰度標識（如 honor-tag:gray）后，同樣會根據該標識從注冊中心獲取服務 C 的灰度實例。

    • 若服務 C 存在灰度實例，則將請求調度到灰度實例；否則，調度正式實例。

• 全鏈路灰度實現：

• • 通過請求頭的透傳（如 honor-tag:gray），確保灰度標識在服務鏈路中保持一致。

  • 服務鏈路中的每個節點根據灰度標識進行調度決策，從而實現全鏈路灰度能力。

通過上述改造，我們實現了全鏈路灰度的精準調度，確保灰度流量在整個服務鏈路中的一致性和穩定性。

流控與安全

APISIX 提供了豐富的插件能力，涵蓋單機限流和分布式限流方案。以下是針對單機限流方案的優化實踐。

限流

單機限流

問題描述

在最初采用單機限流方案時，我們遇到了一些挑戰：用戶若需設置全局限流值（如 4000 QPS），需手動協調平臺管理員確認網關節點數量，并根據節點數量分配限流值（如 2 個節點需各配置 2000 QPS）。此過程繁瑣且易出錯。

在彈性伸縮場景下，網關觸發擴容或縮容時，限流值可能出現不匹配問題。例如，當 CPU 使用率達到 80% 時觸發彈性擴容，假設初始配置為每個節點限流值為 2000，擴容后節點數量增加至 3 個，總限流值會變為 6000，這可能導致后端服務因流量超出承載能力而異常。

優化方案

為解決上述問題，我們引入了以下優化措施：

• 節點信息上報與維護

• • 實現方式：采用開源的 server-info 插件，定時將每個 DP 節點的信息（包括主機名等）以帶租約的 Key 寫入 etcd。

  • “心跳機制”：通過定時更新（類似心跳機制），確保 etcd 中始終維護網關中存活的全量 DP 節點信息。

• 動態限流計算

• • 插件開發：新開發插件定時從 etcd 中拉取全量節點信息，獲取網關節點總數。

  • 排除 CP 節點：通過特殊方式排除 CP 節點（控制面不承載流量），僅統計實際承載流量的 DP 節點數量。

  • 動態調整限流值：插件在限流時動態計算每個節點需要承載的限流基數，確保限流值與實際節點數量匹配。

• 性能優化

• • 特權進程拉取：僅允許特權進程定期從 etcd 拉取網關信息，避免 APISIX 對 etcd 的壓力，同時降低 APISIX 本身的開銷。

  • 共享內存機制：特權進程將拉取的數據寫入共享內存，其他進程通過定期查詢共享內存獲取節點信息。

• 插件抽象與復用

• • 公共插件抽象：將動態限流優化能力抽象為公共插件，提供統一接口。

  • 插件復用：內部大量插件（如固定窗口限流、自定義性能插件等）可通過查詢共享內存獲取節點數，并動態調整配置，以適配優化需求。

分布式限流

接下來是分布式限流，APISIX 開源社區也提供了分布式限流方案。

問題描述

在應用開源分布式限流方案時，我們遇到了以下關鍵問題：

• Redis 性能瓶頸：單 key 限流場景下，當限流規則針對整個路由而非路由特征時，Redis 的 key 會過于單一，導致所有請求集中到同一個 Redis 分片，無法通過橫向擴容實現負載均衡。

• 網絡性能消耗：頻繁的 Redis 請求導致網關節點 CPU 使用率上升 50%+。

• 請求時延增加：開源分布式限流方案需先訪問 Redis 完成計數，再將請求轉發至上游，導致業務請求時延增加 2-3 毫秒。

優化方案

為解決上述問題，我們設計了以下優化方案：

• 引入本地計數緩存：

• • 本地計數機制：請求到達時，首先在本地計數緩存中扣除一個計數。只要計數未降至 0，請求即被放通。

  • 異步同步機制：本地計數通過異步方式定期與 Redis 同步，統計兩次同步期間的請求量，并在 Redis 中扣除相應的計數。同步完成后，Redis 的計數覆蓋本地緩存，確保分布式限流的一致性。

• 誤差控制：通過合理的公式計算和參數配置，將誤差率控制在 3%-4% 的范圍內，確保限流精度滿足業務需求。

• 適用場景

• • 高 QPS 應用：該方案適用于 QPS 較大的應用，能夠顯著降低 Redis 的性能瓶頸和網絡開銷。

  • 低 QPS 應用：對于 QPS 較低（如幾百 QPS）的應用，現有的分布式限流方案已基本滿足需求，無需額外優化。

基于 APISIX 開發高可靠性的熔斷插件

問題描述

盡管開源社區提供了熔斷插件功能，但經過評估，發現其無法滿足內部需求，主要體現在以下兩點：

• 缺乏失敗率支持：開源熔斷插件的策略不支持基于失敗率的熔斷。

• 狀態切換問題：熔斷插件僅有開啟 / 關閉兩種狀態，可能導致狀態切換時放行大量請求，加劇上游服務惡化，甚至可能在上游響應超時時拖垮網關。

自研熔斷插件設計

為解決上述問題，榮耀開發了基于 APISIX 的新熔斷插件。其設計特點如下：

• 百分比熔斷策略：支持基于百分比的熔斷策略，提供更精細的控制。

• 三態控制機制：

• • 關閉狀態：允許所有請求通過。

  • 打開狀態：拒絕所有請求，直到熔斷時間到期。

  • 半開狀態：允許一定量的請求通過，用于評估上游服務是否恢復。

• 靜默數機制：引入靜默數概念，防止少量請求觸發狀態切換。只有當請求數量達到靜默數且失敗率達到閾值時，才會切換至打開狀態。

狀態切換流程

• 關閉到打開：當請求數量達到靜默數且失敗率超過閾值時，熔斷器切換至打開狀態。

• 打開到半開：熔斷時間到期后，切換至半開狀態。

• 半開到關閉：在半開狀態下，若放行的請求數量達到配置值且上游服務恢復正常，則切換至關閉狀態；若失敗率仍高或無響應，則切換回打開狀態。

基于 Sentinel 的設計更新

• 窗口機制：Sentinel 采用滑動窗口，而我們選擇固定窗口，專注于時間內的失敗率，簡化實現并降低性能開銷。

• 架構適配：針對 NGINX 的多進程架構，引入共享內存存儲狀態，確保各 worker 行為一致，同時避免滑動窗口帶來的復雜性和性能損耗。

3.3 旁路 WAF 改造提升鏈路可靠性

串聯式 WAF 的局限性

參考下圖左側架構圖，傳統的串聯式 WAF 需要通過修改 DNS 記錄將流量導向 WAF，WAF 清洗流量后再轉發回源站。然而，這種架構容易導致單點故障。若 WAF 本身發生故障，可能導致整個鏈路中斷，影響業務流量。

旁路 WAF 改造

為解決上述問題，榮耀聯合支流科技和騰訊云進行了旁路 WAF 的改造：

• 流量路徑優化：流量無需先經過 WAF，而是直接請求到 APISIX 集群。

• 分流量檢測：在 APISIX 集群中，將部分流量轉發至 WAF 進行檢測，判斷流量是否正常或是否包含惡意攻擊（如出口攻擊和命令出口攻擊）。

• 狀態碼響應機制：

• • 若 WAF 檢測到流量正常，返回 200 狀態碼，請求被放通到上游。

  • 若 WAF 檢測到惡意攻擊，返回類似 403 的狀態碼，請求被拒絕。

• 故障容錯：若 WAF 發生故障，流量可直接轉發到后端，避免因 WAF 故障導致鏈路中斷，提升整體鏈路的可靠性。

性能與成本優化

性能優化

健康檢查器優化

• 問題背景： 內部業務流量較大，上游節點數量多（上千個節點），滾動更新時頻繁觸發健康檢查器的銷毀和創建，導致 CPU 使用率飆升。

• 問題描述：

• • 銷毀與創建邏輯： 上游更新時銷毀健康檢查器，僅在客戶端請求到達時探測健康檢查器是否存在，若不存在則立即創建。

  • 逐節點添加： 創建時需遍歷所有節點，逐個添加到健康檢查器的共享內存中，涉及大量鎖操作和內存寫入，性能損耗顯著。

• 優化措施：

• • 延遲銷毀： 在上游更新時暫時不銷毀健康檢查器，僅丟失引用，減少頻繁銷毀和創建的性能損耗。

  • 緩存機制： 創建健康檢查器時，將其放入緩存并記錄創建時間。 后續請求若發現健康檢查器不存在，先補充緩存； 若未過期則直接返回，過期則重新創建。

  • 批量更新：將所有上游節點批量更新到健康檢查器的共享內存，減少逐節點操作的開銷。

  • 并發控制：引入并發控制機制，確保同一時刻只有一個 worker 負責健康檢查器的創建，避免多個 worker 同時執行相同操作，顯著降低 CPU 消耗。

• 優化效果：在 2000 個上游節點的頻繁更新場景下，優化后的 CPU 使用率僅增長約 2%，相比優化前的 20% 增長，性能損耗大幅降低，優化效果顯著。

成本優化

成本優化主要包括三點：流量壓縮、EIP 靜態單線改造、網關擴縮容。

流量壓縮

• 背景：經過對網關成本的統計分析，總體大約 3/4 左右的成本是流量成本。因此我們的優化首先需要針對流量。

• 優化措施：提供 br 和 gzip 等壓縮插件，支持動態壓縮。這種插件對于業務而言非常友好，只需在請求中加入壓縮標識即可使用，客戶端和瀏覽器通常支持解壓操作。

• 效益：在云廠商的 LB 計費模式中，流量大小是最主要的計費因子。通過壓縮插件降低 LB 費用和 EIP 帶寬費用，最大壓縮率可達 70% 以上，顯著降低流量成本。

EIP 靜態單線改造

• 背景：BGP EIP 的帶寬費用高昂。

• 優化措施：

• • 為網關集群配置電信靜態單線 EIP，輔以兜底的 BGP EIP。

  • 通過 DNS 智能解析，為主流運營商線路指定對應的單線 EIP。

• 效益：單線 EIP 的價格僅為 BGP 的 1/3，可節約約 2/3 的公網帶寬成本。

網關擴縮容

• 優化措施：基于 CPU 和內存使用率進行網關的彈性擴縮容。

• 目標：確保資源利用率保持在合理區間，避免資源浪費或不足。

總 結

榮耀自 2021 年引入 APISIX 以來，通過持續的優化與擴展，構建了一個高性能、高擴展性且可靠的網關平臺，成功支持了海量業務的快速發展。

榮耀的網關平臺經歷了從試點推廣到全量業務覆蓋的演進過程，流量峰值達到數百萬 QPS，并開發了近百個插件以滿足多樣化的業務需求。通過內外網協議優化、負載均衡器升級、插件市場建設等措施，提升了架構的穩定性和擴展性。在功能上，實現了灰度發布、限流、熔斷、旁路 WAF 等優化，確保精準調度與高可靠性。性能方面，健康檢查器優化和并發控制顯著降低了 CPU 消耗。成本上，通過流量壓縮、EIP 改造和擴縮容策略大幅降低費用。

展望未來，榮耀將繼續探索 AI 與 API 網關的結合，進一步提升平臺的智能化水平，并通過容器自動上報機制等創新手段，助力內部團隊在 Kubernetes 環境中實現高效的資源管理和業務部署。

作者簡介：

付家浩、許偉川，榮耀 PAAS 平臺部工程師。本文整理自 2025 年 4 月 12 日兩位工程師在 APISIX 深圳 Meetup 的演講。