本文由阿里技術專家吉遠撰寫於2022年2月。
# 專案背景
長久以來，IOE技術架構成為銀行業核心的標準配置和唯一選擇，它們組成的系統一度被視為大型金融企業後臺的“黃金架構”，某銀行客戶A類一級核心業務系統採用的就是成熟的“商業系統+集中式架構”的構建方式：IBM大型機、Db2資料庫、EMC儲存。

然而，今天在雲端計算/雲原生等新興技術普及趨勢下，傳統集中式架構正在面臨前所未有的挑戰，業務痛點具體如下：

- **業務迭代慢：** 商業軟體架構和技術封閉，生態不足，迭代緩慢，應對金融創新乏力，因此很難服務於瞬息萬變的國內市場環境及千變萬化的使用者需求。
- **效能低擴充套件性差：** 集中式架構擴充套件性和彈效能力差，無法支撐在類似“雙11”等高併發場景下對系統負載產生的巨大壓力，交易緩慢。
- **穩定性風險高：** 線上金融業務有 7*24 小時服務不間斷要求，傳統架構在執行監測、問題定位上響應緩慢。同時，針對應用、資源或機房級故障，不能快速恢復業務。
- **維護成本高：** 基於 IBM 的大型主機和 Db2 資料庫的集中式系統的總成本（購置/擴容+維護服務）遠超基於X86的分散式系統，成本壓力愈發明顯。
- **無法自主可控：** 金融行業作為自主可控的行業之一，IOE廠商對國有銀行形成事實上的壟斷，在核心繫統領域受制於人容易“卡脖子”，不符合當前國家推進自主可控的頂層設計。

因此，原有系統已經到了支撐能力的天花板，新系統的構建迫在眉睫。

# 單元化分散式架構設計
作為國有大行核心去IOE並且是上阿里雲的首個大機下移試點專案，在沒有可借鑑物件的大背景下，如何將核心系統從傳統大機架構平滑切換到分散式架構本身就是一個巨大挑戰，尤其是在已經擁有億級使用者基數的情況下，如何既能充分發揮分散式架構的高可擴充套件性，又能滿足金融業務嚴苛的安全、穩定、可靠要求，是新核心系統建設首要面臨的問題。

經過和客戶對焦，最終明確新一代分散式架構 6 大設計目標，在金融業務場景下滿足高可用、高標準、低風險的要求。同時，在網際網路場景下需滿足高效能、高彈性、低成本的訴求。具體如下圖：

