大型國有銀行，整體核心的系統都是大機+DB2這樣的傳統架構；針對現在的網際網路金融業務快速擴張的需求，傳統的架構面臨著比較大的挑戰，主要集中在四個方面：
l 處理能力；因為工行這麼大的體量，導致整體系統的規模比較龐大，這種垂直的單一的擴展模式，不具備橫向處理能力，處理能力受到限制；
l 運行的風險；隨著很多的業務從網點變成線上，新的業務提出了更高的業務連續性保障，包括7×24小時，傳統的架構從架構設計上無法做到這樣的支持；
l 快速交付；傳統的開發模式應用內部模塊、應用與應用之間的耦合度非常高，使得軟體的開發和產品交付周期比較長；
l 成本控制；大型主機運營成本非常貴，買個機器幫你搞兩下就幾千萬上億的支出，再加上商業產品的License比較高，銀行議價能力又比較低；
在這種情況下進行IT架構轉型，整體的訴求是優化應用架構、數據架構、技術架構，建立靈活開放、高效協同、安全穩定的IT架構體系，強化對業務快速創新發展的科技支撐。
1.2 轉型的核心訴求和策略
在上面的轉型大背景下，數據作為核心，我們展開了對開放平臺的資料庫的架構轉型，同時提出了幾個核心的策略：
l 第一，在業務支撐方面，做到高並發、可擴展、支持海量數據存儲及訪問。以及兩地三中心高可用容災。工行在國有大型銀行裡應該是比較領先的實現兩地三中心容災體系；
l 第二，降低使用成本，基於通用的廉價的硬體基礎設施，希望提升自己的管理控制能力，進行行內適配和定製。降低對商業產品依賴，提升議價能力；
l 第三，運維能力，提升資料庫的運維自動化智能化，更加開放的技術體系以利於自主掌控。主要採取三方面策略：
一：集中式向分布式的轉型；
二：是專有向通用的轉型，也就是去IOE；
三：限制商業產品，擁抱開源；
這是我們當時採取的策略。結合近期的國家提出安全可靠的工作要求，對國內的生態和服務商也是比較好的挑戰和機會。
二、 轉型的發展經歷2.1 轉型路線圖2.1.1 三年轉型之路
整個轉型歷程，大概從2015年開始IT架構轉型，但真正有進展應該是從2016年初到2017年這個時間。我們整個的發展歷程大概可以分三個階段：
第一階段 原型的研發和探索
l 2016年初到2017年的過程，當時結合人民銀行對於個人帳戶的管理要求，實行一類二類三類帳戶；結合這樣的工作要求，把個人帳戶從主機下移到開放平臺，基於開放平臺的高性價比、可擴展進行了很多的探索，進行了很多的技術驗證。當驗證了技術可行性之後，我們提出了一個開放平臺資料庫轉型的規劃，這個規劃對於我們行內後面幾年的工作，對於資料庫的方案選型是非常大的影響。這個規劃確定我們行裡要建設基於開源的MySQL OLTP資料庫解決方案。
第二階段 基礎研究和試點
l 2017年整年，我們基於開源的MySQL資料庫進行產品的研究和能力的建設，以及初步能力的建設，包括基礎研究和應用的試點。在此期間，前面提到的原型也是在2017年5月份上線的，在生產線上跑起來了，把整個技術體系都進行了驗證。
第三階段 轉型實施及推廣
l 2018年開始大規模的實施和推廣，在這個過程中基於開源的MySQL資料庫，我們逐步建立起了一個企業級的資料庫服務能力，包括引入了分布式的中間件，在高可用、運維能力的提升，資源使用率的提升，MySQL的雲化及自主服務的建設等等。在整個過程中，同步對OLTP的分布式資料庫進行了研究，也對後面的工作指導提供了依據；
2.2 選型階段2.2.1 方案選型調研
在選型階段，我們基於業務場景進行了大量的方案調研。坦率的說，工行軟體開發中心在2014—2016年持續關注著行業內資料庫的發展和生態的發展，在這個過程中我們對很多的產品進行了一些研究和摸底的測試。
NewSQL資料庫方案，是很多的網際網路企業或者一些小型企業有所使用的，但是我行在選擇技術的時候是非常謹慎的，以及要做非常多驗證，在當時並不符合我們系統設計的考量點；
基於開源的分布式OLTP方案，業界有很多豐富的案例，而且在網際網路企業裡面得到了很好的實踐，在業界資源案例都很豐富。是同時能應對我行的高並發、彈性擴展需求的；
所以我們最終確定從分布式架構的角度去解決整個架構的挑戰，不僅僅只從單一的資料庫的層面解決這個問題。
2.2.2 分布式技術棧
基於這樣的一個原型探索，我們構建了一系列的分布式架構技術棧，包括分布式服務、分布式事務框架、分布式批量框架、分布式緩存、交易數據核對及補償、分布式消息、配置中心、開發及運維管理。這裡簡單說一下：
l 分布式服務改造，針對我們傳統架構耦合比較緊密的特點，通過服務化的改造，降低耦合度。降低耦合度的同時，還可以盡最大可能的避免分布式事務的產生；
l 分布式事務的框架，我們結合兩階段提交和分布式的消息，支持強一致性和最終一致性多種模式的支持，通過分布式事務框架解決分布式事務的問題；
l 分布式批量框架，在大規模的數據結點上進行批量操作的一個整體的解決方案；
l 業務層面，在交易或者應用級層面進行數據核對及補償，有些場景就是在傳統的OLTP的情況下，也會對應用上下遊進行核對和補償；
l 分布式消息平臺，實現這樣一個應用級的數據交互；
同時我們也進行了運維的規劃和總設計。這裡引入了開源的MySQL資料庫來解決數據最終落地的問題
2.2.3 MySQL高可用方案
在原型階段，當時主流是MySQL5.6，5.7才剛出來；對於高可用要求，行裡的應用是要做到同城切換，上海兩個園區要做到RPO是0，RTO非常小，同時異地北京有一個災備中心，就是兩地三中心。
我們的AB類重點應用必須具備這樣的同城兩個園區同時對外服務的能力。在原型設計階段，我們基於MySQL的半同步複製，來做這樣的一個切換，實現RPO=0，解決主庫故障自動切換到備庫，同城為了保障RPO=0，在原型階段進行了應用的雙寫。來進行數據的核對和補充；
這裡順便提一下，MySQL5.7相對5.6的改進非常大的，這是一款真正可以適合金融行業的資料庫產品，它在數據回放方面，在性能方面都有比較大的改進和提升；
2.3 實施推廣階段2.3.1 基礎研究和應用試點
第二個階段是開源MySQL基礎研究和應用試點，就是2017年。對於這些元素研究以後，在行裡要發布第一個產品；把這個產品推上線，要做很多的工作：
產品的基礎研究，我需要驗證功能、新特性和配置基線，數據備份恢復，還要結合它的特性來設計應用的高可用，提供開發的技術規範；
我們的角色既要考慮到運維，也要考慮到上遊應用，做好上面的銜接、對接和支持。包括應用的開發規範，它的性能能力評估，上線需要多少設備，容量是多大，還要對Oracle等老架構給予指引和幫助，代碼寫不好還要弄個檢查工具等等。運維方面就是要提供各種安裝部署的便利化，然後行內和行內的監控系統進行對接，制定很多的指標和參數，如何和行裡進行對接，然後新問題的分析等等一系列的問題。在這個階段我們實現了同城RPO=0，RTO=分鐘級目標，RPO為0的切換，問題可監控，實現了人工或自動的一鍵式切換。
這個階段，行裡決策了之後，我們一下子上了21個應用，211個節點，這是2017年。
2.3.2 分布式中間件應用
2018年開始轉型和實施，並且大量應用上線；之前的基於應用級的分布式解決方案，遇到了一些新的限制；部分應用不想設計的過分複雜，這個時候引入了開源分布式中間件DBLE，引入它的目的就是為了簡化開發的工作量，通過引入這樣一個DBLE來支持垂直數據分片、水平數據分片、混合分片等場景的支持，還支持簡單的跨庫匯集查詢提供類似集中庫的操作體驗，這個時候開發場景就簡化了，給了應用更多的選擇，簡化了應用開發的複雜度。
2.3.3 運維架構流程完善
解決了應用開發的複雜度，運維怎麼辦？高可用怎麼辦，我們結合DBLE和運維管理平臺，實現整平臺聯動，支持從高可用、監控告警、安裝部署、自動化補數等等一系列的解決方案；
2.3.4 運維管理能力沉澱
這時進行運維能力的提升，也迫在眉睫；因為分布式隨著實施的運維節點的增加，運維是一個很大的挑戰，那麼多的節點，安裝、監控、報警、故障、人工處理等非常麻煩；
我們首先提供一個自動化的安裝部署，實現批量安裝部署，批量串行還不行，時間太長了，要並行，並行太高了，網絡的流量會受到比較大的影響，所以這個方面有很多的場景都需要打磨。
第二是監控告警，監控告警裡有事件等級，分各種等級，這些需要靈活的定製，建立基線告警，建立應急流程。
第三是故障的分析，完善日誌記錄、採集和分析，建立故障分析規範。
第四是自動巡檢，自動化的巡檢和評分報告，對實例狀態進行健康評分。
2.3.5 統一運維平臺建立
我們通過這樣一個統一的運維管理平臺，把所有的節點都納入進來了，實現一鍵式的安裝、版本的升級、參數的配置。並且實現了多種高可用策略配置，包括自動、人工一鍵式切換。
談到為什麼要有自動化和人工的兩種切換方式？一種新的事務上線之前，都會面臨一些挑戰和懷疑的，都是一個循序漸進的過程，特別是是在金融行業，我們實現了多種高可用策略的靈活配置。
2.3.6 故障自動切換上線
我們建立了一個自動化、高可用的決策系統，大家知道人工決策到自動切換，雖然只是邁出一步，但是面臨著很大的挑戰，包括決策的因素和決策的模型，最難的是還要應對不同應用場景的需求，有的時候說RPO優先，有的RTO優先，有的要求三分鐘搞定，有的說10秒鐘5秒鐘我都難受，你要有這樣的模型適配這樣的場景，這是非常大的挑戰。在整體上面基於MySQL的複製技術，我們有半同步復職和多數派共識機制實現冗餘備份。基於MySQL binlog日誌自動數據補全，保障數據的一致性。
2.4 實踐中的改善優化2.4.1 高可用方案改進
同時實施過程中我們走的比較快了，一年幾百個節點，幾十個應用。在這個過程中，我們又對高可用方案進行了持續的優化，同時學習和借鑑網際網路包括分布式資料庫的一些方案，我們把一主兩備，本地1備和同城1備，擴展成1主3備，通過半同步的機制，做到真正的在系統級去保證RPO=0；
2.4.2 異地災備和存儲優化
異地災備和存儲方面，當初跑的太快，方方面面有些沒有考慮那麼完備。
我們剛才說了，我們在上海到北京有一個災備。數據災備剛開始方案，採用磁碟複製實現災備，這個也是要支出軟體費用，也比較耗錢。第二個是冷備，無法熱切換，RTO至少半個小時以上。這個方面我們改進了，用了MySQL異步複製；
另外存儲方面沿用的集中存儲，一套集中存儲上面同時支撐六七十上百個MySQL實例，IO的性能非常容易成為瓶頸。在應對一些高並發場景的時候，因為IO性能不足，這方面我們就改進了，直接引入了SSD盤，基本上把MySQL、IO的瓶頸給解決了。在現在的場景下，IO一般不會成為瓶頸了。同時通過SSD的引入，交易的響應時間在相同條件下降低50%。
2.4.3 MySQL 容器化探索
MySQL的上容器，首先說一下為什麼要搞這個事情？因為工行一兩年轉型過來，大規模的上MySQL資料庫，節點非常多，機房和設備成為一個瓶頸，再這麼玩兒下去機房容量不足了。這個時候需要提升資源的使用效率。
在很多應用裡，因為它的超前規劃，一般為了穩定運行，基本上都提出資源申請的時候，都是物理機，為了滿足後面幾年的業務需求，大規模的申請物理機，但當前應用的交易量又不是那麼大，浪費比較嚴重的。這個時候我們提升資源的使用成為緊迫的問題。這個過程中為什麼選擇MySQL的容器呢？幾點考量：
第一、行業化裡的商業軟體都是用的VMware，
第二、VMware在IO方面，在系統性能方面都有比較大的損耗。
第三、行裡在IaaS、PaaS方面建設好多年了，我們無狀態的應用服務其實全部上了PaaS，全部上了容器，在這方面有一些技術的積累，結合行內對於雲戰略的規劃，所以我們MySQL選擇了上容器。上容器解決的兩個技術要點：
l 第一個就是容器對數據的持久化支持；
l 第二個是對服務的暴露；
整體我們MySQL上容器，在現階段僅僅是把它作為一個虛擬化的技術，它的整個高可用，包括它的整個監控、整個的安裝部署都是通過我們之前提到的管理平臺來實施的。通過上容器，我們提供了一鍵式的環境供給能力，通過上容器把IaaS、PaaS全部打通過了，能很快的把基礎環境，按照行內的標準和模式很快的供應出來。資源的使用效率提升提升了4到5倍。截止當前我們行內在MySQL上容器這塊，應該是有400多個節點。
三、轉型成效3.1 轉型實施成果
我們實施了至少120多個應用，2000多個伺服器節點，超過2500個MySQL節點。實施的應用涉及很多核心業務，包括個人帳戶、對公帳戶、基金以及很多A類、B類的應用，大多都是主機上遷移過來的。其中還有少量應用是從Oracle遷移過來的，應用層也因此需要重構。
我們通過MySQL支持的核心交易達到日均7億的交易量，經歷過雙十一、2018年的雙十一和春節的高峰期的1.5萬的TPS。我們的架構現在通過橫向擴展可以達到幾萬的TPS。我們就是基於3萬TPS的設計目標進行了架構設計，理論上通過擴展設備還可以無限地增加。如果通過主機想達成這個目標，那麼挑戰就會比較大。
另外通過良好的架構設計，我們可以滿足兩地三中心的架構要求，做到同城RPO=0，RTO<60s。剛才有人問到同城雙活多活，現在很多的"多活"，包括網際網路公司的架構，都是最多能夠做到分片雙活的維度，兩邊同時提供對外服務，但是同時對於某一分片數據的寫入只能是單活的。
通過架構轉型，我們在自主能力方面，初步建立了企業級的基於MySQL的分布式解決的自主能力：首先是分布式框架+MySQL的應用級分布式解決方案，這個方案承載了我們很多的從主機下來的應用。其次是基於分布式中間件構成了所謂聯機交易的資料庫，這樣能應對一些不是很複雜的場景，通過良好設計的分庫分表方案就可以滿足需求。
在成本方面，我們在主機上的成本投入明顯下降。這幾年我們的業務交易量每年以20%的速度增長，但是主機並沒有進行擴容，投入還逐年降低。商業產品的資料庫的使用不僅實現零增長，還有所下降。從整個經費上來說，應該有比較大的降幅。
3.2 典型案例1:個人帳戶平臺
介紹一下作為我們架構設計原型的個人帳戶平臺，這是從主機上遷移下來的應用。當時的交易要求高並發、低延時，日均交易量3億，這個應用的內部交易延時不能超過100ms，要求7×24小時的聯機服務。
我們實施的架構是高可用架構同城分片雙活。實施效果是日均交易量超1億以上，本地高可用做到自動化切換，RPO=0，RTO<30S。同城高可用切換也是60秒內切換。
同時結合MySQL的管理平臺，對自動化的切換能力進行了包裝，同城的切換會面臨著比較大的挑戰：本地的高可用切換是基於SIP的，它是對應用透明的；而同城切換是對應用不透明的。於是我們設計了從伺服器到資料庫的整體切換流程，資料庫要和應用伺服器進行一些聯動來實現同城自動化切換。
3.3 典型案例2:信息輔助服務
另外一個案例就是通過DBLE實現分布式資料庫。這是第一個數據量比較大的系統，它要求高並發、低延時，日均交易量2億，交易響應延時要求10ms以內，當時的業務數據量大概20T左右，還要求7×24小時的聯機服務。我們的架構是通過分布式中間件做MySQL的分庫分表，一共128個分片。我們對分片進行了合併部署，這看上去像是過度分片，但是資源使用上就收益很大。DBLE中間件在日間進行聯機服務，夜間進行批量變更，把主機上的一些數據同步下來。這個架構整體上實現了本地和同城完全自動化切換，RPO=0，RTO<30S。
四、後期工作思路
結合我們行的OLTP的數據轉型，後續幾個方向是我們行要大量工作的。
第一個是雲化服務。現在SaaS雲也好還是什麼雲也好，工行對於一些新的技術是保持跟蹤，當它有普遍性，很好的落地以後，可以使我們不會比網際網路慢一拍，在技術經過更多的打磨，我們認為它成熟以後再引用。在雲化服務方面，我們這邊結合像MySQL，像其它的一些資料庫，我們要加強雲化服務的建設。通過我們剛才的一些平臺也好，一些自主服務的建設也好，加強後面雲化服務能力的建設。
第二個是數據統一交換。我們剛才提到消息平臺，它實現了應用和應用之間的數據交換，這個是業務級的。那麼我們現在除了這樣的一個業務級的，我們還需要一個系統級的來實現不同資料庫和資料庫系統級的準實時的數據的交換和複製，只有把數據流轉，把它活動起來了，那麼數據才能更好的發揮它的業務價值，我們行目前也在建設這一塊的數據複製平臺。
第三個就是Oracle的轉型。工行應該把Oracle這樣的一些特性用的非常極致；基本上都是存儲過程，當開發框架一確定，大家存儲過程都是用筆勾幾下或者拉幾下就可以產生很多的流程，但它同時和具體的資料庫綁定了，後面的維護、擴展都面臨比較大的挑戰。比如說如何用相對可以接受，相對較低的代價進行Oracle的轉型，因為整個資料庫、整個應用重構開發的代價還是非常非常大的，這個也是我們的後面需要探索和思考的事情。
第四個就是對分布式的資料庫。在分布式資料庫來說，我剛才說了，我們從2015年以來，就一直跟蹤著業界很多的分布式資料庫的產品。我們應用級的分布式解決方案也好，包括我們的分布式訪問層的解決方案也好，可能有些場景還真的是無法應對的。我們其實也在探索，隨著生態圈和國內技術的逐步成熟，我們也在考慮分布式資料庫技術的探索和引入的事情，同時從另外一個角度來說，在現在這種國際的關係形勢下，需要做一些技術的儲備，有自主支撐下來的能力。
【免責聲明：CSDN本欄目發布信息，目的在於傳播更多信息，豐富網絡文化，稿件僅代表作者個人觀點，與CSDN無關。其原創性以及中文陳述文字和文字內容未經本網證實，對本文以及其中全部或者部分內容、文字的真實性、完整性、及時性本網不做任何保證或者承諾，請讀者僅作參考，並請自行核實相關內容。凡註明為其他媒體來源的信息，均為轉載自其他媒體，轉載並不代表本網贊同其觀點，也不代表本網對其真實性負責。您若對該稿件由任何懷疑或質疑，請即與CSDN聯繫，我們將迅速給您回應並做處理。】