第一屆“金融現代化 IT 基礎架構轉型論壇（FinTech Infrastructure Wave 2022）”已於 9 月 21 日至 23 日成功舉辦。該論壇由中國資訊通訊研究院雲端計算與大資料研究所、《中國金融電腦》雜誌社主辦，北京志凌海納科技有限公司（SmartX）與北京鯤鵬聯合創新中心協辦，分為三大專場，覆蓋銀行、保險、證券、基金、期貨、信託六大金融細分行業；帶來 15+ 實踐乾貨分享，涵蓋多雲平臺建設、核心業務系統信創轉型、超融合關鍵場景落地、核心業務 K8s 改造、資料中心零信任安全、“基礎設施即程式碼”等前沿話題。我們將以文字及圖片的形式，為大家回顧本次論壇期間的嘉賓精彩演講。今天為大家帶來 華能貴誠信託基礎架構負責人王昆的演講內容： 《核心業務系統 Kubernetes 落地實踐》。

本內容作者為華能貴誠信託基礎架構負責人王昆，由 FIW2022 組織方編輯整理發出，以下為部分演講內容。

今天我來給大家分享一下華能貴誠信託核心業務系統 Kubernetes 改造落地的實踐，我將從五個方面來介紹，分別是專案背景、核心業務系統、K8s 容器管理平臺、DevOps 流水線以及視覺化運維與監控。

一、專案背景

先從專案背景分析一下，我們公司為什麼要做 Kubernetes 的改造。華能信託新一代信託綜合業務系統是藉助移動互聯、大資料、人工智慧等金融科技技術，實現信託專案全生命週期的智慧化管理，藉助資訊科技增強客戶體驗，提升投前、投後管理水平，提升風險防控能力，提升工作效率，提升專業服務能力。

在業務層面，我們真正做到了釋放業務人員重複性的工作，提升工作效率。比如對於系統裡大量的錄入操作，我們做了一些系統複製，從已有的歷史專案當中複製過來，至少能提升 50% 左右的效率。

在資料標準化層面，因為系統開發較晚，是從 2018 年開始的，我們開發時按照監管要求進行表結構設計，所以我們的系統能夠直接對接監管報送，這部分資料不需要單獨處理。由此我們把各個監管機構要求的對應資訊都從系統層面、從專案落地及新建開始就已經融入到整個系統中，對於監管報送這一塊是無縫支援的。

在公司戰略層面，提供了準確、全面的業務資料，為高層領導提供決策分析、公司戰略發展提供資料支撐。

我們新一代業務系統採用了比較先進的基礎架構，整合了信託日常工作中常用的業務，包括對三方的產品和服務進行整合，實現了以客戶為中心，提供包含信託業務展業平臺、TA 資金平臺、銷售管理平臺、信託綜合業務管理，以及與三方系統的互動，包括我們的信託財務的核算模組、監管報送、老系統的資料遷移等。

由於系統裡面包含了公司最重要的一些業務，所以我們對系統的穩定性、安全性、可靠性和快速介入有較高的要求，要求業務 7×24 小時不間斷執行。要建立長期穩定可靠高速接入的環境，現有的基礎平臺無法滿足需求。

於是公司從 2019 年開始組織內部 K8s 的調研和學習，並組織透過 CKA 考試。2020 年 9 月，我們已經搭建了 K8s 的測試環境，並把部分業務遷到 K8s 的叢集上進行驗證。到 2021 年 3 月，我們已經完成了 K8s 開發環境的搭建和核心業務的整體遷移。2021 年 9 月，測試環境也全都遷移到 K8s 叢集中，截止今年 9 月已穩定執行一年，我們也陸續將核心系統生產業務遷移至 K8s 生產叢集，但並沒有最終投產，計劃 10 月以後投產。這裡說明一下，這並不是因為我們遇到了什麼問題，而是我們公司在做分散式儲存的採購工作，原本傳統的 NAS 儲存這個對於 K8s 的支援不是很友好。當前分散式儲存已經落地，計劃 10 月左右上線，上線後正式把 K8s 遷移過去，避免遷移完成後再做切換。

二、核心業務系統介紹

下面我來簡單介紹一下核心業務系統。核心業務系統主要是將公司的前後臺、中臺以及人員進行流程的打通，是一個全流程管理的平臺。從前端業務部門的提交到領導的審批、財務，再到最終的核算及監管報送，實現流程化管理。核心業務系統與其他部門系統及三方系統進行了整合，目前打通了與銀行的代銷、網際網路推薦、三方渠道、OA、入口網站、家族信託系統、資產證券化系統、自動生成憑證、恆生估值系統，以及企查查工商資訊。此外也對接了簡訊平臺、郵件平臺和電子簽章，實現了線上合同的電子籤，還包括與各個銀行的對接，實現線上劃款，以及對接增值稅開票系統，實現了發票的自動開票及電子票的推送。目前信託保障基金系統也已經整合到核心業務系統裡了，所以不涉及到對接。

