天美工作室群 Timi Studio Group 是騰訊遊戲旗下精品遊戲研發工作室，也是多款熱門手遊的研發商，包括《使命召喚手遊》、《寶可夢大集結》、《Honor Of Kings》（《王者榮耀》國際版）和《王者榮耀》。

其代表作《王者榮耀》是全球最受歡迎的 MOBA 手遊之一，截止到 2023 年 12 月，王者榮耀單日活躍人數最高破 1 億 6 千萬，最高同時線上人數破 300 萬，總下載次數逾 38 億次，註冊使用者數亦突破 3 億。2017 年 5 月取得全球手遊綜合收入榜冠軍。（資料來源：維基百科）

我們所在的團隊在業務開發中主要採用 Golang 語言，同時負責部分運維職責。鑑於團隊在運維領域的經驗相對有限，且希望控制成本，我們期望藉助業務閘道器統一處理多項事務，如鑑權、流量錄製等。此外，由於我們在海外業務中需要頻繁遷移基礎設施，因此無法依賴雲上方案，並要求所有資料和元件具備遷移能力。

雖然 APISIX 完全開源且擁有豐富的外掛生態，但在公司內部使用時，仍需考慮和公司現有基礎設施的整合，例如對接公司內部的服務發現、日誌規範及 trace 上報等。這些功能是公司內特定的，無法直接合併到開源 upstream 中。因此我們基於 APISIX，添加了一系列專門為公司內部環境設計的外掛，開發了定製化版本 TAPISIX。

