榮耀成立於 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 的新熔斷外掛。其設計特點如下：
-
百分比熔斷策略：支援基於百分比的熔斷策略，提供更精細的控制。
-
三態控制機制：
-
關閉狀態：允許所有請求透過。
-
開啟狀態：拒絕所有請求，直到熔斷時間到期。
-
半開狀態：允許一定量的請求透過，用於評估上游服務是否恢復。
-
靜默數機制：引入靜默數概念，防止少量請求觸發狀態切換。只有當請求數量達到靜默數且失敗率達到閾值時，才會切換至開啟狀態。
-
關閉到開啟：當請求數量達到靜默數且失敗率超過閾值時，熔斷器切換至開啟狀態。
-
開啟到半開：熔斷時間到期後，切換至半開狀態。
-
半開到關閉：在半開狀態下，若放行的請求數量達到配置值且上游服務恢復正常，則切換至關閉狀態；若失敗率仍高或無響應，則切換回開啟狀態。
-
視窗機制：Sentinel 採用滑動視窗，而我們選擇固定視窗，專注於時間內的失敗率，簡化實現並降低效能開銷。
-
架構適配：針對 NGINX 的多程序架構，引入共享記憶體儲存狀態，確保各 worker 行為一致，同時避免滑動視窗帶來的複雜性和效能損耗。
參考下圖左側架構圖，傳統的串聯式 WAF 需要透過修改 DNS 記錄將流量導向 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% 以上，顯著降低流量成本。
-
背景：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 的演講。