當前的核心業務系統包括 5 個部分，第一個是業務流程處理平臺，包括信託專案的全生命週期管理、資金運用管理和季度結息等功能，可以完成資料錄入、系統自動結息，實現全面的自動化管理。第二個是 TA 銷售管理平臺，實現了資金端的生命週期管理和銀行代銷資料的管理。第三部分是財務會計平臺，我們對信託財務模組進行了重構，整合到了業務系統中，包括核算管理、核算場景設定和年終收益結轉等功能。第四個是一體化監管報送平臺，內建了銀監會、人行、中信登等 10 餘個報送模組，都在核心業務系統進行統一管理。第五個我們開發了三方互動平臺，包括外聯介面監控和監控報警功能，以上是我們核心業務系統的整體架構。

核心業務系統主要包括專案立項、審議、實施、中後期和專案清算，同時包含了代銷及委託端的管理，我們也開發了小程式，包括企業微信的審批流程。信託管理的子業務系統中包含了信財管理，即剛提到的財務模組，其中有風控決策子系統，以及其他的總部業務管理。核心業務系統與舊系統進行了打通，舊系統的資料透過 ETL 工具遷移到新系統。底層的技術支撐是流程引擎和規則引擎、基於 ClickHouse 開發的大資料平臺、基於方案報表開發的內部報表平臺、SpringBoot 和 Kettle 工具，然後搭建了內部的大資料平臺及報表展示平臺。同時我們跟報送的關聯，都透過我們基於 Kettle 和 SpringBoot 這類開源工具開發的監管報送平臺，這個是我們整個的技術架構。

下面介紹一下微服務架構，前端使用 Keepalived 實現叢集邊境室的管理，並能夠實現動態負載，然後從 Nginx 到前端的 Spring Cloud Zuul 的閘道器，閘道器對接的是後端各個資金專案、資產、結息、財務、TA、家族、ABS 等微應用。底層包括基礎服務、流程服務、引擎元件，以及對外提供的 OPEN API 的應用。平臺用到了 Redis、RabbitMQ Cluster、MinIO、MySQL 資料庫，同時這些微應用也透過 ELK 進行日誌收集，包括 Zipkin 的鏈路追蹤，實現了統一微服務治理工作。

三、K8s 容器管理平臺

下面給大家介紹一下容器管理平臺，我們搭建了三套 K8s 叢集，包括開發環境、測試環境和生產環境，目前搭建這些叢集沒有耗費太多資源，因為 K8s 上跑的是一些無狀態的應用。所以我們生產淘汰下來的機器，3 年、5 年之後淘汰機器會放到測試環境，當做 K8s 的節點來跑，即使壞了也沒有影響，我們能夠快速在另一臺機器上啟動，而且不需要人為管理。那麼我們測試的一些機器，比如說 5 年到 8 年，機器本身沒有問題，我們就把這個物理節點放到開發環境的 K8s 叢集上，極大提升了資源利用率。

這是我們核心業務系統基於 K8s 的架構。前端透過 AD 進行負載到達 Nginx Keepalived，雖然我們已經遷到 K8s 叢集，我們前端還是透過這樣的模式進來，後續我們可能會改造，全部採納 F5 的硬體負載，那麼後期可能透過 F5 進行負載到 K8s 的 API Server 上，然後進行內部整個鏈路的打通。

目前我們還是基於 Nginx Keepalived 的這種模式，然後流量引導到 K8s 裡面 Zuul 的閘道器，調到我們 Eureka 註冊中心，拉起後端微應用的介面，實現業務流程。我們透過應用叢集、微服務架構，然後透過 Spring Security Oauth2 的健全服務，包括統一的日誌收集，以及對接的第三方物件儲存，Redis、ES 這類檢索工具，包括我們用到的外掛 xxl-job 的分散式任務排程，整個的底層和業務系統適用的 MySQL 資料庫（目前是三個節點“主主從”模式，從庫是實現報表展示的工作），目前完整的流程基本上都是跑到 K8s 上，我後續會介紹完整的開發業務流程。

我們生產環境的一個叢集目前有 22 個節點、三個 Master 節點和 19 個物理節點。三個 Master 節點放到了 SmartX 的虛擬化平臺上面。因為我們認為 Master 節點是比較重要的，如果放在物理節點上損壞的話，雖然有三臺，但是我們還是希望能夠更高可用。其他的 19 個節點是用物理機構建的。我們測試環境的其中一套目前有 27 個微服務，預設所有都是兩副本，所以跑了 54 個容器，可以監控整個測試環境的資源利用情況。

四、DevOps 流水線

我們整個開發的 DevOps 流水線是這樣的：從 GitLab 上面拉程式碼執行單元測試、程式碼掃描，然後構建推送進入 Harbor 映象倉庫裡面，釋出到開發的 K8s 叢集，開發驗證透過後會提交到程式碼到跟 GitLab 上面，合併到測試分支後再提交到測試環境。下一步是測試人員測試，測試透過後把程式碼合併到生產分支，再進行釋出。

