全球首例銀行“大型機”下移背后

20年12月24日，在騰訊云資料庫品牌升級的時刻，我們也有幸邀請到了平安銀行技術負責人李中原分享平安銀行分布式資料庫TDSQL實踐，講述全球首例銀行“大型機”下移背后的故事，以下是平安銀行技術負責人李中原的演講全文：

尊敬的各位領導，各位來賓大家下午好，我是平安銀行技術負責人李中原，今天由我代表平安銀行給大家分享平安銀行在分布式系統建設中的經驗，

我的分享有四個部分，第一個是分布式PssS平臺專案，第二個是同城多活的建設，第三個是自動化運維建設，最后是彈性擴容的能力建設，

A+信用卡核心是國內首例由大型機直接下沉到分布式系統的核心系統，信用卡建設的貧訓是在我們一級卡量精準服務，性能突破，成本控制，并且快速創新能力受到底層服務框架制約的情況下，行領導提出需要建設一套全新的能夠實作快速業務交付以及靈活、富有彈性的新的信用卡核心系統，

于是2018年12月份我們開始啟動了信用卡A+專案，整個專案歷時兩年，于今年10月31日正式投產，由于今年雙11規則是從11月1日開始，所以新系統上線的第二天就要承接雙11巨大的壓力，但在這個基礎上我們的系統最侄訓是非常平穩的上線，

基于信用卡建設的貧訓，我們同時建設了一整套的企業級全堆疊式服務化的技術中臺，這個技術中臺主要是PssS層，其中主要的核心組件有大約九個，而資料庫組件可以說是核心中的核心，選用了騰訊云TDSQL資料庫，基于PssS平臺建設的信用卡核心系統，整體的處理能力較原有系統提升了十倍，理論上具有無限橫向擴展能力，而且成本是原系統1/3不到，保守估計未來五年可以節約成本14億，

信用卡A+系統采用單元化DSU分布式架構，基于私有云和PssS平臺建設，應用微服務化，拆分解耦，DSU整體設計邏輯采用按客戶維度進行分片，由GNS去負責決議，完成分片，由DLS實作分片的路由，分片內部實作自包含，所謂自包含就是說我們所有的客戶的業務均可以在單個分片完成，包括交易授權、用卡業務，也包括我們的批量業務，

在DSU之外，為了滿足聚合查詢、分析、歸檔需求，我們同時建設一套sharding版的TDSQL，用于實作聚合的查詢，我們支持全量、增量以及實時的資料同步，同時為了完成資料歸檔，我們建設了一套Hadoop集群作為歸檔資料平臺，

接下來第二部分是同城多活，這是我們反復打磨，不斷極限測驗的一個部分，首先這個是我們DSU部署架構，部署架構中采用了非常典型的兩地三中心，一主五備的架構，它的架構的特點是同城備機強分步，同機房異步，不管什么場景下，包括硬體、軟體各種場景的故障均實作了RPO為0，完成跨機房、強同步和一鍵切換，

第二個是異地容災模式，半小時是在對系統包括資料庫做極限壓力的時候它的最大的一個值，其實我們上線到目前為止兩個月我們觀察到的RTO和RPO的值遠沒有到半小時，其中還包括跑批的時間，

我們的同城多活是建設所有組件的同城多活，我們架構中第一個組件就是LVS，LVS由于本身技術特性不能實作跨資料中心的高可用架構，這個程序中我們跟騰訊的研發團隊反復的溝通協商，最終我們建設了一個LVS Group的概念，通過這樣一個概念把兩個資料中心的VIP系結在一起，對我們的業務提供服務，通過這樣的模式最終實作了LVS的同城多活，

正常業務的訪問場景是業務流量進入系統的時候通過域名訪問我們的資料庫，同城部署的時候應用不需要做任何修改，它的域名和埠都是相同的，由我們的GSLB組件決議，生成不同機房不同的LVS VIP，根據我們的流量權重的配置轉發到相應的網關，再由網關專發到資料庫主庫，讀寫分離場景中轉發到備庫，

這個架構最大的特點有兩個，第一個就是我們所有組件是同城多活的，另外一個我們的應用流量是本地訪問的，最大限度減少了機房之間的訪問互動，

