上雲三部曲：集團支付平臺數據架構最佳實踐

 

本文根據張小虎老師在2017年12月3日【DBAplus數據庫年終盤點大會】現場演講內容整理而成。點擊文末連接便可下載PPT~

講師介紹  

中國電信集團支付平臺在2016年作過比較大的動做就是上雲操做。經過上雲操做，咱們完成了公司成立6年來包括上層應用在內的全部硬、軟件架構的大梳理與大調整。這項工做的實質是對現有平臺的一次基於雲計算技術的升級。

 

今天我將和你們分享中國電信集團下屬支付公司這一兩年裏作過的事情，講一些咱們實現的思路及過程，以及一些好玩的例子。

 

分享大綱：

 

1. 上雲以前須要作什麼？

2. 上雲的最終決戰八小時

3. 上雲以後還能再作什麼？

 

1、上雲以前須要作什麼？

 

1、上雲前夕-集團支付平臺兩地三中心總體規劃

 

本人目前供職於甜橙金融信息技術部，從事運維及數據庫工做有近7年的時間，在甜橙金融上雲的過程當中，除了機房設計外，咱們在數據庫層面上採用了一些業內比較有意思的技術。

 

 

這是咱們當前集團支付平臺的IDC機房區域架構。如圖所示，華東主節點定位爲全部生產應用的主節點，這個節點當前承載了全部的生產業務量。華東副節點的定位主要是作數據級容災。最後是今年正在建設的華南節點，用於公共業務應用級容災。這樣，在建設所有完成後，甜橙金融將造成兩地三中心的機房佈局。在應用容災、數據容災上均可以知足央行對咱們的各項監管要求。

 

2、上雲前夕-咱們存在的問題

 

在此以前，給你們說說上雲以前，做爲一個有傳統行業背景的新晉互聯網金融公司所須要面對的問題。

 

在支付公司發展的6年時間裏，遇到的問題有：

 

 

 

（1）基礎服務邊界不清晰

 

業內定義的基礎服務沒有統一標準，就個人理解來講，全部的網絡、系統、服務器、硬件設施層面均可以盤點爲基礎服務。

 

在上雲以前，支付公司的基礎服務是很是零亂的。由於在業務發展初期，因爲資源分配等緣由，致使了數據系統資源在華東和華南均有分佈，且基於這些數據系統資源的公司各業務系統也相對獨立。因爲缺少標準化和規範化的設計，在業務快速發展過程當中，出現了由基礎服務邊界不清晰、數據庫服務耦合度高、傳統數據架構沒法靈活擴展等引發的各類問題，給咱們的平常運維工做及新增業務需求等帶來了極大的困難和阻力。

 

所以，基礎環境的邊界不清晰是在上雲前最急需解決的問題。

 

（2）數據庫服務耦合度過高

 

一個公司從小作到大必定會有架構上的變化，對於架構上的變化，咱們要主動擁抱，這不只體現了一個公司技術上的演進，也體現了公司業務上的發展程度。

 

支付公司在前幾年的發展過程當中處於人力資源比較粗放的發展，那時爲了擴展業務，提升自身品牌的知名度，須要儘快推進產品發佈。所以，過分的資源開銷是必然的。每個應用系統都着急上線，每個應用系統對應着一套數據庫，或者是若干個應用系統對應着一套數據庫。甚至還有多套應用系統使用同一個用戶，這種已經超限的數據庫服務設計也給咱們後續的遷移形成了必定困難。

 

不過，發展過程當中的技術欠債是必需要還的，這也是此次上雲的主要目的之一。

 

（3）Shared Disk架構過分使用

 

咱們小機加存儲的數據庫架構特別多。這種數據庫架構在早期的優勢確實很明顯，好比部署迅速、統一規劃等。但在業務發展中後期，它的缺點就開始逐漸顯現了，如成本高昂、擴展困難、人力迭代等，都不適合互聯網金融業務中快速迭代的發展特色。

 

這種Shared Disk架構的過分使用，使得一些非核心業務逐漸成爲核心業務的累贅。若是一套高端存儲設備的價格在400萬左右，那麼連同小機在內的硬件設備上的開銷就要將近千萬。這對於一些只是存放日誌信息的邊緣應用來講無疑成本巨大。

 

Shared Disk架構還存在設計及佈線繁瑣等弊病。因此個人小機和存儲之間還要架設光交，這樣額外引入的一臺網絡設備會給整個數據庫架構中增長額外的故障點。

 

（4）應用配置的非標準化

 

