我們剛才說了,我們在上海到北京有一個災備。數據災備剛開始方案,採用磁碟複製實現災備,這個也是要支出軟體費用,也比較耗錢。第二個是冷備,無法熱切換,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選擇了上容器。上容器解決的兩個技術要點:
第一個就是容器對數據的持久化支持;
第二個是對服務的暴露;
整體我們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年以來,就一直跟蹤著業界很多的分散式資料庫的產品。我們應用級的分散式解決方案也好,包括我們的分散式訪問層的解決方案也好,可能有些場景還真的是無法應對的。我們其實也在探索,隨著生態圈和國內技術的逐步成熟,我們也在考慮分散式資料庫技術的探索和引入的事情,同時從另外一個角度來說,在現在這種國際的關係形勢下,需要做一些技術的儲備,有自主支撐下來的能力。
*聲明:用戶故事來源於DTCC公開演講內容。
對宇宙行的架構解密還不過癮?
歡迎參加 6.15 分散式中間件DBLE用戶見面會,屆時我們會解密更多的技術細節!
推薦閱讀: