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

語言: CN / TW / HK

講師:袁鵬,一頁科技架構師

摘要: 君潤人力採用多套 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 釋出!