一、數據庫架構建設的基本方法和過程

二、某核心系統由大型機系統遷移到分布式架構

三、Redis異地容災架構建設

一、數據庫架構建設的基本方法和過程

1.數據庫架構組成

1）數據庫架構

在日常工作中，如果我們說到數據庫架構，一般來說指的是網絡、主機、存儲及之上運行的數據庫實例。數據庫架構工作指的則是如何去評估和組合這些組件，從而為業務提供符合運營要求的數據庫服務。

2）數據庫訪問組件

當數據庫架構演進到分布式架構，如何讓應用程序（服務）快速確認數據所在的位置，就成為了一個核心的問題，而這就是數據庫訪問組件的工作。

3）數據庫運營平臺

對于一個大型組織，運營幾千套、幾萬套數據庫實例是很平常的事情，而這也給運營團隊的日常管理帶來了一定難度的挑戰。各個公司組織紛紛搭建運營平臺，用于告警監控、故障處理、變更、版本發布等，在設計和構建數據庫架構的同時建設數據庫運營平臺已經成為了一種標準操作。

2.可運營及需求的組成

1）業務需求

數據庫架構首先要匹配組織的業務流程，滿足組織的業務需求，是所有從業者的共識。

2）運營需求

設計和構建數據庫架構的最終目標就是獲得一個能夠持續、穩定提供服務的數據庫集群，從設計之初就充分了解和滿足運營需求，是數據庫架構設計成功的一個關鍵要素。

3）監管需求

對于強監管行業而言，不滿足監管要求，項目就無法上線。因此，監管需求可以說事關監管行業的生死，必須在設計之初就充分考慮。

3.架構設計

1）業界生態

“不要重復造輪子”，在數據庫架構設計前，調研業界的技術生態非常重要。同時需要注意，我們所在組織的技術生態也是業界生態非常重要的一部分。

2）架構設計初稿

通過調研業界生態，我們能夠獲取數據庫架構所需的模塊，再結合項目的實際情況，對所需模塊進行組合和完善，就能夠獲取數據庫架構的初稿。

4.架構構建

1）數據庫選型和測試

數據庫選型放在架構設計之后的一個重要考量是保證數據庫架構設計的客觀性。如果在數據庫架構設計之前就選定了數據庫，架構設計將不可避免地受到數據庫功能特性的影響。

2）數據庫架構原型

在擁有數據庫架構設計和完成數據庫選型的前提下，我們才能在測試或者開發環境構建數據庫架構原型，這是我們下一步工作的基礎。

5.架構迭代

1）在完成數據庫原型建設之后，可以開始對數據庫原型進行測試和驗證，驗證指標應回到最初的需求、業務目標、運營目標和監管目標。

2）每輪的測試和驗證都會生成架構的優化項，結合項目的需求和目標，對數據庫架構不斷進行迭代，一般在3到5輪迭代之后就可以得到一個相對穩定可靠的數據庫架構。

二、某核心系統由大型機系統遷移到分布式架構

1.項目調研

遷移項目第一步是對當前系統的情況進行摸底調查。

1）容量和性能指標

系統指標分為很多方面，對于數據庫架構而言，首先需要考慮的是性能和容量指標。

2）業務特性

該項目具有一個明顯的特點——實時在線業務一次僅處理一個客戶，賬務結算和報表模塊一次需要處理很多客戶數據。

3）數據訪問和處理

通常意義上所說的計算和存儲分離指的是數據存儲在大型機文件中，業務邏輯完全在應用層實現。

4）項目人員能力

項目人員的能力主要集中于JAVA的開發，對于Oracle和MySQL較為熟悉，其他關系型數據庫的開發則相對陌生，項目人員的能力對于數據庫選型有明顯的影響。

2.數據庫架構原型設計

1）按照客戶對數據進行分片，數據路由在應用層處理，每個分片都由一個數據處理模塊和一組數據庫實例組成，不同分片之間完全獨立，跨分片的聚合計算在業務層處理。

