APISIX 在君潤人力雲原生平台的架構實踐

講師：袁鵬，一頁科技架構師

摘要： 君潤人力採用多套 Apache APISIX 集羣來滿足自研服務平台的功能需求。

君潤人力成立於 2019 年，是一家以科技驅動的人力資源解決方案服務商，依託行業領先的科技水平和服務能力，專注於為客户提供一站式人力資源服務。自研數十家人力資源服務平台，深度鏈接 B 端企業和 C 端用户，構建數字化人力資源服務生態。

本文從君潤人力業務快速擴張的背景入手，重點介紹開源 API 網關 Apache APISIX 對其自研平台系統架構的多樣化應用場景支持，共有四大線上實戰案例，希望對仍在網關選型過程中的企業或用户有所幫助。

君潤人力自研系統架構概述

君潤人力在搭建自研服務平台架構時，首要原則就是**“開放、開源、擁抱雲原生”**。平台基於 Kubernetes 微服務架構構建雲端系統，整體架構參考下圖。

右側是君潤自研服務平台，DevOps 流程依託 Git webhook、coding、Kubernetes 集羣實現全自動化與無感發布，業務系統基於 PaaS 平台進行迭代開發，確保研發規範，並達成技術棧的統一。上側是監控手段，系統集成了 sky-agent 和 arthas，滿足了線上服務觀測多維度的需求。與此同時，採用騰訊日誌雲與 Kubernetes 結合的方式將服務日誌存儲在雲上，實現 Kubernetes 集羣內無文件化服務，避免磁盤容量堆積從而影響到 Kubernetes 集羣單個節點的健康。

左側是業務系統中最重要的環節 —— 流量管理。所有流量會通過 WAF（WAF，Web 應用防火牆，負責網絡安全）進入三層網絡裏面的第一層 CLB，主要負責流量轉發；第二層就是雲原生網關 APISIX，它承擔了業務系統的內部服務治理；第三層則是業務系統的 Gateway 應用內部的網關，負責單系統鑑權和路由。

其中第一層的 CLB 和第二層的 APISIX 尤其重要，它是所有系統的入口，一旦出現問題，那麼所有系統將無法被訪問。CLB 採用的是騰訊雲服務，穩定性、擴展性與抗併發性能都比較高，業務架構需要解決的是第二層雲原生網關 APISIX，保證它的高可用。

APISIX-Service 被部署在 Kubernetes 集羣內部，Kubernetes 集羣採用的是騰訊雲提供的服務，為了保證出現問題後能夠快速恢復，系統外置了 etcd 集羣，使數據得以保留，這是 APISIX 集羣高可用的體現。

那麼，如何來保證 APISIX 的高併發和高性能？這裏系統利用了 Kubernetes 的機制，當 APISIX 進行路由轉發時，通過 Kubernetes 的服務名 + 服務端口使它在同一個網段內跳轉；因為網關服務部署在 Kubernetes 內部，依託於 Kubernetes 的特性，可以進行滾動升級，進而達到 APISIX 網關升級的無感發布。

通過該架構圖不難發現，第二層是所有流量的入口，選擇一個滿足業務擴張需求的雲原生網關，對系統架構來説至關重要，下面談談在網關技術選型時的主要思考。

技術網關選型痛點

• 數量龐大的業務系統。 目前人力資源這個領域有 15+ 服務平台，生態業務多樣化，面臨的問題也比較多，服務請求需要頻繁變更，導致需要操作和配置的路由也非常多。原來系統是基於 CLB 進行流量轉發，久而久之，運維人員需要配置和操作的地方非常多，耗費了大量的人力與時間。
• 頻繁的高併發大流量。 舉個例子，客户集中在同一天發薪或提現大額資金。在用户數量達到大幾十萬時，集中進行的某些行為，如打卡、簽約、領取任務或工資等，此時系統併發流量非常大，短期翻倍的情況比比皆是。
• 個性化需求的擴張壓力。 APISIX 是基於 OpenResty、Nginx 和 Lua 開發的，但如果用 Lua 來開發插件，會有一定的研發投入和維護成本。 對於插件的支持，APISIX 已經提前做好了準備。APISIX 的官網提供了自定義插件 ext-plugin 來支持 Java 開發，技術棧問題迎刃而解。此外 APISIX 的生態非常好，作為國產網關產品，社區極其活躍，業內實踐還特別多，在雲原生網關這層來説，業內也是頂級存在。

我們的團隊非常開放，做完技術選型後，快速實踐落地。從上線部署到服務分批次接入，耗時不到 1 個月時間。目前 99% 的服務通過 APISIX 訪問，上線一年多至今零事故，穩定性非常好。下面這張圖裏，大家能看到 APISIX 的一些特性，紅字部分是我們最看重的幾點。

APISIX 四大實踐場景

下面我們來逐一介紹 APISIX 的四個實踐場景。

路由策略

Apache APISIX 基於 Radixtree 和 etcd 提供路由極速匹配與配置快速同步的能力。路由和插件的設計實現都滿足了極速性能和超低延遲的需求。比如以下兩個場景中，都表現出了不錯的性能：