按照個人理解，上雲就應該是一次標準化和規範化的過程。那麼非標應用會帶來什麼影響呢？A應用和B應用使用的均可能是同一套數據存儲，但應用底層的數據庫鏈接池，一個採用了JDBC，另外一個採用了c3p0。再好比服務的調用上，在改造Dubbo以前，咱們甚至有應用是直接經過F5來作服務轉發。這都是不可想象的。因此，爲全部的應用在配置、服務調用等層面進行標準化改造，是咱們在後續上雲時須要着手解決的另外一個問題。

 

3、上雲前夕-準備工做

 

明確上述的4個問題後，咱們用了近8個月的時間着手去解決它們：

 

（1）明確基礎服務邊界

 

在這個過程當中，咱們在集團內部、支付公司內部經過內部討論，還和行業大牛作過交流，最終生成一套本身的基礎服務邊界規範。除了剛剛提到的，系統、網絡、數據庫、鏈接池的資源也被我定義爲基礎服務。咱們經過各類域劃分、資源劃分，在底層造成了相對統一且相互隔離的基礎服務環境。

 

（2）數據庫服務資源解耦

 

這個階段，咱們先把全部的IP直連方式、DBLINK等所有幹掉，設置內部DNS Server，改由域名進行數據庫服務鏈接。以後，針對全部業務系統作了全面梳理，開始在業務層面進行垂直拆分，根據垂直拆分的結果，最終把業務所屬的數據庫環境解耦掉。讓不一樣的業務只能訪問本身的庫，只能使用本身的用戶。

 

（3）「部分」去存儲

 

無論怎樣，Shared Disk架構仍是有優勢的，只是看用在什麼地方。所謂技術方案的制定必定要針對相應的業務。所以像價格比較昂貴、性能優異、數據一致性要求高的核心業務能夠繼續使用高端存儲；而像產品層的各類非核心業務則從shared disk架構中剝離，轉而改造爲其它的開源解決方案。

 

（4）標準化改造

 

這個改造過程是對應用、中間件、系統、數據庫進行的全盤改造。包括Dubbo在內的多種技術方案造成了屬於咱們本身的標準，這爲上雲後的DBaaS方案奠基基礎。

 

4、上雲前夕-面臨的困難

 

（1）南京機房的網絡佈局

 

上雲的整個過程當中，最基礎的莫過於風火水電的機房建設以及機房網絡設計。機房的網絡就形如人類的骨架，一個好的網絡設計能夠爲後續的服務搭建打好基礎。若是說整個運維繫統、網絡、數據庫最開始建設的永遠是網絡，沒有好的網絡環境，或者是網絡環境不夠清晰，就至關於人的骨骼出現了偏移，人長得再健壯也沒用，可能我一腳就把你踹倒在地上了。

 

在整個機房建設的過程當中，爲了機房選址問題，咱們的團隊幾乎走遍了半個中國。在機房網絡架構設計中，通過多方調研，咱們開始和思科進行了比較深度的合做。如今，咱們是全球第三個大規模採用了思科ACI網絡技術的公司。咱們成功實施的案例也已經被思科收入到服務案例當中。

 

（2）跨千千米數據同步

 

其次須要解決的是跨千千米數據中心之間的數據同步。這裏的數據同步咱們採用了兩種方式：第一種方式是針對全部的核心業務系統，咱們設計並實現了基於Oracle ADG技術的四層數據同步架構，這種架構在咱們的切換演練中能夠作到數據零丟失，而且切換速度很是快。第二種方式是對非核心的產品層業務，這裏採用的是MongoDB+MySQL的方式，經過咱們本身開發的數據同步工具進行同步。

 

（3）「部分」去存儲後的技術選型

 

最後在「部分」去存儲後的技術選型，咱們把本身開發或者是二次開發的開源軟件所有標準化後投入生產系統。好比咱們在帳單的應用上部署MongoDB，在風控規則中使用Redis Cluster等。經過不一樣的應用場景，使用不一樣的數據庫技術解決方案。而再也不無腦地採用小機加存儲的結構。

 

5、上雲前夕-跨千千米數據同步方案設計

 

在咱們的南京大二層網絡架構搭建時，在設計整個網絡架構當中充分考慮到了可能會出現域劃分不清晰的問題，因此咱們在最初設計時，人爲地拆成了三層，從最底層的數據網、向上的管理網及業務層網。在建設完成後，在網絡環境上已經達到了多租戶隔離效果，咱們把各種資源經過EPG域劃分結合在一塊兒，這樣就從網絡物理層面上完成了資源隔離。

 

 

 