![](https://img.alicdn.com/imgextra/i2/O1CN01nH9VOG1yjGMLYHomy_!!6000000006614-2-tps-832-536.png)
圖1 分散式架構設計目標

客戶核心系統分散式設計，整體部署採用“同城雙活+異地災備”的兩地三中心架構，實現同城 RPO=0，RTO 分鐘級，異地 RPO 分鐘級的容災目標。其中底層資料庫採用 OceanBase 資料庫設計的單元化架構，具體如下圖：

![](https://img.alicdn.com/imgextra/i1/O1CN011Jh0Do1JBSso33fQG_!!6000000000990-2-tps-832-472.png)
圖2 同城三機房單元化架構

單元（即單元化應用服務產品層的部署單元），是指一個能完成所有業務操作的自包含集合，在這個集合中包含了所有業務所需的所有服務，以及分配給這個單元的資料。單元化架構就是將單元作為部署的基本單位，在全站所有機房中部署多個單元，每個機房內單元數目不固定，任一單元均部署系統所需的全部應用，資料則是全量資料按照某種維度劃分後的一部分。

單元化的本質，就是把資料流量，按照一定緯度進行拆分。使得一個單元能夠閉環提供完整的服務能力。但這個服務能力面向的是拆分後的部分資料流量，且只服務於這部分流量。

**單元化解決的問題**

- 容量問題：IDC資源緊張，集中式單機資料庫連線瓶頸。
- 多機房容災：控制故障爆炸半徑
- 使用者體驗：就近訪問，提升使用者請求訪問速度

**單元化設計原則**

- 核心業務必須是可分片的（交易、支付、賬務）
- 必須保證核心業務的分片是均衡的，比如客戶號、會員號作分片維度
- 核心業務要儘量自包含，單元內全部收斂掉，呼叫要儘量封閉
- 整個系統都要面向邏輯分割槽設計，而不是物理部署

## 應用單元化設計
應用App部署在第一機房和第二機房，2個機房，互為主備。
1個Gzone單元，雙機房應用無狀態對等部署，資料僅有一份，需要跨機房訪問。
10個Rzone單元，雙機房單元互備共20個Rzone，應用/資料訪問自閉環，應用故障爆炸半徑控制在10%以內。

- **GZone（Global Zone）：** 部署了不可拆分的資料和服務，這些資料或服務可能會被 RZone 依賴。GZone 在全域性只有一組，資料僅有一份。 設計：閘道器、配置、引數、路由等全域性服務。
- **RZone（Region Zone）：** 最標準單元定義的 zone，每個 RZone 都是自包含的，擁有自己的資料，能完成所有業務。設計：交易、支付、賬務等核心可分片的業務。

## 資料庫單元化設計

- 客戶核心系統按照「使用者編號」維度對資料分片。將全量資料按照1%的粒度劃分成100個資料分片，即按照「使用者編號」ID 末 2 位作為標識（00-99）。
- 按「使用者編號」為主體劃分 5 個單元化叢集，每個叢集 20 個租戶，總共百租戶/百庫/百表 ,每個租戶對應一套分片庫/表；1 個全域性化叢集，存放非單元化公共資訊。劃分5個單元化叢集最大好處就是當資料庫出現極端故障時，損失了一個單元化叢集的能力，隻影響 20% 的使用者，整體影響面可控。
- 每個叢集 5 個zone（即5個副本） , 主副本根據單元化訪問需求分配到主機房和備機房的 4 個zone上，第三機房不承擔業務流量，機房之間網路延時在 2ms 以內。
- 由於分散式多副本資料一致性協議要將每一個事務的資料強同步到多數派副本中，這種部署模式下必然導致頻繁的跨機房同步操作。為了保證資料庫的寫效能，對機房之間的網路質量有比較高的要求，通常要求任何兩個機房之間的網路時延不超過2毫秒（ms）。
- 資料庫內部沒有跨zone/跨節點的分散式事務，所有分散式事務需求在應用單元內部解決，透過“本地訊息表”，補償機制達到最終一致性；

你可能會疑惑，OceanBase叢集標準部署是同城三機房三副本，而這個專案為什麼要使用同城三機房五副本呢？原因是這樣的：雖然業務上規劃了第一機房和第二機房兩個機房，但是客戶要求以穩為主，核心系統對時延要求很高。同城機房基本也不允許跨機房訪問。因此，為了避免OceanBase叢集第一機房當機，而導致leader切主到第二機房，我們在第一和第二兩個機房各部署了2個副本。另外，三機房五副本等部署方式，可以在同一時間容忍2臺observer 機器出現異常，為業務提供了更高的安全性和可靠性。

![](https://img.alicdn.com/imgextra/i2/O1CN01MRP8uB23m4ruiTeKe_!!6000000007297-2-tps-832-838.png)
圖3 OceanBase資料庫單元化架構

##  單元化資料統一訪問
客戶核心系統透過 SOFA ODP 分庫分表中介軟體/OBProxy 代理提供的統一入口來訪問 OceanBase 資料庫單元化叢集，它遮蔽了分庫分表、多叢集及OBServer分散式的複雜性，將 SQL 語句路由到該應用單元對應的 Leader 副本上， 對使用者使用完全透明；不過需要特別注意的點是，透過「使用者編號」分片後，所有 SQL 必須透過帶“分片鍵”進行資料操作，否則全表掃描 SLB 和 ODP 會被打爆。每個單元會拆分一個SLB（負載均衡服務）例項掛載ODP，ODP後對應後面的所有的OBserver。

![](https://img.alicdn.com/imgextra/i3/O1CN01w74DUN1PaYH4P1jSh_!!6000000001857-2-tps-832-434.png)
圖4 ODP單元化架構設計

這邊重點講下部署架構，客戶核心系統對效能有非常高的要求，在上雲過程中經歷了幾次演進。一次從 ODP 和 OBProxy 分開部署演進到 2 個程式合併一起部署到容器，主要解決網路多一跳耗時和快速彈性擴容問題，並且後續會往 OBSharding 單個C程式演進，解決效能問題。另一次，從一個 SLB 例項掛載後端所有 ODP 例項拆分成每個單元對應一個 ODP SLB ，解決的問題是：1） 在大流量情況下，單個 SLB 流量容易被打滿；2）由於應用長連線原因，會導致負載不均，這樣對某個 ODP 造成非常大壓力，甚至出現 JAVA FullGC；3）某個 ODP SLB出現故障時，不會影響其它單元，符合單元化設計思想。

# 分散式資料庫OceanBase部署與容災
## 同城單機房到三機房改造
按照整體設計，我們在主城市規劃了三個機房，但是每個機房採購及部署到位時間是不一致的。為了不影響應用上線計劃，在第一機房主機房機器ready後，我們就開始部署OceanBase叢集。首先部署好第一機房單機房三副本叢集，提供給客戶進行測試驗證，同時等待第二和第三機房機器到位，待機器ready後，我們透過OceanBase特有的增減副本以及副本型別線上轉換的功能，實現資料的平滑搬遷，最終實現同城單機房三副本到同城三機房五副本的架構轉化，整個過程對應用透明，應用無感知，充分體現了OceanBase 強大的彈性伸縮能力。

![](https://img.alicdn.com/imgextra/i1/O1CN017Qx6WV1x2NezZIxW6_!!6000000006385-2-tps-832-648.png)
圖5 OceanBase三機房調整-1

![](https://img.alicdn.com/imgextra/i3/O1CN01O1knhW1KVRmTOxI5e_!!6000000001169-2-tps-832-676.png)
圖6 OceanBase三機房調整-2

![](https://img.alicdn.com/imgextra/i1/O1CN01Rk4QJK1YcEGSBRDcK_!!6000000003079-2-tps-832-646.png)
圖7 OceanBase三機房調整-3

**OceanBase主備叢集方案**
傳統IT系統高可用的實現主要是以主備的方式。這種方案目前有非常廣泛的應用，由於經歷了時間的驗證，行業的認可度比較高。主備雙機也可以作為容災的一種選擇。目前執行的很多系統，其容災方案是以主備的方式構建的。雖然OceanBase透過其多副本特性完美解決了容災的方案，對於重要度極高的系統，仍需要規避整個叢集出現不可預知的故障時，導致服務不可用的情況。因此，OceanBase也提供了與傳統構架類似的複製功能，利用REDO日誌，使主叢集和備叢集實現資料同步。在極端情況下，如當主叢集出現計劃內或計劃外（多數派副本故障）的不可用情況時，備叢集可以接管服務。備庫提供最大可用、最大效能、最大保護三種保護模式，可以根據實際情況選擇，最大限度降低服務停機時間。

**Oceanbase 主備叢集三種保護模式**

- **最大性（Maximum Performance）。** 這是預設的保護模式。它在最大限度地確保主叢集效能的同時，還能保護使用者的資料。在這種保護模式下事務只需等REDO日誌在主叢集持久化成功就可以立即提交。REDO日誌會非同步的同步到備叢集，但是不會阻塞主叢集事務提交。因此，主叢集群的效能不會受備叢集的同步延時影響。
- **最大保護（Maximum Protection）。** 這種保護模式提供了最高階別的資料保護，可以確保主叢集出現故障時不會發生資料丟失。在這種保護模式下，事務需要等REDO日誌在主叢集和強同步的備叢集上都持久化成功才能提交。最大保護模式下只支援配置一個強同步的備群，其它備叢集只能處於非同步同步模式。如果強同步的備叢集不可用，主叢集會停止寫服務。
- **最大可用（Maximum Availability）。** 這種保護模式在不犧牲叢集可用性的前提下提供了最高階別的資料保護。預設情況下，事務要等REDO日誌在主叢集和強同步的備叢集上都持久化成功才能提交。當感知到強同步的備叢集出現故障時，主叢集不再等日誌強同步成功，和最大效能一樣優先恢復主叢集服務，保證叢集可用性。直到強同步的備叢集恢復服務，主叢集會自動恢復為強同步模式，提供最高階別的資料保護。最大可用模式下只支援配置一個強同步的備叢集，和其他備群只能處於非同步同步模式。

## OceanBase異地部署方案
金融行業對業務連續性及對IT風險的應急要求非常高，容災體系建設至關重要。對A類核心系統，既要能夠滿足同城雙活，又要具備異地災備的能力。為了滿足客戶異地容災需求，我們在異地災備機房搭建了一套異地備叢集，採用OceanBase 主備叢集架構，並藉助首次釋出的OCP管控主備叢集版本進行快速跨城部署，實現了異地容災切換時間跨越式提升（從小時級提升至分鐘級），切換方式由原來的黑屏切換轉換成白屏切換，極大地提高了應急切換的響應時間、安全性和便捷性。

![](https://img.alicdn.com/imgextra/i2/O1CN01uiNpAl1bFHGROJ9Nj_!!6000000003435-2-tps-832-480.png)
圖8 OceanBase 異地容災部署

##  容災測試演練
因為客戶是第一次在核心繫統上使用OceanBase分散式資料庫，對穩定性和安全性提出了非常嚴格的要求，要求我們對全場景進行容災演練，透過業務容災演練滿足核心A類業務投產要求。為此我們不僅在架構上設計了主城市同城三機房五副本的高可用架構，我們也和應用一起編寫了詳細的測試案例，來檢測我們的高可用方案。透過驗證我們在主城市2個副本同時當機的情況下，完全可以做到RPO=0，RTO<30s，贏得客戶信任，提升了客戶面對災難時能切敢切的信心。

![image.png](https://intranetproxy.alipay.com/skylark/lark/0/2022/png/8779/1662363889390-2b7e3968-cf23-4679-b2b0-742fc56e4f84.png#clientId=u5a56c37f-73fb-4&crop=0&crop=0&crop=1&crop=1&from=paste&height=585&id=uea9900a5&margin=%5Bobject%20Object%5D&name=image.png&originHeight=1170&originWidth=2132&originalType=binary&ratio=1&rotation=0&showTitle=false&size=1062979&status=done&style=none&taskId=ud2d268ad-681e-4a19-8339-b04fada3749&title=&width=1066)
圖9 OceanBase容災測試案例

# 核心系統割接整體遷移方案

客戶核心系統整體上採用停寫遷移的方式進行資料移植，整個遷移過程中，資料從大機匯出，要先匯入臨時庫表，透過聯表查詢匯入目標庫，涉及多次資料匯入匯出。經過前期精心的設計準備，以及多輪生產環境移植演練，遷移時間控制在小時級別。同時為了穩定期間，客戶分三個階段進行白名單切流遷移驗證，每個階段，都會進行資料對賬和業務邏輯驗證，以保證資料和業務的正確性。
![](https://img.alicdn.com/imgextra/i1/O1CN01uKQhjF1lUWbmZ9l1s_!!6000000004822-2-tps-1399-659.png)
圖10 核心系統割接整體遷移方案
# 價值

- **客戶收益：** 核心系統從大機下移，節省大量軟硬體費用，並獲得遠超大機的水平擴充套件能力，得益於OceanBase的動態擴縮容能力，從容應對大促業務峰值，藉助Paxos多副本+主備庫架構提供媲美大機的高可用性。
- **技術提升：** 成功實現客戶核心系統資料庫從集中式向分散式架構的轉變，滿足7x24小時持續服務，高可用容災達到5級，透過“同城雙活+異地災備”的兩地三中心架構，確保核心業務RPO為0。
- **能力沉澱：** 設計出一套針對大行核心系統的分散式資料庫單元化架構及標準部署方案，同時滿足同城和異地容災需求，並形成核心產品的最佳實踐，為業務未來發展提供了有力技術保障。
- **新的篇章：** 阿里雲首個國有大行核心IBM大機下移的系統，全棧阿里雲技術，專有云 + 分散式資料庫 + 分散式微服務單元化業務改造，證明阿里雲平臺是能夠承載銀行的核心繫統，具有絕對標杆和示範效應。

某銀行客戶Db2下移分散式資料庫OceanBase案例

相關文章