歡迎訪問 OceanBase 官網獲取更多資訊：https://www.oceanbase.com/
國泰產險自 2018 年以來業務開始高速增長，現平峰日均保單量達數千萬級，高峰日均保單量達億級。面對財產保險場景化、碎片化特徵，國泰產險最終選擇分散式資料庫 OceanBase 並已平穩執行近 5 年。在此期間，國泰產險積極探索，在運維創新與資料庫遷移等方面沉澱了大量可借鑑的行業經驗。3 月 25 日，2023 OceanBase 開發者大會在京召開， 國泰產險資深資料庫專家舒明分享了《國泰產險的 OceanBase 上雲實踐》的主題演講， 以下為演講實錄。
國泰產險於 2008 年在上海成立，迄今已在東南沿海和中西部地區 9 個省市設立25家分支機構。過去的 2022 年，全年保單數量達 57.8 億單，保費規模達 53.8 億元，累計服務客戶達 3 億人， 並獲得 2021 年中國金鼎獎“年度卓越財產保險公司”、2022 年“金理財”獎年度企業社會責任獎。
國泰產險網際網路產品有兩個比較明顯的特點：
一是場景化。 所謂場景化，就是在生活和工作中遇到的一些場景。例如以電商場景為代表的退貨運費險，大家在淘寶、天貓等平臺購買商品時商家贈送的退貨運費險，很有可能就是我們國泰產險的產品。這種產品特點體現在“小單”和“天量”，“小單”是指保費收入和保額較少，但相對其他險種它的“天量”即數量非常大。像過去幾年的“雙 11”期間，國泰產險的退貨運費險日保單量基本都在 1 億以上。
二是碎片化。 國泰產險的產品覆蓋生活場景中的很多碎片化需求，這類產品特點通常不能用一些通用的模型來解釋，比較偏定製化、個性化。例如大家給自己買的健康險、給寶寶買的“萌寶保”、給父母買的“孝順保”等。國泰產險針對這些碎片化場景打造了 200+ 創新產品，驅動業務高質量發展。
面臨多重挑戰
基於國泰產險產品場景化、碎片化的特點，我們在實際生產過程中遇到了一些業務和技術上的挑戰。
▋ 挑戰一：要求 7×24 小時全天候高可用
升級為網際網路科技保險公司後，我們的系統要求 7×24 小時全天候提供服務，因為即使是在深夜也會有使用者在淘寶、天貓等線上平臺下單，進而同步購買我們的各種產險產品，假設停止服務五分鐘，都會給我們帶來直接的經濟損失。而作為底層服務的資料庫需要保持更高的可用性。
▋ 挑戰二：業務快速增長，分庫分表邏輯複雜
近年來，國泰產險在網際網路平臺上的保單數快速增長，資料庫的單表資料量急劇膨脹。這種情況下，我們曾經考慮分庫分表加歷史資料歸檔，還對一些分庫分表方案進行了選型，如透過第三方中介軟體，如直接自己寫框架在程式層進行邏輯控制。但無論哪種方案，整體邏輯都會比較複雜且後續維護不方便。
▋ 挑戰三：併發高，效能要求苛刻
每逢節假日、大促日，尤其是“雙 11”期間，高併發的特徵非常明顯。像在大促日 24 點時，很多使用者都守在 APP 前準備集中下單，短期內成千上萬甚至上億的保單量，瞬時流量非常大，對我們的應用來說壓力非常大。再加上保險業務的一個請求要經過承保前置、承保、合約、風控等鏈路，並且對鏈路上每個節點的執行流暢度要求都非常高。所以我們對資料庫效能的要求可以說是非常苛刻的。
分散式資料庫選型及成果
為了提升網際網路化交付速度、敏捷響應大規模業務需求，國泰產險決心全力打造保險中臺，而保險中臺的底層需要一款經歷過海量資料考驗的資料庫做支撐。
一方面是基於打造保險中臺的大背景，一方面是基於以上三點業務和技術上日益凸顯的挑戰，我們開始進行大量的資料庫調研工作，發現 OceanBase 有三個特點非常吸引我們，也是我們最終選擇握手 OceanBase 的主要原因。
特點一：高度相容 MySQL 和 Oracle，無需分庫分表。
OceanBase 高度相容 MySQL 和 Oracle，對國泰產險現有的 SQL 程式碼無需額外改動，對開發人員非常友好。針對資料量膨脹的問題，我們之前需要分庫分表，現在只需透過表分割槽就能解決，無需額外進行繁雜的分庫分表工作。
特點二：應用透明的水平擴充套件。
高併發下全鏈路壓測 OceanBase 的效能非常優秀，針對節假日、大促日等的高併發場景下，能進行快速的擴容、快速的縮容，並且對應用透明無感。
特點三：極致的高可用。
兩地三中心、三地五中心等多機房的容災能力，是我們非常關注的。有多機房容災的情況下，才能保證資料不論是發生機房級還是伺服器級故障時都能快速恢復、才能保證在高併發寫入情況下資料零丟失。
得益於穩定可靠的資料底座，我們能更好更快地透過技術創新賦能業務增長。從2018 年開始選型到正式上線，如今，OceanBase 已經在國泰產險平穩執行近 5 年，並得到以下主要成果：
- 高併發。 國泰產險的日均保單量級基本在數千萬，在“雙 11”期間有超高流量湧入，日均保單量超一億。OceanBase 完美支撐了我們一次又一次“雙 11” 日均保單量過億級的業務請求，巔峰達 8.5 萬次 TPS。
- 穩定性。 穩定性是金融行業選型資料庫最看重的點之一，執行 OceanBase 多年來國泰產險整體實現 RTO<30s, RPO=0 的目標。即使硬體偶爾出現故障，OceanBase 的預警功能也能提醒我們及時介入處理，我們就可以把故障節點上的Leader 租戶切走，快速替換再切回來。
- 多租戶。 我們將業務透過保障等級（高保、中保、低保）劃分為不同的租戶，租戶之間處於硬體資源隔離、資料資源隔離的狀態。如大促來臨，國泰產險可以動態調整，優先把資源調給鏈路前端部門應對高併發流量。即使當前端正在高併發寫入情況下，動態資源調整對應用也無感透明。
- 降本增效。 OceanBase 在降本增效這塊表現地非常好，國泰產險的資料庫綜合成本降低 2/3，資料庫效能整體提升 20%。
運維創新：1.X版本基於系統檢視自建資料庫平臺
國泰產險接觸 OceanBase 較早，我們最先使用的是 1.X 版本，那時的運維體驗並不像現在好。於是我們基於 OceanBase 的系統檢視自建了一個資料庫平臺，主要包含三個模組：
模組一，監控。 監控非常重要，因為我們必須要掌握資料庫當前的狀態，包括各租戶的資源狀態。國泰產險的表的資料非常大，我們精細統計到了所有表空間具體的值，將資料落庫進行趨勢展示，同時實時展示 CPU、記憶體等資源，方便運維人員和開發人員迅速分析。
模組二，報警。 當資料庫租戶的資源發生報警時，運維人員需要及時地瞭解並介入。我們基於檢視做了資源報警，如 CPU 等資源報警；慢 SQL 報警，如報警當前執行的慢 SQL、超過不能接受範圍的慢 SQL，反映資料庫的狀態；還有應用層的異常表監控，保證整個系統的穩定執行。此外，我們還接入了釘釘進行及時的報警提醒。
模組三，慢 SQL 治理平臺。 慢 SQL 的危害非常大，甚至會拖垮租戶和叢集造成大規模的應用超時。根據慢 SQL 產生的特點，我們將整個過程分為事前、事中、事後三個階段。
- 事前 Review SQL。 事前我們會進行 DBA 的人工稽核和程式卡點，雙 Review 統一進行，爭取在慢 SQL 上線之前就消滅它。
- 事中抓取慢 SQL 落庫。 慢 SQL 發生時，我們首先會透過前面提到的報警模組先報警出來，然後把慢 SQL 透過抓取落到我們自建的日誌庫。
- 事後形成工單流程跟蹤最佳化。 事後我們會對慢 SQL 進行整改，把聚合後的慢 SQL 進行清洗、分析、統計，最終形成一個工單流，派發給對應業務的開發人員。由開發人員和 DBA 雙重角色維護，因為有時慢 SQL 不僅要從 SQL 層最佳化，還可能要從系統層最佳化。
透過事前、事中、事後這三個階段，國泰產險自建的慢 SQL 治理平臺能對慢 SQL 進行全鏈路的跟蹤、最佳化，直到它上線。
僅需半小時，1.x版本平滑遷移至2.x版本
資料庫遷移是很多行業尤其是金融行業感興趣的話題，我們花費了將近小半年的時間進行遷移工作，其中大部分時間都在進行方案的論證與整理，最終實際遷移花費三個月的時間，主要分為三個階段。
▋ 第一階段，前置工作。
首先進行 OMS（OceanBase Migration Service，OceanBase 資料遷移工具）搭建。其次，進行賬號許可權梳理，有些賬號已經沒有使用或者賬號異常，我們要趁這個機會進行統一梳理。然後環境初始化，跨域跨賬號需要更多網路打通，以及各種資料庫環境建立。最後，髒資料排查，從低版本到高版本有些資料可能對資料庫來說是髒資料，我們需要清理掉，例如，某些 datatime 值不相容的問題，就可以提前更新並處理掉。
▋ 第二階段，遷移和灰度。
遷移過程本身並不漫長，但國泰產險為了驗證整個方案的穩定性和成熟度，將時間拉長至 2～3 個月，透過時間維度來驗證方案的可行性。主要包含四個步驟：
步驟一，全量、增量遷移。 我們會將所有庫表進行全量和增量的資料遷移，可以在 OMS 裡進行庫表任務的任務配置。
步驟二，資料一致性校驗。 這是遷移的重中之重，我們非常關心遷移前後的資料是否一致。針對一致性校驗，OceanBase 提供資料校驗的功能，如果發現資料不一致會顯示出來。作為金融行業，國泰產險對資料一致性的要求非常高，所以我們還自建了一個校驗資料一致性的小工具，監控這些表的同步情況，雙保底方案驗證遷移前後的資料一致性，確保源端和目的端的資料一致性。
步驟三，差異資料處理。 如果真正在遷移過程中發現資料不一致怎麼處理？針對差異資料，根據實際情況具體問題具體分析，判斷是選擇重新同步這張表，還是在目標端進行相關操作。例如，唯一索引的問題，若在早期版本中建了唯一索引，雖然有重複資料會建失敗，但還是建了，但在遷移過程中先建唯一索引的話，重複資料寫入就會報錯。
步驟四，應用灰度切流。 最後是部分應用的切流，我們將應用的查詢請求打到新的OceanBase 叢集，把 OceanBase 當成一個熱備，透過只讀場景去驗證新叢集的整個功能是否有問題。
▋ 第三階段，切換和驗證。
做了這麼多前置工作，第三階段相當於最後的臨門一腳。在整個切換過程中非常順利、順滑。那天晚上我們 8 點開始，8 點 30 基本就結束，大概持續不到半個小時即切換成功，這裡分享一下我們當時做的具體工作。
工作一，應用限流。 我們對應用做了一個系統的開關，將應用進行限流後，對底層資料庫的請求相對比較少，壓力也就比較小。 工作二，OceanBase 源端禁寫。 我們透過修改引數把 OceanBase 源端進行禁寫，儘可能保證源端和目的端的資料一致性。 工作三，統一切換配置。 我們寫了一個指令碼，可以批次修改資料來源的配置，使其連線到新的資料來源。 工作四，應用驗證恢復。 我們把所有應用啟起來進行功能驗證，恢復流量後進行最終驗證。
整個過程花了不到半個小時，這得益於我們前面進行的大量的反覆演練，不用大家蹲守到半夜釋出，這對運維人員來說是非常好的體驗。
雲上資料庫運維實踐
上雲 OceanBase 後，DBA 能明顯地感受到運維效率提升。
一是監控報警， 基礎運維工作可以配置報警規則，關心哪些引數可以及時報警出來； 二是視覺化運維操作， 我們可以將切可用區、主動發起備份等操作直接在白屏進行，相對穩定安全，不用黑屏做這件事。
三是災備系統完善， 我們之前需要透過寫指令碼進行備份和恢復，現在透過頁面化的功能來配置即可實現； 四是支援資料傳輸， 不僅支援叢集間的資料傳輸，還支援透過 OMS 傳輸至國泰產險的數倉進行離線/線上分析等。
▋ 全生命週期管理資料安全
金融行業對資料安全非常重視，隨著資料成為生產要素，各行各業對資料安全的重視程度基本上都是隻增不減。我們把資料從生產到銷燬濃縮成三個階段：傳輸、儲存、使用。
在傳輸層透過 SSL 鏈路加密且進行嚴格的訪問白名單控制。在儲存層進行 TDE 加密，對一些敏感資料進行加密儲存。在使用層針對人工查詢訪問資料庫的請求，我們統一收口到資料管理平臺，在裡面進行敏感資料保護的設定，做許可權控制和操作等級的設定等。這樣就在全生命週期的各個環節加固資料安全。
▋ 玩轉雲上 OceanBase 精細化運維
上雲之後，很多基礎運維工作確實被替代了，這個相信大家也深知，我們也沒什麼好避諱的。但不代表 DBA 沒有事情可做了，我個人應對雲資料庫時代的方案是——走近業務，貼近業務實現 DBA 的價值。
首先，在架構治理上。 有些業務建立上線的時候，不能很好地識別業務的保障等級，業務推進過程中才能識別，因此需要進行高/低保租戶隔離的動作，避免低保障的應用影響高保障的應用。
當一個新業務上線時，開發 leader 一般無法準確預估該業務未來會有多大的流量，分配資源也是按照當前該業務符合的資源，需要 DBA 後期運營。那國泰產險是怎麼做的？我們把資源使用情況透過 API 拉到近數月、一個月、一週的資料，透過資料分析該資源的使用率。如果這個月的使用率不到 20%，其已分配資源就該被動態調整。
其次，降本增效上。 原來，國泰產險的表壓縮比不是很高，我們持續在更改一些表的壓縮格式，轉成一個更低的壓縮比。此外，業務每天的全鏈路很多，每個節點每天的資料量都會有一兩千萬的增長，對於整個 OceanBase 的儲存壓力非常大，於是我們自建了一個資料庫清理歸檔平臺，把這些大表做了一個資料大盤，每張表的資料量、儲存情況以及最近的增長情況一目瞭然。根據資料分析推動開發進行配置刪除策略，這些策略整合在平臺中，可以按產品、時間等多維度進行歸檔。
對於金融行業，備份必須要做，但異地備份的價效比不是很高，除非真正發生大故障，否則很少去做。大家可以考慮把異地備份轉歸檔儲存，同時還可以降低使用成本。
最後，SQL 治理上。 一是可疑 SQL 展示與限流，如果某個 SQL 確實比較慢或效能不太好，我們可以針對它進行限流，直接在頁面上配置即可；二是全量 SQL 審計，當我們線上出現不明 SQL，可以在頁面上開啟審計開關，找到 SQL 是從哪裡來的？是否是內部執行等；三是索引建議，OceanBase 可以提供索引建議供 DBA 參考，進行相應的 SQL 最佳化；四是慢 SQL 工單流，基於上述提到的國泰產險自建的平臺，方便我們與開發同學一起最佳化慢 SQL。
總之，真正遷移到雲上的 OceanBase 後，DBA 對於資料庫運維的整體效率提升，感受非常明顯。我們可以更多地聚焦 SQL 治理、資料架構治理、資料安全等工作，更多地開發配套的提效降費工具，而不是將時間浪費在重複而又繁雜的基礎運維工作上。我今天的分享就到這裡，希望能對大家有所幫助，謝謝大家！
歡迎訪問 OceanBase 官網獲取更多資訊：https://www.oceanbase.com/