這是當時四層ADG數據同步的拓撲圖，原華南和華東的數據中心經過ADG技術將壓縮後的日誌經過專線把生產數據從B層向南京節點進行轉發。這一過程是持續的。除了原始數據的處理可能須要大量時間外，已經進入同步狀態後，異地機房中的數據近乎徹底同步。這一狀態也是整個割接前夕的標準狀態。

 

 

 

咱們的MySQL同步採用如上方式實現。全部的前端應用做爲生產者將數據變動寫入消息隊列中，各IDC機房中的消費者來負責生產數據的最終持久化。這套工具徹底由咱們自行研發。

 

6、上雲前夕-合理去O，引入更多開源解決方案

 

上雲以後所擁抱的開源解決方案：

 

 

首先MySQL生態圈中，除了各種開源解決方案外，在異地數據同步處理中咱們也使用了一些阿里的開源技術，好比Canal。不過咱們針對Canal有一些二次開發的工做，以令其適應咱們自身的環境。

 

在NoSQL技術中，咱們除了經過自動化運維平臺管理200多套Redis哨兵架構外，還在幾個重點項目裏，採用不一樣大小的Redis Cluster集羣。好比咱們在風控系統裏，就採用了9實機27個節點的大集羣，其平均負載基本上維持在50%以上，機器使用率也較以前有大幅提升。

 

另外，咱們還引入了MongoDB的新技術棧。用來處理一些非結構化的數據展現，如帳單。同時，咱們還自研了集羣管理模塊，實如今自動化運維平臺上對Redis集羣、MongoDB集羣進行一鍵平滑擴縮容。

 

在數據分片中間件上，當前的MyCAT使用比較重，這多是咱們後面要着重解決的問題之一。咱們修復了MyCAT的一些Bug，刪除了一些咱們認爲無用的功能，好比當多個MyCAT同時進行DDL時會出現信號量超時問題等。

 

在上雲遷移後，因爲MyCAT相對於全部的運維人員來講確實太難維護，咱們如今開始着手改造爲Sharding-JDBC。因此在明年的計劃裏，咱們會在Sharding-JDBC作比較多的二次開發。

 

最後是定製化的監控開發，咱們知道面對雲環境，當你對全部資源進行容器化時，你會發現監控系統若是不配合雲環境進行改造的話會很是痛苦。若是每個虛擬出來的容器都要手動添加監控的話，怎麼對外宣稱已經作到平滑擴縮容？

 

因而咱們基於Zabbix已經作了很是多的二次開發。結合Zabbix的Discovery功能，咱們已能夠在虛機劃分或各種服務推送完成後，就能識別所推送的服務類型並自動導入相應的監控模板。當前咱們的監控系統承載的nvps很是大，所監控的實機大概在2000臺左右，虛機的話我就不說了，咱們實虛比大約在1:6。

 

2、上雲的最終決戰八小時

 

 

 

上圖展現的是咱們上雲八小時決戰。整個上雲操做在和各省公司密切溝經過後，最終確認在2016年10月底進行。全部業務給出的真實割接時間只有兩個半小時，完整數據量在150T左右。咱們前期進行了4輪各類狀況下的割接演練，作了這麼多的工做就是爲了在最後2.5小時裏得瑟一下。

 

隨着割接總指揮的一聲令下，操做人員只是點了一下鼠標，就看着進度條一點一點往前推。

 

說實話，數據割接是我最有把握的。咱們自動化平臺裏的實現邏輯通過了屢次討論訂正，簡單來講就是B層斷開到C層。數據的比對是通過了一套很是嚴密的算法。而割接真正結束之後，全部的B層備庫也會同時被斬斷，斬斷後的新C層主庫纔會啓用。

 

整個割接，從開始到結束，個人心裏深處並無太大波瀾，畢竟已準備8個多月了，但過後真正回想起來仍是有些後怕。好比，咱們當時遇到了一個比較緊急的狀況，我的帳戶的核心主庫在當晚割接時有一個節點拉不起來了，在緊急維護了半個小時後，才把它拉起來。在最後覆盤時，發現是由於自動化平臺裏的Bug，把沒有起來的節點文件推錯了。因此，自動化有利有弊，但若是用得好確實是很是好的方式。

 

 

總體遷移全部的生產數據150T左右，大數據平臺在2P左右，遷移數據庫有94套，耗時時間是在2.5小時內。數據校驗採用了自研的方法，完成了1300多套規範審查，整個過程平滑切換，沒有數據丟失。在全部南京應用上雲割接操做之後，咱們不折不扣地擺脫了傳統企業技術上落後捱打的局面。

 