我們對 Java 版本進行了一些改造，能夠在開發人員無感知的情況下，自動改造釋出到 K8s 叢集上。只需在 GitLab 上改下引數，就可以從原來的釋出到虛擬機器上，自動釋出到 K8s 叢集上。

我們的 K8s 叢集既支援直接從原始碼構建，也支援從外部拉取已編譯好的二進位制映象進行釋出。我們還缺少單元測試，目前處於初級階段，後續我們會藉助自動化工具整合到這個流程中來，實現自動化測試的功能，提升程式的健壯性。

這是我們整個的開發平臺，從開發人員提交到 GitLab，然後 Jenkins 從 git 上拉取程式碼，編譯成 Docker 映象，提交到 Docker 倉庫，再透過 Jenkins 執行命令，在 K8s 叢集上拉取映象進行釋出。目前不同的業務系統是透過 Namespace 做應用的隔離。我們目前是三套叢集：開發、測試、生產，所有的業務系統都在這三套叢集裡，開發和測試人員基本上都可以透過系統直接訪問。

我們 Jenkins 的流水線目前包含了幾套環境。原來是直接釋出到虛擬機器上，現在進行了改造，開發人員不需要寫 Dockerfile 檔案，可以自動修改釋出到 K8s 叢集裡面。

我們的 SonarQube 程式碼掃描平臺，負責在所有的程式碼提交後進行掃描，問題處理好之後才會進行編譯，最終會提交進行打包映象，上傳到 Harbor 映象。比如我們內部的一個 Harbor 倉庫，一些微服務的映象就會提交到這個平臺上面。

五、視覺化運維與監控

下面給大家介紹一下整體的運維與監控。我們的開發人員透過 Jenkins 構建然後釋出 K8s，和傳統運維有一些區別，現在的方式相當於把整個流程都自動化，中間出了問題時很難定位，所以監控就比較重要。目前 Jenkins 自帶的，包括所有的編譯，每一步都有完整的日誌記錄，所以對於 Jenkins 這一塊沒有做相關的處理，直接使用 Jenkins 預設的內部記錄編譯成功失敗的日誌，非常便於查詢。

除了 Jenkins 編譯這一塊，K8s 也有對應的監控。我們採用 ELK 進行收集，同時用 Zipkin 對整個應用之間的鏈路進行追蹤，應用到底是在哪個環節出了問題，很容易能夠查詢到。

除了這些之外，我們還有 Zabbix 進行監控，以及 Grafana 進行報警。我們 Prometheus 是用了 KubeSphere 的這套叢集裡面最大的一個監控，也為大家介紹一下。

我們在 K8s 叢集上部署了一個 KubeSphere，是一個國產開源的 K8s 管理工具，功能非常豐富，但是我們並沒有完整地用到它，目前能用到的就是監控功能。因為它的監控頁面比較美觀，而且監控指標比較全面，所以我們並沒有單獨再給 K8s 做另外的監控工作，只借助了這個平臺。除此之外還用到線上人員許可權的管理功能，不同應用的運維人員不同，我們可以在 KubeSphere 裡面進行設定。

因為我們公司會 K8s 的也只有兩三個人，不可能要求所有人去學習，但這麼多系統也不可能讓三個人來運維。所以我們就構建了 KubeSphere，讓開發人員和運維人員也能分析和定位問題，目前用的還是比較好的。

以上是我們的整個 K8s 叢集的監控，可以對整個叢集的 CPU、記憶體、儲存和容器進行整體監控，包括 ETCD。整個叢集健康的狀態能夠透過這個介面看出來，資源、API 的排程情況都能在叢集監控裡面看到。

除了叢集狀態監控，我們還能對 Node 節點的狀態進行監控，可以在介面完整檢視所有節點的狀態，包括 CPU、記憶體、磁碟 Node 數、負載數量等，出現問題能夠及時告警。

此外我們還能夠實現對容器的監控，看到容器的執行狀況、資源利用，包括歷史情況。那這塊監控有什麼用處？我們剛才提到預設是兩副本，那麼假設記憶體佔用率達到 75% 以上，那麼它就會自動擴容一個節點，把兩副本增加到三副本。同樣，三副本如果資源利用率記憶體還是超過 70% ，會再去拿第四個副本，直到整體資源利用率降低到 70% 以下，這樣能夠實現資源的合理利用和排程。

KubeSphere 對整個叢集的監控確實很好，但存在一個問題，它本身是依賴於 K8s 的，如果 K8s 整體本身掛掉的話怎麼辦？所以我們在 K8s 的外面一層，相當於以第三方的視角，引入了 Zabbix 對節點以及 K8s 整個叢集狀態再進行了一層監控，如果 K8s 的整體叢集是沒有問題的，我們可以透過 K8s 裡面的監控來掌握叢集的狀態、Node 節點的狀態、容器的狀態。如果 K8s 叢集出了問題，我們也可以透過外部的 Zabbix 進行監控，能夠達到相當於災備的效果。