• 高峯期的 API 緊急停用。 業務系統處在高峯期時，用户導出百萬數量級的報表數據，會使 MySQL 數據庫直接宕機，此時重啟服務也無法解決，用户繼續導出操作會持續故障，這個問題以前我們得發版才能解決；而現在只需要運維人員簡單配置一番，就可以做到 API 緊急停用，通過路由優先級策略和失效策略（依託 Serverless 插件），配合使 API 接口在分鐘級下線，從而保證服務的穩定。
• 業務系統較多。 其中 SaaS 系統需要支持客户自定義域名訪問，我們採用了泛域名匹配，做到一次配置，全局通用。 下圖是君潤人力 2022 年度路由增長趨勢圖。可以看到，不論前端還是後端路由，在引入 APISIX 之後，都實現了三倍或以上的數量增長。

安全控制

我們基於 APISIX 做了雙層網關架構，在 APISIX 上隔離出一個邏輯網關，用户訪問 CLB 進來 APISIX 再轉發到業務系統。如果用户使用的這個功能需要用到 PaaS，就會通過 PaaS 服務網關進行訪問，此時的 PaaS 服務網關就是一個邏輯網關。

我們在 Kubernetes 內部封閉了一個區域，即 PaaS 平台，裏面包含大量的基礎服務。利用 APISIX 網關的特性：熔斷、安全、身份識別，使上層業務系統訪問 PaaS 服務都需要通過 PaaS 網關。

流量管理

由於業務系統數量較多， 核心服務（SSO、PaaS 服務和發薪服務）可用性要求高， 這些服務的流量管控需要依賴 APISIX 提供的流量管理灰度策略。

為此，系統內部採用了兩種方式進行。一是基於標籤灰度。核心服務上到生產環境之前，測試人員先在灰度環境驗證。我們會將測試用户流量轉發到灰度服務，進行生產環境驗證，驗證通過後再基於權重切入流量，觀察一段時間，沒問題後再把全部流量切換到新版本；二是生產環境內。相同的服務並存多個版本，不同的業務系統訪問不同的版本時，基於標籤進行路由轉發。

日誌管理

從下圖的架構模式可以看出，APISIX 和 Pod 服務都基於 Kubernetes 架構，所有後端路由都被綁定在同一服務上，在 APISIX 服務上配置的 Kafka 插件用來採集日誌數據，同時配置了 Skywalking 監控程序性能。根據 RequestId 和 TraceId 在 Skywalking 和日誌雲，可以觀測到整個調用鏈路，並查看每個環節的日誌記錄和 API 請求耗時。

從目前觀測到的數據來看，系統每天都有上千萬次的 API 請求，平均每天產生的日誌數據達到 30G ，日誌總量達到 TB 級。

使用 APISIX 的經驗與展望

在使用 APISIX 的過程中，我們總結了一些經驗之談，在這裏分享給對 APISIX 感興趣的朋友們。

構建基礎鏡像需要拉取國外資源。 APISIX 需要部署在 Kubernetes 內部，內部會進行一定的二次開發和源碼編譯，這時需要到 GitHub 上拉取資源，目前官方提供的 Docker 鏡像有一部分需要拉取國外資源，在進行本地開發和線上部署時，環境調試相對麻煩。

調試環境部署有要求。 自定義插件 java-plugin-runner ，需要基於 runner.sock 進行 RPC 通訊，現有案例較少，調試起來有一定困難，它需要和 APISIX-Service 在同一個鏡像內。

每天產生大量的日誌記錄到本地。 剛剛發佈生產時，我們發現就算只開啟 error 級別日誌，每天的增長數量都非常大，導致 Kubernetes 集羣中一個節點磁盤告警。後面打包鏡像時將日誌由文件記錄改變為輸出至控制枱，收集至雲日誌服務 CLS 存儲記錄分析，實現本地無文件化存儲。

當然，以上都屬於前期準備工作上的必經之路，在正式投入使用後，APISIX 給我們帶來的收益遠遠大於期望，總體有以下三點：

1. 對業務發展起到了強有力的支撐。 使用 APISIX 後，系統功能更加豐富，性能更加強勁。APISIX 對 API 服務提供了多種可觀測性和安全防護手段，可以支持我們每天千萬次流量的訪問。
2. 助力研發交付效率。 比如原來配置 DNS 解析需要 10 分鐘才能生效，而現在通過泛域名配置，幾秒鐘就能生效；因為原先需要在 CLB 和 Nginx 兩個地方手動修改配置，而我們有 10 多個系統、100 多個服務，需要配置的點很多，應用了 APISIX 的泛域名配置後，現在只需要在控制面板上修改，極大地減少 DevOps 工作量。
3. 大幅降低成本。 LB （負載均衡）成本的變化。LB 服務數量由 200+ 縮減到了 10+，大大降低了系統維護成本。 後期我們還會有一系列需要藉助 APISIX 雲原生網關達成的功能開發包括但不限於：集成 Sentinel 使服務具備熱插拔動態限流功能、開發多維度流量控制、風控識別功能升級、分層治理和全鏈路日誌分析等等。屆時將採用多套 APISIX 集羣來滿足自研服務平台的功能需求。

總結下來，使用 APISIX 雲原生網關給君潤人力服務平台帶來了非常大的幫助，使我們能輕鬆應對多樣化的複雜場景，打造趨於完美的數字化人力資源服務生態。

本文由博客一文多發平台 OpenWrite 發佈！