我們的服務執行在  Kubernetes(k8s）叢集上，以 APISIX 作為流量入口，與內部業務服務對接。服務發現採用公司內部的北極星系統，指標監控藉助 APISIX 社群版的 Prometheus 實現，日誌和 trace 採集都是透過 OpenTelemetry 進入 ClickHouse。在 CI 工具方面，我們採用 OCI（類似 GitHub Actions），支援透過 YAML 定義流水線；CD 工具則選用 Argo CD，基於開源方案實現持續部署。

由於我們的業務主要面向海外市場，對合規性要求極為嚴苛，這導致許多公司內部元件無法直接落地使用。

本次分享將涵蓋以下四個方面：

我們的目標是構建一個業務閘道器，依託於 APISIX 的外掛能力滿足定製化需求。作為業務團隊，我們面臨以下挑戰：

為解決上述問題，我們從以下四個方面入手：

開發規範易於理解，我們需定義一個庫，明確外掛的儲存路徑，並要求外掛採用單檔案形式，與 APISIX 的單檔案外掛機制保持一致，便於管理和維護。

為降低開發門檻，我們支援本地快速執行與測試。藉助 APISIX 的 Docker 映象，可將本地外掛透過卷對映至容器中，實現便捷部署。同時，利用下游的 echo-service（基於開源 Node.js 開發的服務），可模擬上游行為。該服務能夠返回請求的所有內容，如請求頭等。透過在請求中新增特定引數（如 HTTP 狀態碼 500），可模擬上游的異常行為，從而全面驗證外掛功能。

為降低開發門檻並加速驗證，我們提供了便捷的本地開發環境支援：

透過定義開發規範和提供本地快速開發支援，我們有效降低了開發門檻，加速了外掛的驗證過程。開發人員可以專注於功能實現，而無需擔心複雜的部署和測試流程，從而提高了整體開發效率。

在流水線建設過程中，需要保證可靠性和開發外掛的穩定性。開發流程如下：

a. 開發人員從 master 分支拉取一個新分支進行開發。

b. 完成開發後，提交 Pull Request（PR）至 master 分支。

a. Lint 檢查：主要檢查程式碼格式規範。

b. 單元測試：執行單元測試，驗證外掛的功能是否符合預期。

c. Try Build：使用原始碼構建映象，驗證程式碼的可構建性。

我們使用了 Grafana 旗下的 k6 測試框架進行核心用例的驗證。k6 框架支援宣告式編寫測試用例，可以覆蓋多種場景。我們定期回放這些用例，檢查介面是否透過。例如，即使只是修改了外掛，我們也會進行全面的回放測試，包括解析能力和服務發現能力等。

透過本地開發、快速驗證、MR 提交、流水線檢測、可靠性保障以及打包部署的完整流程，我們確保了外掛從開發到上線的每個環節都經過嚴格的質量控制。

接下來簡要介紹 APISIX 的部署模式，分為資料面和控制面。資料面負責實際的代理工作；控制面負責管理配置，包括管理端和其他功能，將配置寫入 etcd，資料面從 etcd 讀取配置並載入到記憶體中，完成路由功能。

APISIX 提供了三種部署方式，以適應不同的生產環境需求：

只保留資料面的獨立模式也是我們使用的方式，所有的配置都儲存在本地，避免了對 etcd 的依賴。這種模式更適用於海外場景。由於 etcd 屬於資料庫選型，部分雲廠商不提供 etcd 服務，且海外對資料合規性要求嚴格，並且我們的部署環境在 k8s，因此也採用了對 k8s 友好的配置管理方式。

我們定義閘道器為不可變基礎設施，日常運營中不會進行頻繁的變更。即使是路由變更，也被視為一次完整的變更操作。

問題描述：在管理 config.yaml 時，我們發現 k8s 的部署實際上依賴於一系列複雜的配置檔案，例如 Service.yaml、ConfigMap.yaml 和 Workload 等。這些配置檔案數量龐大且細節繁多，容易導致管理上的複雜性和錯誤。

解決方案：K8s 社群提出 Helm Chart 作為解決方案。Helm Chart 是一種將 k8s 配置檔案模板化的工具，能夠顯著簡化配置管理。APISIX 官方提供了 Helm Chart，助力我們高效管理核心配置（如節點數等），無需手動填寫大量 YAML 檔案。目前，Helm Chart 已有效解決配置複雜性問題。

衍生問題：然而，衍生出來的另一個關鍵問題是：如何將 Helm Chart 或 YAML 檔案部署到 k8s叢集上。

解決方案：為此，我們採用了 GitOps 模式，透過流水線將 YAML 檔案部署到 K8s 叢集。在 GitOps 模式下，所有配置以程式碼形式儲存在 Git 中。藉助 Git 觸發 CI/CD 流程，實現自動化部署。config.yaml 和其他配置檔案均儲存在 Git 中，確保了配置的版本化管理和可追溯性。透過這種方式，我們不僅簡化了配置管理，還實現了部署流程的自動化和標準化，提升了整體效率和可靠性。

在上圖展示的部署流程中，SRE（Site Reliability Engineer）代表使用者進行配置管理。任何修改，如路由變更或映象更新，都需要透過修改 Helm Chart 倉庫來實現。修改後，Argo CD 會自動檢測到變更並觸發流水線，拉取最新的配置完成部署。另外，Git 和 K8s 之間建立了強同步關係，確保配置的一致性和可靠性。

例如，部署完成後，我擁有 k8s 叢集的完全訪問許可權，對 service.yaml 檔案進行了修改。Argo CD 會持續監控叢集狀態，若發現實際資源與 Git 倉庫中的配置不匹配，將自動觸發同步，使用 Git 倉庫中的內容覆蓋叢集配置。

這種模式帶來諸多益處：

在實際部署中，我們僅需維護兩個倉庫：程式碼庫（存放應用程式碼）、部署庫（如下圖，存放所有部署相關的配置檔案）。

這種簡化模式使得許多傳統的管理平臺變得不再必要，整個流程更加高效簡潔。需要將應用部署到其他叢集時，只需從部署庫拉取相應分支，並應用到目標叢集即可，整個過程簡單高效。

在以上部署實踐中，APISIX 的關鍵配置檔案（如路由配置和 config.yaml 啟動配置）被整合到一個 Helm Chart 庫中，便於統一管理和部署。然而，這種部署方式也可能帶來一個問題：它本質上將 APISIX 當作了一個普通服務來部署。

APISIX Ingress Controller 作為社群為 k8s 提供的官方解決方案，其核心流程如下：透過定義 APISIXRoute 等自定義資源，以 YAML 檔案的形式在 k8s 中描述路由等配置。

將這些 CRD 部署到 k8s 集群后，Ingress Controller 會持續監聽相關的 CRD 資源。解析 CRD 中的配置資訊，並透過呼叫 APISIX 的 Admin API 將配置同步到 APISIX 中。Ingress Controller 主要為了進行 CRD 和 APISIX 之間的部署，最終還是將資料寫入 etcd。

經過審慎評估，我們發現 APISIX Ingress Controller 的部署和運維模式並不完全適配我們的團隊需求，主要有以下原因：

因此，我們沒有選擇 APISIX Ingress Controller。

在 k8s 環境中部署 APISIX 時，實現配置熱更新是確保系統穩定性和可用性的關鍵。APISIX 的配置主要分為兩種：

在 k8s 環境中，apisix.yaml 和 config.yaml 這些資原始檔均以 ConfigMap 的形式存在。

解決方案：為解決這一問題，k8s 社群提出了相應的解決方案，即透過合理地拆分配置，並巧妙地利用雜湊與註解方式，將需要變更的 ConfigMap 內容以註解的形式注入到 Deployment 中，從而實現配置的動態更新。

更新觸發機制：為實現配置變更的自動檢測與更新流程觸發，我們採用註解方式對 ConfigMap 內容進行雜湊處理，並將雜湊值寫入 deployment.yaml 檔案。當配置變更導致雜湊值更新時，deployment.yaml 檔案會相應發生變化，k8s 系統檢測到這一變化後，會自動觸發更新流程，從而確保 APISIX 部署例項能夠及時應用新的配置。

Runtime 運維主要分為三個部分：metrics 採集、trace 上報、日誌收集。

k8s 叢集提供了官方的 metrics 採集解決方案，名為 Kubernetes Prometheus Operator。透過定時抓取服務暴露的 metrics 埠和資訊，定期將資料上報至外部系統，如 Prometheus。由於該部分未進行深度定製，此處不再贅述。相關的 k8s 配置在 APISIX 的 Helm Chart 中已有完整描述。

Trace 上報基於 APISIX 提供的 OpenTelemetry 外掛實現。該外掛透過 OpenTelemetry 協議將資料上報至 OpenTelemetry Collector，最終將資料寫入 ClickHouse，完成 Trace 資料的採集與儲存。

日誌收集同樣採用 OpenTelemetry 協議。然而，APISIX 社群版的 OpenTelemetry 外掛僅支援 Trace 上報，而不包括日誌上報功能。因此，我們建議採用本地日誌儲存方式，透過 sidecar 模式將 APISIX 日誌寫入一個共享資料夾。在 Deployment 中掛載另一個 Pod，該 Pod 與 APISIX Pod 共享同一個日誌資料夾，從而實現日誌的採集，並透過 OpenTelemetry 協議進行上報。

另外，社群提供的監控面板功能較為通用，針對性不足。因此，我們基於採集到的指標資料定製開發了專用的監控面板，以滿足特定的監控需求。告警系統則基於 Grafana 的開源方案構建，利用其強大的視覺化和告警功能，實現對 APISIX 執行狀態的即時監控和告警。

我們首先對路由管理策略進行了最佳化。在早期的路由管理實踐中，我們將所有路由配置集中放置在一個單一的 config 檔案中。然而，這種做法很快暴露出問題，隨著業務的發展和路由數量的增加，YAML 檔案的規模急劇膨脹，給維護帶來了巨大挑戰。

正如業內調侃的那樣，“k8s 運維工程師是‘YAML 工程師’”之說，恰是因為面對海量的 YAML 配置檔案而產生的無奈與自嘲。為應對這一難題，我們從兩個關鍵維度出發，對路由進行了合理拆分。

在 k8s 的 upstream 配置中，存在多種型別，這些不同型別配置間的差異往往僅體現在 service name 這一關鍵要素上。在引入新版本並更新 Lua 包後，我們充分利用其支援的錨點功能，對重複配置問題進行了有效治理。透過錨點機制，實現了對共性配置部分的抽象與複用，在實際應用中成功減少了約 70% 的重複配置內容，極大地提升了配置管理的效率與簡潔性，降低了因重複配置而引入錯誤的風險。

最初，我們的鏈路架構為：Edge one 作為一個 CDN，然後流量經 CLB 轉發至 Ingress（Istio），最後到達內部的 APISIX。

Ingress 的存在主要源於歷史原因，當時在雲上選擇了 Istio 作為服務網格解決方案。然而，隨著業務的發展和技術的演進，我們計劃直接替換掉 Ingress，採用 APISIX 作為 K8s Ingress，以實現更高效、更靈活的流量管理。

在遷移過程中，我們評估了兩種主要的遷移方案：

● 方案一 CDN 灰度與雙域名：即在現有架構旁側部署一個新的 APISIX 例項，引導新的流量至該例項。然而，此方案的缺點在於前端需要修改域名，可能會對使用者訪問和業務連續性產生一定影響，因此我們謹慎考慮後暫時擱置了這一方案。

● 方案二 CDN 流量調配：選擇這種方式，它可以配置多個 CLB 路由，並且能夠實現基於百分比的流量推送。這種方式的優勢在於能夠在不改變使用者訪問入口的前提下，逐步將流量切換至新的 APISIX 例項，並且可以根據實際情況靈活調整流量比例，便於觀察和評估遷移效果。

我們最終選擇了方案二，成功形成了一條新的流量鏈路：新流量透過灰度方式直接到達 APISIX。這一新的鏈路架構帶來了以下顯著優勢：

以下展示的是遷移的整體流程。

我們團隊基於 APISIX 二次開發了 TAPISX 業務閘道器。APISIX 作為我們業務閘道器的核心元件，在滿足海外業務的高合規性要求、降低開發和運維門檻、提高系統靈活性和可靠性等方面發揮了關鍵作用。它為我們打造了一個高效、穩定、靈活的業務閘道器平臺，為業務的持續發展提供了有力支援。未來，我們期待與 APISIX 一起，探索更多創新的應用場景，為業務創造更大的價值。