<ins id="jxy61"><option id="jxy61"><menu id="jxy61"></menu></option></ins>
          1. 煉數成金 門戶 大數據 架構 查看內容

            去Oracle實錄:如何在線更換金融核心場景中的數據庫?

            2020-7-27 14:49| 發布者: 煉數成金_小數| 查看: 65157| 評論: 0|原作者: 王英杰|來自: 架構頭條

            摘要: 陸金所從 2018 年啟動全站去 O 項目以來,在不做任何服務降級的情況下,歷時 2 年通過上百次變更,把全站 98% 的 Oracle 數據庫無縫切換到 MySQL 上。其中,這 98% 的數據庫覆蓋了陸金所的賬務、資金、資產中心、支 ...
            陸金所從 2018 年啟動全站去 O 項目以來,在不做任何服務降級的情況下,歷時 2 年通過上百次變更,把全站 98% 的 Oracle 數據庫無縫切換到 MySQL 上。其中,這 98% 的數據庫覆蓋了陸金所的賬務、資金、資產中心、支付、交易、用戶、基金、主賬戶、網貸、資管、銀行理財等全金融場景。整個去 O 的全程 0 故障、0 風險、對用戶幾乎不感知。

            陸金所去 Oracle 實踐有四大特點:
            一是在線更換數據庫,不做服務降級。讓去 O 這類重大架構改造實施落地的時候對全站用戶影響最小,同時也最考驗去 O 的架構改造的技術實現能力。
            二是對于高頻上線了上百次的去 O 變更,全程 0 故障、0 風險,這一點非?简炾懡鹚 O 的變更工具水平。
            三是在短短 24 個月的時間完成全站 98% 的數據庫去 O 改造,并且涉及陸金所全部最核心的業務,去 O 的整體落地效率非?。
            四是在去 O 各個環節實現了從開發、測試到運維各種自研智能工具來把控去 O 各個核心環節的質量,這也是把一個龐大、復雜、高風險的金融核心系統,在非常短的時間內 0 風險、0 故障,穩妥落地去 O 的關鍵。

            1、陸金所為什么要全站去 Oracle?
            陸金所為什么需要啟動去全站去 O,并且是 100% 全部去 O。

            在去 O 項目立項之初,我們希望通過去 O 來實現三個方面的提升。
            首先是降低昂貴的金融系統數據庫運營成本。2013 年至 2018 年期間,陸金所的業務成長了上百倍。業務量增長帶來的數據庫運營成本暴增。無論是傳統的 IOE 架構還是去 IE 后的 X86+Oracle 分布式架構都是如此。IOE 架構下,高端服務器和高端存儲的價格隨著提供的計算和 IO 能力呈現指數型增長。X86+Oracle 架構下,分布式改造和數據庫細粒度水平拆分后雖然沒有 I 和 E 的成本,但數據庫節點暴增后導致 Oracle 軟件授權費用暴增。

            其次是希望通過去 O 來打造一個不依賴特定數據庫特性的金融交易系統,徹底擺脫被商業數據庫廠商技術綁架的風險。傳統金融交易系統使用數據庫特性承擔了大量的業務邏輯和架構屬性,造成系統對某個數據庫特性的強依賴,也大大增加了被技術綁架的風險。陸金所通過全站去 O 實現了把金融交易系統里數據庫的角色轉化為只支持基本增、刪、改、查的存儲引擎,全站系統架構弱依賴數據庫特性。

            最后一點也是最重要的一點,我們希望通過全站去 O 這樣一個涉及到開發、測試、架構、DBA 等全部研發團隊都參與的重大架構改造項目,來鍛煉研發隊伍、提升研發能力,并把歷史上一些架構設計不完善的地方,通過全站去 O 進行重構。因為去 O 不僅僅是更換數據庫,更重要的是落地架構拆分、微服務化、分布式事務等配套的大量架構改造工作。這些工作需要開發、架構、測試、運維高度協同配合,并穩妥落地。所以去 O 是非?简炑邪l團隊技術水平的架構改造項目。通過,我們也希望通過去 O 打造“研發規范——研發工具——研發人員”的研發管理體系閉環。這一塊我們在后面會詳細展開,并向大家進行介紹。

            2、技術選型:為什么是 MySQL,又不僅是 MySQL
            決定去 Oracle 之后,選擇什么數據庫或存儲引擎來承載 Oracle 的流量?我們從功能、資源、案例和壓測四個方面來進行選型和評估。

            首先,選擇的數據庫要從功能和性能上能夠承接 Oracle 在各種場景下計算和 IO 能力。其次,它還要具備最廣泛的社區資源、技術資料和問題處理案例,通俗的說就是大量坑被踩過,以及最廣泛的用戶基礎,外面招開發和運維工程師都比較好招。然后,還要在業界有可參考的金融場景案例。這一點相信大家都很熟悉,阿里和騰訊在金融場景上已經有不少成功的案例。

            最后,同時也是最重要的一個評估標準就是陸金所自身上線前嚴格的壓測環節。陸金所在切換任何一張表流量的時候,都會使用生產環境完全真實的數據搭建 O 和 M 并行壓測環境,來獲取訪問這張表的所有讀寫接口的在 Oracle11.2 和 MySQL5.7 下的性能比對報告。經過每一輪非常嚴格的壓測后,發現 MySQL5.7 的性能比我們預估中的更好。通過從邊緣系統往核心系統的逐步去 O 演進中,MySQL5.7 就成為陸金所去 O 最主要的替代存儲引擎。

            我們都知道 Oracle 是個非常優秀、且覆蓋場景非常全面,無論是 OLTP 還是 OLAP 場景表現都很優秀,所以這種功能承接應該遠遠不止一種數據庫或存儲引擎,涉及到多種存儲引擎發揮他們的優勢在各種特定場景下來替換 Oracle。

            所以最終的結論是綜合選型下來確定 使用 MySQL 為主,TiDB、Redis、ES、HBase 等多種存儲引擎為輔的方式,100% 全部替換掉 Oracle。

            3、陸金所去 Oracle 方案
            接下來,我們就詳細介紹陸金所的去 Oracle 方案。
            去 O 雙寫和切換方案

            陸金所去 Oracle 改造主要是分為應用和數據庫兩個部分來落地的。
            首先介紹一下應用層部分的落地。應用層在去 O 的時候會做一個整體規劃,把一個大的系統或庫拆分成多個可獨立落地的批次,然后會把應用的業務邏輯層從數據庫的訪問接口盡可能剝離出來,讓 DAL 層專注只做好數據庫交互的操作。同時,在 Oracle DAL 層的基礎上,對 MySQL DAL 層的進行重構,并且配置流量開關讓上層的業務邏輯層可以自由選擇和數據庫的交互是走 Oracle DAL 層還是 MySQL DAL 層。每個批次都會有自己單獨的流量開關進行控制。批次拆分的時候遵循一個原則就是把具備業務相關性和事務相關性的表放在一個批次里。

            再說數據庫層的落地,在 Oracle 還在不斷對外提供服務的時候,我們會在后臺建立起一個和 Oracle 保持實時數據同步的 MySQL 數據庫,即當 Oracle 的事務提交后,秒級同步到后端的 MySQL 里面。同時這個同步是雙向的,當未來流量切換到 MySQL 后,也會在 MySQL 事務提交完成后,把數據秒級同步回 Oracle,這就類似 MySQL 的雙 master 架構,只不過數據是在 Oracle 和 MySQL 這個異構數據庫之間建立雙 master 架構。

            在這個架構中為了確保數據庫的一致性和完整性,一定是嚴格要求某個批次的寫流量只能在某個時間點只能在 O 和 M 一個地方寫入。陸金所研發了一整套自動化構建數據庫雙寫的工具平臺,只要在平臺上選擇需要建立批次的 Oracle 表,就能在后臺全自動完成 Oracle to MySQL 從表結構轉化、數據全量同步、數據增量同步、數據實時同步、數據校驗和數據雙向同步建立整個全流程繁瑣。依據這套自動化平臺,陸金所只投入 2 個 DBA 就完成了全站上萬張表的去 O 數據庫遷移和運維層的全部準備工作。

            最后是流量切換,我們設計并研發了一套總控開關機制來協調從應用、到數據庫、到傳輸、最后到流向的全盤流量切換。實現當流量在 O 時,實時同步到 M。當流量在 M 時,實時同步到 O。保證切換一瞬間,最后一筆事務在源庫提交成功,在目標庫傳輸成功,并完成最后一筆事務的數據在源庫和目標庫的數據校驗后,同一個批次下所有表的寫流量在同一個時間點同時完成切換。

            應用流量在 O 和 M 之間快速切換

            雖然去 O 流量切換會在 10 秒內瞬間完成,但整個過程按照細粒度劃分會有十多個步驟。為了方便介紹,我們把這十幾個步驟精簡成了三個狀態。

            首先是初始狀態,這個狀態下生產的只讀流量可以在 Oracle 或 MySQL,寫流量可以在 Oracle,由 Oracle 對外提供服務。這個狀態狀態可以理解為 Oracle 為主庫,MySQL 為 Oracle 的異構實時備庫。

            其次是中間狀態,這個狀態下 Oracle 和 MySQL 會進入一個非常短暫的寫保護靜止狀態。在完成最后一筆 Oracle 事務提供成功,并同步至 MySQL,且完成最后一筆數據一致性校驗后,會把應用開關的流量切換到 MySQL,這個時候這個批次的寫流量在某個時間點全部一致性都切換到 MySQL。

            一旦在 MySQL 里寫流量進來,就進入了第三個狀態即完成狀態,一旦寫流量的事務在 MySQL 中提交成功,雙向實時同步鏈路會把 MySQL 的數據秒級同步回 Oracle,這個時候可以理解為 MySQL 是主庫,Oracle 是 MySQL 的實時備庫。

            需要注意的是,這個架構下需要解決大量的細節問題,比如避免同一筆記錄雙向循環寫的問題。

            陸金所實現的這個雙寫框架流量切換速度極快,在數秒內就能實現有狀態的寫流量從 O 到 M 的快速切換,整個過程在低峰期落地對業務影響非常小,甚至是不感知。如果在去 O 之前在 Oracle 內部已經完成了對用戶的水平拆分,以批次和用戶雙重細粒度進行去 O 流量切換,那么整個更換數據庫過程幾乎是無感的。

            在流量從 O 切換到 M 后,以陸金所落地的經驗來看,大概有一定概率(比如程序的 bug)需要回切到回 Oracle。這套切換框架可以確保在幾秒內流量快速回到 Oracle,且在 MySQL 寫入的少量數據也會同步回 Oracle,且在保證 Oracle 和 MySQL 兩邊的數據嚴格一致性和完整性的過程中,進行流量的快速前滾和回滾。

            適用于金融核心系統的穩妥去 O 推進方案

            了解了去 O 流量切換的架構和方案,接下來我們介紹如何在一個關聯系統龐大、業務邏輯復雜、改造風險極高的金融核心系統里落地整個去 O 方案。
            首先我們會以表為粒度來把一個復雜、龐大的金融核心系統和數據庫拆分成多個批次,拆分的原則上面也提到了一點,即把有業務相關性和事務相關性的表放在同一個批次里,在確保這個基本原則的情況下,把單個大庫盡可能的拆分成多個批次,確保每個批次里的表盡可能的少。

            為什么要基于這個原則來落地實施呢,因為批次是去 O 變更的單位,O 和 M 之間的流量切換開關是控制到批次的。把批次拆分的足夠細,最終目標是為了實現“改造難度可控、上線進度可控、切換風險可控”的 3 原則。

            首先對于金融核心系統中一個復雜的模塊來說,去 O 改造的周期會橫跨半年甚至一年以上,在這個過程中,金融核心系統在 7*24 小時不間斷對外提供服務,應用層的代碼和功能每個月甚至是每周也處在高速迭代中,不斷的新功能被加入到系統并被發布到生產。

            而在這個過程中,要落地去 O 這類龐大的架構改造,必須框定一個可快速迭代和實施的改造范圍,批次就是一個合理設定的單次去 O 改造和變更的范圍。批次拆分的粒度細,可以確保在單個批次的去 O 改造工作量可控、改造難度也可控。

            同時因為批次的粒度細,在做去 O 變更切換流量時,對整個金融核心系統的影響也可控;谶@種思路,就可以實現“小步快跑”的高速迭代方式來改造應用、上線版本以及切換流量。即每次只改動核心系統的一小部分,改動完成后快速測試、快速發版上線、并且風險可控的把這部分流量切換到 MySQL 運行,如果有問題依靠強大的流量切換框架,快速把流量回切回 Oracle。

            從圖中大家可以看到一個龐大的金融核心系統去 O 改造中,應用改造、上線版本和流量切換這 3 件事情實在并行落地的。

            最開始是應用改造,改造完了上線發版,發版后就有了這個批次 O 和 M 的流量開關,并具備了切換條件,之后在某個變更日把流量從 O 切換到 M,如果遇到任何問題可以快速切回來。應用版本在不斷上線迭代,流量在分批次不斷切換,一個龐大的金融核心系統就在多次高速迭代中一點點的從 O 切換到了 M。

            整個過程對核心業務不影響、不感知,且對參與去 O 的開發、測試和運維開展去 O 工作非常友好,讓他們可控的去落地各項工作。

            在這個過程中,從第 1 張表從 Oracle 切換到 MySQL,到最后一張表關閉 Oracle 流量,在非常長的一段時間內,整個應用是由 Oracle 和 MySQL 在同時提供服務。其中某些表已經完成去 O,讀寫的流量在 MySQL 上,由 MySQL 同步到 Oracle,部分表還未完成去 O,讀寫流量在 Oracle 上,由 Oracle 同步至 MySQL。這就非?简炦\維的能力,要確保在這個架構下每天高頻的各種發版和數據庫變更都非常準確。

            基于此,陸金所是有研發一整套配套去 O 變更工具,來確保整個去 O 過程中大量變更準確實施和落地。以陸金所交易、主賬戶、資產中心、基金、賬務等核心庫為例,從第一張表流量切換到 MySQL 到最后一張表切換到 MySQL,歷時 12 個月以上。按照上述方案一點一點的替換掉 Oracle 數據庫,整個過程完全不做服務降級,對陸金所的 4500 多萬用戶無感知。

            4、陸金所去 Oracle 方案的落地
            在 PPT 中畫出去 Oracle 的架構圖是很簡單的事情,但是架構改造的難點和重點在于落地。要在生產環境落地是非常龐大且復雜的系統工程,尤其是對一個 7*24 小時的金融核心系統來說,進行重大架構改造本身就是一件高風險的工作,既要做到規避風險,確保各種工程實現細節有效落地,同時又要保證系統的業務連續性,甚至是對外部用戶不感知。

            去 Oracle 架構改造的本質是什么?我覺得有兩方面,一是細節規則,二是上生產前發現和上生產后兜底。

            去 O 的重點不僅僅是方案本身,更重要的是組成方案的數百條細節規則,能在一個參與去 O 的、龐大的研發團隊里每個開發所寫的每一行代碼都有效遵守規則,同時在每個運維設計的生產變更方案里每一條命令都有效遵守規則。方案通過從邊緣系統往核心系統逐步推進過程中,會逐步趨于完善,方案中的規則也會被逐步積累和完善起來,那么把這些規則落地到研發團隊的每個人上,是關鍵和重點。

            上生產前發現是指如果規則在某個微小的細節實施時沒有被遵守,如何盡可能的在上生產環境之間發現隱患。上生產后兜底如果問題突破了所有檢測環節上了生產,如何設計一個兜底方案可以有效控制風險,把影響盡可能降低。

            去 Oracle 落地工作都應該圍繞有效解決這兩個本質問題展開,并提升這兩個問題的解決效率,降低人力成本。

            陸金所的做法是建立“人員——規則——工具”的閉環。
            陸金所通過“人員制定規則——規則通過工具落地——工具確保所有人員的代碼和變更符合規則”的方式來確保各種細節工作落實到位,整套工具最終沉淀為陸金所數據庫升級平臺。

            以陸金所的去 O 落地經驗來看,一個不起眼的細節問題如果未進行有效管控,都有可能引發嚴重的生產故障。所以我們可以把陸金所數據庫升級平臺理解成為一套強大的去 O 風控系統。這套風控系統覆蓋 SQL 重構、表結構轉化、數據遷移、數據校驗、分布式事務構建、流量切換等橫跨從開發到運維在去 O 架構改造方方面面會遇到的問題。通過這套工具平臺,有效確保參與去 O 的研發團隊在每個細節上都處理的非常規范,從而實現歷時 24 個月的全站去 O,無風險平穩落地。

            除了確保各種規則精準落地外,金融核心系統去 O 改造需要多個研發團隊協同作戰、有效配合、共同推進。其中涉及到大量工程實現細節工作需要多團隊有條不紊、事無巨細的協同配合好。任何疏漏都有可能會引發嚴重的生產故障。

            5、經驗總結:談談企業去 Oracle 的目標
            去 Oracle 的口號喊了很久了,但是為什么要去 Oracle,去 Oracle 想要達到什么樣的目標...... 有些企業可能沒有想得很清楚,所以我也想從自己的角度和經歷來談談去 Oracle 的目標。

            目標一:省錢
            去 O 完成后,使用“免費的開源數據庫 + X86 架構的 PC Server”來搭建金融核心系統,真的很省錢。因為搭建金融核心系統從昂貴的高端服務器、高端存儲和 Oracle 一體機,以及昂貴的 Oracle 軟件授權變成只需要 6 萬一臺的 X86 服務器,花在數據庫上的運營成本降為之前的 10% 不到。

            在整個去 Oracle 的過程中,陸金所架構從一個傳統金融的超大型數據庫支持各種核心業務的架構變成了以微服務化驅動的分布式架構,這種架構具備以下特點:
            每個服務有自己獨立的應用和數據庫。
            每個庫只提供給服務內的應用直接訪問,即服務內的應用可以通過 SQL 訪問。
            服務之外的應用訪問數據庫需要走應用層的服務接口,避免跨服務訪問數據庫。
            服務分為同步調用和異步消息。
            在服務內實現數據庫的水平擴展。
            對于類似用戶、交易、資金等公共類基礎服務,逐步迭代為中臺服務。

            通過微服務化拆分,幾套集中式的 IOE 大庫就變成了微服務小庫,同時對于訪問量和數據量較大的中臺服務,又會進一步細粒度水平拆分。

            目標二:架構升級和改造
            除了降低成本,我認為更重要的是通過去 O 實現傳統金融系統全方位的架構升級和改造。

            對于一個傳統金融系統來說,借助去 O 來實施和落地全系統的架構改造和升級,應該是一個再好不過的機會。以陸金所為例,通過去 O 實現了以下的升級和改造:
            數據庫底層計算和 IO 能力的水平擴展,并且這種水平擴展完全基于 6 萬一臺的 X86 服務器,擴容成本極低。
            同時實現了應用訪問數據庫的規范化,應用和應用之間的服務化。全站的調用鏈會非常清晰,應用和數據庫之間不合理的依賴將大幅降低。
            另外實現數據庫層去中心化,單個數據庫的可用率對全局可用率影響有限,消除中心化的單點隱患
            最后借助去 O 實現的分布式架構,可以把各個分片的數據庫部署在不同的機房,從而實現真正意義上的機房多活。

            目標三:引入更合適的存儲引擎
            提到去 Oracle,可能很多人在第一時間就想到了 MySQL。其實,MySQL 是承接 Oracle 主要流量的數據庫,但 MySQL 無法承接 Oracle 的全部流量,例如以下幾類經典場景:
            Oracle 在 oltp 場景當中少量 hash join 查詢場景。
            Oracle 中多表關聯和多層復雜嵌套查詢場景。
            MySQL 細粒度拆分后,跨庫、跨分片的查詢場景。
            在 MySQL 集群和 Hadoop 集群之間構建一個秒級數據同步的 ODS 層。

            在這些場景中,可以引入 TiDB、Elasticsearch、Impala+kudu、Redis 等多種存儲引擎。這些存儲引擎在合適的場景下替換 Oracle,產生的效果是不但比 IOE 架構成本低得多,性能也會比 Oracle 快得多。

            我們以 TiDB 為例來講講使用 MySQL 之外的存儲引擎是如何支撐 Oracle 流量的。

            陸金所有個實時對賬的場景,需要跨用戶庫、交易庫、資金庫和資產庫進行復雜的關聯查詢。在完成去 O 后,數據庫在 MySQL 上做了細粒度拆分,無法跨多個獨立的服務庫進行復雜且高頻的跨庫查詢。

            為了支持這個場景,我們研發了數據總線來實施解析 MySQL binlog 并生成消息同步至 TiDB,事務在 MySQL 提交后實現秒級同步至 TiDB。之后通過 TiDB4.0 的 TiFlash 功能(類似 clickhouse 的列式存儲),在 MySQL 和 Hadoop 之間搭建一個實時 ODS,實現了秒級處理跨庫、多表、復雜關聯的查詢場景。性能遠超去 O 之前在 IOE 架構下的處理結果。

            聲明:文章收集于網絡,版權歸原作者所有,為傳播信息而發,如有侵權,請聯系小編刪除,謝謝!

            歡迎加入本站公開興趣群
            軟件開發技術群
            興趣范圍包括:Java,C/C++,Python,PHP,Ruby,shell等各種語言開發經驗交流,各種框架使用,外包項目機會,學習、培訓、跳槽等交流
            QQ群:26931708

            Hadoop源代碼研究群
            興趣范圍包括:Hadoop源代碼解讀,改進,優化,分布式系統場景定制,與Hadoop有關的各種開源項目,總之就是玩轉Hadoop
            QQ群:288410967

            鮮花

            握手

            雷人

            路過

            雞蛋

            最新評論

            熱門頻道

            • 大數據

            即將開課

             

            GMT+8, 2021-5-1 17:40 , Processed in 0.114164 second(s), 23 queries .

            年轻人手机在线观看