1. 程式人生 > >上雲三部曲:集團支付平臺數據架構最佳實踐

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

 

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

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

 

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

 

分享大綱:

 
  1. 上雲之前需要做什麼?

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

  3. 上雲之後還能再做什麼?

 

一、上雲之前需要做什麼?

 

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。

 

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

 

 

 

上圖展示的是我們上雲八小時決戰。整個上雲操作在和各省公司密切溝通過後,最終確認在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分鐘,映象虛擬好後加入到資源池擴資源,也就是在三五分鐘之內。

 

三、上雲之後還能再做什麼?

 

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