導讀
本文介紹了某商業銀行基於 TiDB 和 Kubernetes(簡稱 K8s) 構建的雲化分散式資料庫平臺，重點解決了傳統私有部署模式下的高成本、低資源利用率及運維複雜等問題。
透過引入 TiDB Operator 自動化管理與容器化技術，銀行能夠實現多個業務系統的高可用、彈性擴充套件與自動化運維，極大提高了運營效率與資源利用率。本文還詳細闡述了平臺架構設計、面臨的技術挑戰及創新解決方案，展示了 TiDB 在金融行業數字化轉型中的應用前景。
專案背景
某商業銀行新一代業務金融雲建設，以某國有大行新一代業務解決方案為建設藍本，目標是利用新架構滿足業務快速迭代的要求，提供較強的業務處理能力和靈活擴充套件能力，加快數字化轉型和業務創新等，同時滿足降本增效要求。 其中，選定 TiDB 分散式資料庫叢集的上雲應用系統合計超過 100 個，涉及核心、金融服務、渠道管理/整合、中間業務、個人貸款、對公貸款、元件服務、公共業務管理、資料分析等多個銀行重要業務領域 ，系統重要等級高，需要具備兩地三中心部署、同城雙活能力，且同城和異地 RPO、RTO 滿足系統對應的高可用和災備要求。按原私有部署模式（OP)，該專案常規需要物理機 300-600 臺，考慮客戶自身運營規模，系統建設迫切需要建立成本低、使用便捷的 TiDB 雲化平臺支援服務體系，全面減低 TiDB 部署、測試、運維等成本。
目前業內主流的 OP（私有）TiDB 部署方案，基於獨立物理伺服器，存在以下問題：
- 資料庫使用成本高 ：每一個業務應用都需要一套獨立的資料庫，部署時需要 3-6 臺物理伺服器；部署過程無法白屏化一鍵操作，仍需要人工複核和定位部署過程中出現的各類問題；
- 單獨為業務系統建設資料庫，不符合成本效益，同時形成多個資料孤島；同時帶來資源利用率低問題 ：每個業務對應的資料庫叢集利用率不同，無法合理利用同一套硬體資源，造成明顯的資源浪費；
- 業務上線、變更速度慢 ：通常採用物理機部署的形式來為某個業務應用提供資料服務。基礎架構團隊每次都需要部署物理機，如果考慮容災備份的需求，工作量極大，資源交付速度很慢，通常是以“天”為單位；上線後如果需要資料庫擴容、調整架構等，面臨相同問題
- 運維管理難度高 ：依賴管理員經驗、手工命令，無法滿足運工作標準化和自動化要求
分散式資料庫雲化架構目標
該銀行透過 TiDB Operator 自動化部署能力和 K8s 成熟的容器叢集排程管理能力和 TiDB 資料庫的高可用能力，構建 TiDB 雲化平臺。
整體目標是建立滿足某商業銀行自身業務發展的 IT 系統及架構，實現金融數字化轉型，具體系統建設目標為：
- TiDB +TiDB Operator 適配 K8s 聯邦叢集，提供金融級高可用雲平臺資料底座支撐能力；具備同城及兩地三中心高可用能力；
- 基於 TiDB Operator ，構建 TiDB 叢集運維管理功能，提供包括部署、擴縮容、備份恢復、引數變更、監控告警等雲 TiDB 產品的全生命週期管理；
- TiDB 雲平臺具備在各種物理資源上融合部署能力，大幅節約整體使用成本。
TiDB 是平凱星辰公司自主設計、研發的開源分散式關係型資料庫，是一款同時支援線上事務處理與線上分析處理 的融合型分散式資料庫產品，具備水平擴容或者縮容、金融級高可用、實時 HTAP、雲原生的分散式資料庫、相容 MySQL 協議和 MySQL 生態等重要特性，適合高可用、強一致要求較高、資料規模較大等各種應用場景。 TiDB Operator 是 K8s 上的 TiDB 叢集自動運維繫統，提供包括部署、升級、擴縮容、備份恢復、配置變更的 TiDB 全生命週期管理。藉助 TiDB Operator，TiDB 可以無縫執行在公有云或自託管的 K8s 叢集上。
整體架構
基於上述要求，TiDB 雲化建設整體架構如下：
整體設計特點如下：
- 系統底座構建在支援跨 Region(跨可用區同地區) 的 K8s 叢集服務上；
- 為更好滿足金融業要求，在 TiDB-Operator 基礎上，增強 Pod 獨立生命週期管理，提升線上擴容能力；新增 IP 固定等特性；
- DBASS 管控平臺面向雲使用者、運營人員、運維人員、開發人員，提供 TiDB 雲平臺視覺化管理、運維、監控、相關開發及測試任務；
- 提供整合、統一介面服務的 TiDB 資源池，可按需供給各類規格的 TiDB 邏輯叢集，依靠 K8s 自身服務排程編排能力和 TiDB 產品真正分散式事務能力、線上擴縮容能力，實現多業務隔離，提高資源利用率。
挑戰
最近幾年原生 K8s 技術演進發展迅速，新功能特性層出不窮愈加豐富，從技術可行性評估，容器技術早已具備支援有狀態應用的能力，但是 K8s 對資料庫等有狀態的應用的支援，因資料庫應用的特殊性，需進行一定的適配開發，以使資料庫容器化的整體架構方案和技術優勢和價值達到最優。
在此背景下，基於 K8s+Operator 構築資料庫容器化方案落地過程中，將會面臨以下幾方面技術難度：
1. K8s 災備能力： 從近期著名雲廠商多起史詩級故障來看，冗餘的 K8s 叢集可用性遠遠大於單一 K8s 叢集，需要有效使用多 K8s 叢集技術；
2. TiDB 高可用部署： TiDB 資料庫需要 保障 K8s 叢集下資料一致和高可用；
3. 多業務隔離能力： 需要滿足該銀行業務體量，支援小庫歸集、多業務隔離部署和資源隔離能力要求；
4.儲存： 容器針對無狀態應用的分散式儲存，並不適用於資料庫應用場景；需要 針對資料庫容器，提供一種既滿足資料冗餘，又能滿足 DB IO 效能要求的儲存方案；
5.運維便捷性： 原生 K8s 主要面向的是 CI/CD 應用場景，對資料庫的運維場景支撐並不完善。方案需要有效 降低運維成本，無縫對接行內現有資料庫運維生態體系及工具。
解決方案
1. K8s 災備能力
隨著 K8s 技術越來越成熟，企業以 K8s 為基礎構建基礎設施層的場景越來越多，雖然單個 K8s 叢集的容量不斷增加（例如：K8s v1.24 版本，單叢集最多可支援 5000 個節點和 15 萬個 Pod），但實際生產場景中，將所有業務都部署在一個叢集會導致單點故障，當單個叢集出現故障時，無法進行故障轉移，將造成業務故障。
透過引入聯邦叢集技術，構建多個不同地域、不同形態的容器叢集組成，不僅能夠解決上述單點故障題，還能夠實現多叢集統一管理和一致性觀測等。
方案示意如下：
如圖，K8s 叢集採用聯邦叢集技術，可在單個資料中心部署 3 套 K8s 叢集解決 K8s 單叢集單點故障；主叢集上是一個啟用了多叢集功能的 K8s 叢集，可以使用它提供的控制平面統一管理。成員叢集是沒有中央控制平面的普通 K8s 叢集。叢集管理員可透過主叢集訪問控制平面，管理所有成員叢集，例如檢視和編輯成員叢集上面的資源；單個成員叢集只能訪問和看到自身資源。
2. TiDB 高可用部署
根據業務重要程度，該商業銀行對應用專案有 A/B/C 三種分類，具體如下：
- A 類： 賬務處理、網銀、核心交易介面平臺、高等級聯機交易等系統；SLA 服務可用性不低於 99.95%；
- B 類： 對業務恢復時間要求不高的聯機交易系統等；重要等級較高的內部管理系統、內部分析系統等；SLA 服務可用性不低於 99.3%；
- C 類： 面向內部人員、內部客戶使用的內部系統；全年故障時間不超 24 小時，業務中斷時間不超 10 分鐘
其中，重要等級為 B/C 類的應用專案，可採用 單中心方案 ，如下圖所示：
部署說明：
- 該部署模式可提供單中心高可用能力；
- K8s 相容叢集包含 3 個物理叢集；均在生產 IDC；
- 應用透過負載均衡連線 TiDB 叢集；
- TiDB server 無狀態節點，部署在其中 2 個叢集對應節點上；
- PD 部署 3 節點，每個叢集一個，透過 RAFT 保證 PD 高可用；
- TiKV 透過 Raft 協議保持資料的一致性（至少預設三副本）,部署 3 節點，每個叢集一個；
- TiFlash 根據業務需求選用，至少兩副本保證高可用；
- 監控服務（Ngmonior）、TiDB 集中監控服務（TiDB-dashboard)、管理節點（MGT)均單 Pod 部署在一個叢集,依靠 K8s 自身機制實現高可用；
- 執行備份、恢復等任務，根據各叢集負載情況動態選擇一個負載較小的 cluster 生成 JOB 型 Pod 執行。
重要等級為 A 類的應用專案，可採 用同城雙中心+異地災備部署方案 ；部分高等級 B 類系統，可採用 同城雙中心（不需要提供異地災備） ，如下圖所示：
部署說明:
- 該部署模式可提供同城雙中心（無 TICDC）和異地災備高可用能力（部署 TICDC）；
- TiDB 叢集分為 AZ1/AZ2;應用系統也分 AZ 部署，透過不同的負載均衡連線不同 AZ 的 TiDB server；
- TiDB server：AZ1 上兩叢集各部署 1 個；AZ2 上 1 個叢集部署 2 個；
- PD/TIKV/監控服務/TiDB 集中監控服務/管理/備份&&恢復 Pod 部署同上；
- TIKV（預設 3 副本）在 3 個叢集上各部署 1 個；
- TiFlash 根據業務需求選用，至少兩副本保證高可用；AZ1/AZ2 預設各部署一個；
- 新增 TICDC Pod，負責生產->災備叢集資料同步，可選擇部署在目標端或源端。
高可用方案能力總結如下：
3. 多業務隔離能力
在 TiDB 雲化平臺上，首先需要保障 K8s 原生的名稱空間（NameSpace）和資源配額 (ResourceQuota) 能力 ，保證不同業務的 TiDB 服務 Pod 能有效資源隔離，不會相互干擾；其次，需要保障 基於 K8s 原生 Pod 排程能力， 節點選擇(NodeSelector)、汙點容忍度（Tolerations）、親和/反親和（Affinity/AntiAffinity），可按需在不同 K8s 節點上排程各類 Pod，完美解決 TiDB 各類計算、儲存服務的混合部署時互相干擾的難題。
如上圖所示，在雲化 TiDB 平臺上，運維人員只需要為上線業務選擇合適的 Pod 規格和 Pod 個數後，可以一鍵部署叢集，而無需關心 K8s 具體的資源分配、Pod 編排排程細節。
4. 儲存
資料庫應用為重 IO 應用，磁碟負載很重，因此，如何保障資料庫容器的磁碟 IO 和吞吐量，成為了容器資料庫方案設計的重中之重；系統設計時有 2 種方案供選擇：
- 使用開源雲原生儲存（GlusterFS/CephFS)： 該方案過度依賴網路，和資料庫服務搶佔網路資源。
- 使用本地儲存 LocalPV： 資料冗餘保護能力不足，運維較為複雜，但效能高，可滿足資料庫場景需求。
考慮到 TiDB 產品的儲存服務 TiKV 會自動維護多副本（預設為三副本），架構如下：
如上圖，TIKV 主要特點如下：
- Multi-Raft 架構 - 以 Region 為粒度複製副本；
- 奇數份資料副本打散分佈在儲存節點叢集；
- 相同的資料不會在同一個節點上。
因 TIKV 天然支援高可用和自動故障轉移，解決了本地儲存方案中資料無法冗餘的缺點，同時繼承該方案能為資料庫容器提供足夠的磁碟 IO 和吞吐優點，兼顧資料高可用性和儲存成本最佳化，因此經大量驗證測試後，選擇使用本地儲存方案（localPV）來實現 TiDB 雲化持久化。
5. 運維便捷
TiDB 雲化平臺基礎架構，圍繞 TiDB 服務適配設計定製開發，運維優勢體現在：
- 分鐘級部署 TiDB，支援單中心、同城雙中心、兩地三中心等多種模式；保證應用程式在開發、測試和生產環境中執行一致；
- 運維全視覺化操作，簡單直觀，有效減少人為運維失誤；
- 無縫對接行內現有容器化 TiDB 叢集、TiDB 遠端容災、TiDB 映象管理平臺、TiDB 資料庫管理等平臺。
系統收益
基於 K8s+TiDB+TiDB-Operator 構築的雲化 TiDB 平臺於 24 年 5 月一次性上線了 100+ 業務應用系統，執行平穩。該專案主要收益如下：
- 驗證了分散式資料庫 +容器雲的創新方案，一套 TiDB 叢集支援多個業務，簡化技術棧；
- 充分利用 K8s 和 TiDB 架構特點，實現了金融業務在容器平臺的高可用；
- 解決運維自動化能力建設的瓶頸、規模化運維效率低下問題，實現自動化運維，為將來智慧化運維奠定堅實基礎；
- 較 OP 部署模式，資料庫部署硬體資源節約 80% 以上；解決了傳統部署模式下總體擁有成本高、資源利用率不高、部署密度低等問題；
- 解決了傳統虛擬化部署產生的基礎環境不穩定、不支援資源彈性伸縮以及 Pod 是否高效穩定執行有狀態類應用等問題。