上雲後的效果很快就體現出來了。在2015年上雲以前，每一年的525大促都是全部技術人員的一場噩夢。活動開始時第一小時很正常，第二小時很正常，到第三小時必定死，機器擴不上去，用戶沒法登陸，各類妖孽問題頻出。當時擴容的時間有多長呢？從機房搬機器到機架上線插電，基本按天算。是否是很落後？都已到了2014年、2015年，互聯網IT技術飛速發展，那個時候咱們還在採用這種方式來作，很是落後，因此落後就要捱打，「525」活動只能在最後一刻完成指標。通過這些年咱們技術人員的成長，咱們決定經過技術改變這種情況。在2016年上雲改造後，硬件資源入池時間只有15分鐘，鏡像虛擬好後加入到資源池擴資源，也就是在三五分鐘以內。

 

3、上雲以後還能再作什麼？

 

1、上雲後-集團支付平臺DBaaS體系架構規劃

 

 

這是上雲後咱們規劃的支付平臺DBaaS架構圖，最底層已經作好了IaaS的部分，數據庫服務層是咱們逐漸開始作的，咱們計劃把數據庫服務包裝虛擬化、容器化掉。雲數據安全是和兄弟部門安全中心一塊兒規劃的，他們幫咱們進行全部數據庫層面上的隔離以及審批認證，這是最核心的兩部分。

 

再看右邊的雲數據平臺，已經成功上線大半年時間了，全部的機器管理、資產管理、自動化運維工做所有都在平臺上獲得有效的執行。

 

雲數據服務是咱們2018年的計劃，主要仍是根據支付公司系統內部來作，咱們後面要對各劃小事業羣進行服務計費及流量管理。

 

2、上雲後-集團支付平臺DBaaS技術框架

 

 

這是如今的DBaaS技術架構圖。最上面是門戶界面，會訪問全部DBaaS的Service，底層推送是在用Ansible。DBaaS Service會把資產管理一部分資產信息傳遞給當前資源池的API，若是說全部資源都合適的話就直接經過Ansible Server進行發送。

 

3、上雲後-集團支付平臺數據安全體系

 

 

咱們安全的同事說最好仍是簡單提一下雲安全，由於若是真正對一個公司來說，數據安全是無比重要的。安全同事從底層網絡層的安全開始抓起，把全部的管理網段、業務網段進行了相應配置。

 

真正跟數據庫相關的我認爲主要仍是租戶隔離、軟件隔離、資源隔離這部分，固然還包括備份。由於這些所有隔離好之後，數據服務才變成一個個獨立的個體，你才能把這些服務下發給全部的想要使用的租戶，並且租戶和租戶之間的信息不會有太大誤差。

 

4、上雲後-集團支付平臺數據平臺運維

 

 

這是當前咱們雲平臺的功能展現，我特別截了一下ACI網絡的管理，已經能夠達到徹底自動化。好比如今我想把一臺MongoDB的機器加入到新申請的節點，直接經過管理平臺就能夠把當前這一臺MongoDB的機器劃分到相應的EPG中。全部的虛機擴展包括劃分應用都是採用相似的操做。

 

 

前段時間我在沙龍裏介紹過咱們對MHA的改造時，已經介紹過咱們這塊的工做。那時還只是刷新MHA本身的本地HOST文件。MHA仍是有一點問題，好比說在真正切的時候還會出現日誌追不上的狀況。因此，咱們如今把MHA服務化，增長一層DNS Service。ZK節點會把全部想要知道的域名信息推送給MHA，而後MHA全部底層的監控節點同步當前的信息就能夠了。

 

5、上雲後-服務高可用性-MySQL

 

 

這張圖是如今列的的當前資源申請的流程圖，全部管理員只負責資源入庫，管理員是由工程部門來扮演的，工程部門把全部相應型號的數據庫應用機器所有入池，會有相似的表格根據某一些表格的形式把機器入池。入池之後，會根據不一樣的業務需求推送成相應的服務，好比說有一些是須要部署Java，那就直接把Java給你推送出來。Redis和MongoDB也是同樣的，若是緊急出現要預服務的話資源也能加的上去。

 

之前都是經過工單系統或者是紙質流程來完成資源的申請，如今是直接經過管理門戶打給當前租戶的領導，只要贊成就直接把底層資源劃掉。

 

今天的分享就到這裏。如有疑問和探討，歡迎留言交流。

 

點這裏下載本文乾貨PPT