2）站在數據庫本身的視角，不同分片之間的數據庫實例是完全獨立的，不存在任何的數據交互。站在業務的角度，所有的數據庫實例則組成了一個統一的數據庫集群。

3）該架構的優點是單分片處理邏輯簡單，對實時在線業務非常友好；缺點是跨分片處理邏輯復雜，報表和賬務結算業務難度高。

3.數據庫選型

1）Oracle和MySQL的對比測試

• Oracle在性能和故障自動恢復上具有一定的優勢，但分布式應用架構下數據庫實例眾多，Oracle的成本要遠高于MySQL。
• MySQL在技術生態上與應用分布式架構更匹配,但需要解決半同步不降級的問題。

2）經過架構師團隊的討論和權衡，最終決定使用MySQL衍生數據庫，性能與原生MySQL接近，同時半同步不降級，滿足RPO=0

4.運營平臺建設

1）配置管理：為每個數據庫實例添加分片屬性和業務屬性。

2）端到端交付：為了滿足數據庫實例可以動態地橫向擴容和縮容，增加了拉入節點、拉出節點和資源池的功能。

3）監控和故障處理：在原有的數據庫監控平臺的基礎上，增加了業務視角和分片視角，當數據庫實例故障時，能夠更加精準定位到受影響的客戶。

4）數據庫變更：為滿足24小時不停機的業務要求，增加了業務降級、流量管控、滾動處理和變更日歷功能。

5）版本發布：在分布式架構下，為應對成倍上升的復雜度和風險，增加灰度發布、并行發布、分片自適應和版本編排功能。

5.數據庫架構迭代

1）為滿足監管要求，需要在已有架構上添加容災架構。

• 在生產數據中心和容災數據中心建設相同的數據路由、數據處理模塊及對應的數據庫實例，對應的數據庫實例之間進行數據同步。
• 每個分片都可以獨立在不同的數據中心之間自由切換。
• 添加全局數據路由，能夠保證將事務處理路由到正確的數據中心處理。

2）使用業界已有的技術，通過binlog將數據實時同步到大數據平臺，進行報表分析。

3）使用業界已有的技術，通過binlog將數據實時同步到分片數據庫（整體引入），降低賬務結算程序的復雜度。

三、Redis異地容災架構建設

1.需求整理

1）所有的Redis僅作為緩存使用，無數據同步需求。

2）95%以上的Redis為Cluster架構，5%以內的Redis為哨兵架構，本次設計的架構聚焦于Cluster架構。

3）95%以上的Redis Cluster無容量和性能要求，準確來說就是所有的Redis Cluster都可以標準化，只要后續提供擴容/縮容的功能即可。

4）生產Redis Cluster變化較大，異地容災要求和生產同步上線和下線。

5）最小化DBA和應用開發團隊的人力成本。

2.架構實現

1）建設一個K8S集群，用來承載所有的Redis集群。

2）建設Redis集群同步平臺，從已有的CMDB讀取生產Redis集群的信息，并將創建的異地容災Redis集群信息更新到CMDB。

3）同步進程根據CMDB生成生產Redis集群集合和異地容災集合。生產集合減去異地容災集合，即需要搭建的異地容災集合，平臺將自動創建異地容災集群，并將信息更新到CMDB。異地容災集合減去生產集合，即需要下線的異地容災集合，平臺將自動下線異地容災集群，并將這些集群從CMDB中刪除。

4）每天執行上述步驟，即可保證移動容災集群和生產集群的同步。

5）K8S集群可以自動拉起宕掉的節點，結合Redis集群本身的高可用，即可保證異地容災集群的高可用。

6）K8S集群本身的告警監控即可滿足異地容災的告警和故障處理需求。

7）設計自助平臺，應用開發和運營團隊可以進行自助查詢、自助修改參數、自助擴容、自助申請域名等操作，最小化DBA和應用開發運營的人力成本。

王順

平安銀行 數據庫運維團隊上海分組負責人

專注于數據庫領域20+年的老兵，目前專注于數據庫運維和數據庫架構。