這是我們LVS高可用組，在一個機房整體故障的場景，GSLB會自動檢測到我們的LVS Group不可用并自動啟動切換，切換的時候會直接在域名決議層決議到另外一個機房的VIP，另外一個機房的LVS把流量往下轉發，這個程序中根據我們的測驗，正常基本上是幾秒到十幾秒就可以完成，

還有一個場景就是我們的PROXY在一個機房完全宕掉的情況下，GSLB監測到PROXY在整個機房不可用的情況把域名切到另外一個機房，

分布式自動運維的建設，分布式資料庫我個人覺得在我們運維和建設程序中可能最大的難點是它的數量特別龐大，我們對它做運維和建設的程序中可能會面臨管理上難度高，升級替換困難的情況，我們把我們TDSQL相關的組件做這么一個分類，其實它們有機結合在一起的，核心的組件跟業務的訪問造成影響的組件，包括LVS、網關以及TDSQL，它們的升級我們采用滾動的升級方案，

另外的組件包括集群的組件，包括ZK等，它們的不可用對我們的業務本身并沒有影響，但是它可能會影響集群的一些功能，另外就是多源同步，影響到聚合查詢，一些分析報表的情況，所有的這些組件我們都通過集群化，通過滾動升級能夠實作在線的升級和擴容，

自動化運維程序中我們著力打造了一套全鏈路核心的部件，能夠實作一鍵切換，這里強調一下，一鍵切換指的是哪怕不是很熟悉的運維，只要知道我們的規范，按照我們的要求去做就可以直接一鍵完成我們這個切換的操作，主要包含主備的同城切換，測驗的程序中我們也反復在壓測，正常的一個機房之間的切換我們控制在一分鐘以內做完切換，如果希望更快的話可以更快，但是為了避免機房之間雪崩效應，對它的速度有所控制的；單個DSU切換時間四到五秒，除了這些，我們還包括流量的切換，以及強同步不同級別的切換方案，也包括計算資源可以實作一鍵的擴容，另外就是強分布的這種批量的管理和一鍵問題處理能力，

另外就是在做資料庫自身的建設以外，我們也著力建設一些工具，這些工具主要支撐應用以及開發業務對我們系統的訪問，主要包含這樣幾個部分：查詢工具，發布工具、資料比對工具以及容量平臺，

簡單來說，查詢工具因為是多DSU的部署，查詢可能會有查個別DSU或者全量DSU的需求，由于銀行屬性，我們做了一些脫敏限制，在沒有權限的情況下，查到的資料會被我們自動脫敏，

第二部分是發布工具，在DSU尤其是在多DSU的變更程序中，如果由于變更的故障導致業務故障，那這個故障其實是災難性的，因此我們重點打造了我們的發布工具，發布工具中內嵌SQL審核的功能，有相應的風險管控，還提供灰度發布以及發布操作的回滾功能，

另外就是資料比對，因為我們是多DSU灰度發布，程序中有可能個別的DSU出現失敗的情況，因此我們提供了資料比對的工具，

最后還有容量平臺，容量平臺是我們提供了一個公用的平臺，主要給業務，給開發提供容量的管理，趨勢的預測，并可以在我們平臺上實作自動的資料歸檔的功能，

最后，我們來看我們彈性擴容的能力，DSU場景下，我們認為擴容要以防為主，以治為輔，以防為主是指盡量給我們的單個DSU容量設限，正常的情況下給DSU預留一定的buffer，包括對我們的交易以及批量業務做拆分，另外我們也支持進行橫向的擴容，

擴容的場景簡單來說其實有這樣兩個，一個是橫向的擴容，一個是縱向的擴容，當然，我們要盡可能的去避免縱向擴容，但是我們在系統建設程序當中也預留了巨大的縱向擴容的能力，在我們的建設程序中我們單個DSU資料庫實體僅占整機資源的小部分，也就是說我們有能力進行幾倍的擴容，我們的擴容的重點在于DSU橫向擴展，橫向擴展簡單來說就是新加DSU，方案大體是這樣，通過GNS層調整分片的路由規則，由新的路由規則控制我們新增的用戶，以及流量的比例，實作平滑進入到新擴容的DSU，從而實作非常平滑的擴容，

我的分享就到這里結束，感謝大家，

本文由博客一文多發平臺 OpenWrite 發布！

標籤：其它

上一篇：我們，讓9300萬人辦事少跑一趟

下一篇：《王者榮耀》背后的資料秘密