【51CTO.com原創(chuàng)稿件】導(dǎo)言

　　在互聯(lián)網(wǎng)金融快速發(fā)展的當(dāng)下,面對(duì)爆發(fā)式增長(zhǎng)的數(shù)據(jù)量、高并發(fā)海量交易場(chǎng)景，傳統(tǒng)集中式架構(gòu)的性能瓶頸愈發(fā)凸顯?；诖?越來越多的銀行等金融機(jī)構(gòu)近年來逐步關(guān)注和應(yīng)用分布式架構(gòu)。受??51CTO企業(yè)學(xué)院??邀請(qǐng)，微眾銀行科技合作支持部架構(gòu)師劉力在第十一期“技術(shù)大咖面對(duì)面”中帶來了相關(guān)演講《微眾銀行：分布式架構(gòu)之高可用》。特此整理，以饗讀者。

?[[392589]]??

　　正文

　　我將基于微眾銀行的實(shí)踐經(jīng)驗(yàn)，把我們的設(shè)計(jì)思路和做法分享給同業(yè)，希望可以和大家交流，共同在金融科技領(lǐng)域取得進(jìn)步。

　　今天的分享內(nèi)容主要集中在三個(gè)方面：第一，微眾銀行的分布式架構(gòu)的設(shè)計(jì)思路；第二，分布式的核心系統(tǒng)是如何來匹配分布式架構(gòu)的；第三，基于分布式架構(gòu)的運(yùn)維管控如何進(jìn)行。此外，我也會(huì)就微眾銀行的分布式架構(gòu)和微服務(wù)之間的關(guān)系進(jìn)行解釋。

　　01 分布式架構(gòu)的設(shè)計(jì)思路

　　1.1 整體原則：通過架構(gòu)實(shí)現(xiàn)安全可控，解除對(duì)底層技術(shù)的依賴

　　建設(shè)分布式架構(gòu)的前提：作為第一家民營(yíng)互聯(lián)網(wǎng)銀行，微眾銀行起步比較晚，沒有太多歷史負(fù)擔(dān)；出于合規(guī)限制，當(dāng)時(shí)獲準(zhǔn)的籌建期是六個(gè)月，初始資本為30億；定位是普惠金融，因此需要全面降低成本。

　　縱觀這些前置條件，可以看到啟動(dòng)資金的規(guī)模意味著我們?cè)谶M(jìn)行IT建設(shè)時(shí)天生不具備采購IOE的條件，普惠金融的定位在某種角度上意味著成本控制和底部組件的設(shè)定基本已確定。基于這一情況，我們從設(shè)計(jì)角度定義了三個(gè)不同原則：

　　其一，堅(jiān)持技術(shù)通用性，不被單一廠商鎖定；

　　其二，極簡(jiǎn)主義。盡量采用穩(wěn)定成熟的技術(shù)，不依賴技術(shù)性能來完成整體的性能指標(biāo)；

　　其三，依靠可控的。對(duì)一家金融機(jī)構(gòu)的IT部門來說，從架構(gòu)角度出發(fā)，可控的主要是架構(gòu)規(guī)劃以及業(yè)務(wù)系統(tǒng)相關(guān)的程序代碼。其他無法獨(dú)立研發(fā)完成的部分就通過技術(shù)通用性來解決。

　　對(duì)于提供技術(shù)支持的廠商，我們希望他們的解決方案盡量白盒化，盡可能采用開源組件，開源社區(qū)本身具備一定的通用性，廠商自身有比較核心的研發(fā)能力。另外需要明確的一點(diǎn)是，如果計(jì)劃用X86來完成分布式架構(gòu)，就要默認(rèn)你的底層技術(shù)和系統(tǒng)是不穩(wěn)定的。如何通過運(yùn)維手段來面對(duì)和解決這種不穩(wěn)定性也是需要提前在設(shè)計(jì)中有一定規(guī)劃的。

　　1.2 安全可控的核心技術(shù)建設(shè)理念：通過XML實(shí)現(xiàn)安全可控

　　下面將具體說明為了實(shí)現(xiàn)安全可控，我們?nèi)绾卧O(shè)計(jì)搭建分布式架構(gòu)。

　　主機(jī)：一般情況下，由幾十到一百臺(tái)X86服務(wù)器組成1個(gè)固定集群。這樣1個(gè)單獨(dú)的集群在分布式架構(gòu)里也可以理解為1個(gè)單元。這個(gè)服務(wù)器集群提供應(yīng)用計(jì)算服務(wù)、數(shù)據(jù)庫服務(wù)和存儲(chǔ)服務(wù)。我們通常也稱之為數(shù)據(jù)中心的1個(gè)節(jié)點(diǎn)，這種單元化的節(jié)點(diǎn)在我們內(nèi)部被命名為DCN（后文將有所提及）。

　　數(shù)據(jù)庫：我們需要一個(gè)基于MySQL，至少是與其高度兼容的數(shù)據(jù)庫。而這個(gè)數(shù)據(jù)庫的特點(diǎn)在于——設(shè)計(jì)原則秉持“三幅本強(qiáng)同步”（稍后詳述）；數(shù)據(jù)放在本地磁盤上，而不依賴存儲(chǔ)；實(shí)現(xiàn)自動(dòng)化的故障監(jiān)控和恢復(fù)。

　　其他技術(shù)：目前基本上是以Linux和KVM為代表的開源技術(shù)的組合，來完成整個(gè)底層的支撐。

　　1.2.1 數(shù)據(jù)庫選型：以客戶為單位的分布式松耦合單主多副本強(qiáng)同步架構(gòu)

　　關(guān)于數(shù)據(jù)庫選型，我們當(dāng)時(shí)選擇的是騰訊TDSQL數(shù)據(jù)庫。在實(shí)踐過程中，我們發(fā)現(xiàn)所有分布式架構(gòu)的設(shè)計(jì)實(shí)質(zhì)上就需要對(duì)你的客群或者業(yè)務(wù)來進(jìn)行劃分。

　　傳統(tǒng)銀行的IOE架構(gòu)，程序基本運(yùn)行在一、兩臺(tái)主機(jī)服務(wù)器上，數(shù)據(jù)一致性沒問題，但在需要擴(kuò)容的時(shí)候，更換硬件、數(shù)據(jù)遷移都極為復(fù)雜，閑置和風(fēng)險(xiǎn)都比較高。相對(duì)地，很多互聯(lián)網(wǎng)企業(yè)在數(shù)據(jù)庫優(yōu)化中會(huì)進(jìn)行分庫分表，全量的分布式方式會(huì)獲得很好的靈活性和擴(kuò)展性，但數(shù)據(jù)一致性很難保證，而且金融業(yè)務(wù)的安全性和穩(wěn)定性要求比一般的互聯(lián)網(wǎng)業(yè)務(wù)也要高。綜合來看，這兩種模式就是各有千秋，所以我們思考的是能不能設(shè)計(jì)一種架構(gòu)結(jié)合兩者的特點(diǎn)。

　　基于這種考慮，我們采用了分布式松耦合架構(gòu)。首先把所有的分布式節(jié)點(diǎn)按客群和業(yè)務(wù)兩個(gè)維度做一次劃分，即每個(gè)數(shù)據(jù)中心的分布式節(jié)點(diǎn)只支持一部分客群，也只支持某一類型的業(yè)務(wù)。其次在數(shù)據(jù)庫層面，我們選擇采用一主兩從的節(jié)點(diǎn)強(qiáng)同步結(jié)構(gòu)，以此來保證數(shù)據(jù)的最終一致性。

　　這樣做的優(yōu)勢(shì)是：按客群拆分計(jì)算節(jié)點(diǎn)，每一個(gè)節(jié)點(diǎn)只支持部分客群，有效降低了單節(jié)點(diǎn)故障影響面，同時(shí)能夠控制運(yùn)營(yíng)風(fēng)險(xiǎn)；業(yè)務(wù)邏輯分散到多個(gè)計(jì)算節(jié)點(diǎn)上去，實(shí)現(xiàn)高性能要求；數(shù)據(jù)層則通過一主兩從的方式來實(shí)現(xiàn)數(shù)據(jù)高度冗余，滿足高可用性要求；我們默認(rèn)情況下會(huì)是以主節(jié)點(diǎn)的數(shù)據(jù)為主，來規(guī)避CAP理論的限制。

　　這樣做的負(fù)面影響是：需要配套自動(dòng)化管理工具，降低管理復(fù)雜度，提升運(yùn)維效率；需要健全數(shù)據(jù)庫技術(shù)，實(shí)現(xiàn)高效率的數(shù)據(jù)強(qiáng)同步機(jī)制。

　　1.2.2數(shù)據(jù)中心節(jié)點(diǎn)的分布邏輯：通過DCN架構(gòu)構(gòu)建全分布式銀行系統(tǒng)

　　微眾銀行的數(shù)據(jù)中心節(jié)點(diǎn)的分布邏輯即：按客戶維度拆分多組DCN，每組DCN只會(huì)支持一定容量的客戶，客戶數(shù)量增加時(shí)復(fù)制部署DCN即可，一組DCN會(huì)在同城的不同數(shù)據(jù)中心有三個(gè)或三個(gè)以上副本。

　　簡(jiǎn)單來說，每組DCN就像微眾銀行的1個(gè)分行。比如拆出100個(gè)節(jié)點(diǎn)就相當(dāng)于開了100家小分行，而這100家小分行任意一個(gè)節(jié)點(diǎn)出現(xiàn)問題，都不會(huì)影響到全量業(yè)務(wù)或者客群。如此一來，就相當(dāng)于把所有的業(yè)務(wù)和客群打散到了所有的分布式的小節(jié)點(diǎn)里面去。且每個(gè)分布式節(jié)點(diǎn)的規(guī)格、計(jì)算資源和數(shù)據(jù)庫的定義也是標(biāo)準(zhǔn)的。

　　1.2.3 實(shí)踐用例：微眾銀行分布式架構(gòu)整體邏輯視圖

　　如何進(jìn)行分布式節(jié)點(diǎn)的客群分配呢？我們有一個(gè)專門的組件叫GNS（Global Naming Service），是整個(gè)以客戶為單位的可控分布的核心。這個(gè)組件會(huì)在每個(gè)用戶進(jìn)來時(shí)自動(dòng)分配1個(gè)GNS編號(hào)。這個(gè)GNS編號(hào)有一定的編寫規(guī)則，會(huì)為新用戶分配1個(gè)分布式節(jié)點(diǎn)，以后新用戶相關(guān)的業(yè)務(wù)處理和數(shù)據(jù)保存基本就會(huì)固定在這個(gè)節(jié)點(diǎn)上。后續(xù)業(yè)務(wù)處理過程中通過查找GNS編碼就會(huì)馬上找到用戶所在的節(jié)點(diǎn)。如果每個(gè)DCN節(jié)點(diǎn)的配置都固化下來就非常有利于做橫向擴(kuò)容。隨著用戶規(guī)模增長(zhǎng)需要，只要固定地增加DCN節(jié)點(diǎn)就可以進(jìn)行，系統(tǒng)處理能力就可以無限橫向擴(kuò)展。

　　1.2.4 微眾IDC 2.0架構(gòu)：同城六中心多活+異地災(zāi)備

　　當(dāng)前在微眾銀行IDC2.0的架構(gòu)中實(shí)現(xiàn)同城多活的方法，跟DCN節(jié)點(diǎn)的設(shè)計(jì)也密切相關(guān)。首先我們有一個(gè)全局的負(fù)載均衡機(jī)制，業(yè)務(wù)從外網(wǎng)進(jìn)入后會(huì)被分配到某個(gè)數(shù)據(jù)中心。業(yè)務(wù)接入后會(huì)通過消息通道進(jìn)行處理，進(jìn)而訪問到后臺(tái)不同的業(yè)務(wù)應(yīng)用，最后落入主庫進(jìn)行所有的寫庫操作。萬一出現(xiàn)問題，不管是外網(wǎng)訪問的問題、應(yīng)用問題還是數(shù)據(jù)庫的問題，在IDC故障時(shí)，備庫會(huì)切換成主庫來承擔(dān)數(shù)據(jù)庫的讀取和寫入。數(shù)據(jù)庫的切換機(jī)制速度極快，因?yàn)槊抗P業(yè)務(wù)在操作中寫完主庫后會(huì)再寫兩個(gè)副本，這兩個(gè)副本分布在不同的數(shù)據(jù)中心。這個(gè)步驟完成后才會(huì)反饋到用戶，繼續(xù)下面的業(yè)務(wù)流程。

　　由此看到，微眾銀行實(shí)際上是把同城多活的機(jī)制交由數(shù)據(jù)庫本身的高可用機(jī)制來完成。這種做法的優(yōu)點(diǎn)在于，它并不依賴底層硬件的同步來完成，只用數(shù)據(jù)庫的機(jī)制來進(jìn)行，大體可以實(shí)現(xiàn)RPO等于0。達(dá)成這樣一種狀態(tài)：業(yè)務(wù)基本不會(huì)發(fā)生中斷，但RPO會(huì)有秒級(jí)切換。

　　1.2.5 通過消息總線路由機(jī)制實(shí)現(xiàn)高效穩(wěn)定的同城多活架構(gòu)

　　如何通過消息總線的路由機(jī)制來實(shí)現(xiàn)高效穩(wěn)定的同城多活架構(gòu)？

　　首先，微眾銀行有一個(gè)基于消息總線的分布式架構(gòu)數(shù)據(jù)骨干?？偩€實(shí)現(xiàn)系統(tǒng)間通訊解耦。通過總線隔離機(jī)制，配合網(wǎng)絡(luò)隔離，實(shí)現(xiàn)法人間消息流轉(zhuǎn)控制?？偩€提供服務(wù)端負(fù)載均衡、限流、熔斷等保護(hù)機(jī)制，確保海量交易下服務(wù)的穩(wěn)定性。

　　其次，交易盡量在本地處理。消息路由優(yōu)先選擇本數(shù)據(jù)中心內(nèi)的服務(wù)，減少跨數(shù)據(jù)中心的調(diào)用，降低交易延遲。

　　再者，賦予消息隊(duì)列靈活的路由尋址能力。使用消息地址定位組件，在系統(tǒng)間調(diào)用時(shí)提供消息尋址能力，避免應(yīng)用代碼邏輯和服務(wù)部署地址的耦合。

　　最后，嚴(yán)格控制消息交換。支持跨法人消息路由，但通過服務(wù)治理，嚴(yán)格控制權(quán)限及策略。默認(rèn)不可通訊，按需開通消息路由，避免不恰當(dāng)?shù)恼{(diào)用。

　　02分布式核心設(shè)計(jì)分享

　　這一部分的主要內(nèi)容是關(guān)于分布式核心系統(tǒng)如何與分布式架構(gòu)來結(jié)合。

　　2.1互聯(lián)網(wǎng)銀行微核心分布式特性

　　目前微眾銀行的互聯(lián)網(wǎng)核心系統(tǒng)，包括存貸核心、信用卡核心都是完全由微眾銀行自研的。因此我們?cè)谧龊诵南到y(tǒng)的分布式時(shí)，其實(shí)進(jìn)行了拆分。第一個(gè)拆分是我們的核心功能需要是分布式的。第二個(gè)是業(yè)務(wù)特性需要是分布式的。第三個(gè)是系統(tǒng)性能也需要是分布式的。

　　2.1.1微核心 – 基于核心功能的分布式

　　我們當(dāng)時(shí)在做核心和賬戶體系設(shè)計(jì)時(shí)希望功能能夠?qū)崿F(xiàn)分布式，因而很早之前我們就對(duì)一些核心系統(tǒng)做了功能拆分。舉例來說，我們會(huì)把存款核心的邊界縮小到賬目核心和記賬的角度，在這之上的組合交易層，諸如支付、頭寸管理、反欺詐等部分會(huì)以單獨(dú)的功能來存在。這樣一來，設(shè)計(jì)產(chǎn)品時(shí)在合適的功能里面進(jìn)行組合即可。換句話說，我們盡量把一些通用性的功能變成服務(wù)型的、平臺(tái)型的能力。

　　可以看到，這個(gè)設(shè)計(jì)思路跟微服務(wù)的邏輯非常相像。實(shí)際從服務(wù)和分布上來講，微眾銀行內(nèi)部已經(jīng)非常接近于用微服務(wù)的邏輯在建設(shè)所有的系統(tǒng)和子系統(tǒng)，只不過現(xiàn)在的這些系統(tǒng)間的通訊是通過消息隊(duì)列來完成的。至此我們可以說已經(jīng)做到了基于功能的分布式。

　　2.1.2微核心 – 業(yè)務(wù)特性的多核心分布

　　基于業(yè)務(wù)特性的分布式處理也是出于更好地適應(yīng)業(yè)務(wù)發(fā)展的考量。因?yàn)楹芏嘞到y(tǒng)在訴求方面其實(shí)有顯著差異，比如網(wǎng)銀app的常見場(chǎng)景是，客群變化不大，并發(fā)數(shù)量不大，但要求是能看到全局的產(chǎn)品，給用戶展示更多的內(nèi)容。但如果是對(duì)接微信零錢通這樣的互聯(lián)網(wǎng)場(chǎng)景，對(duì)用戶來說這就只是一個(gè)單一入口，其他產(chǎn)品形態(tài)、用戶信息都不是他感興趣的。這個(gè)流程的特點(diǎn)就是交易極高頻，但整個(gè)流程非常簡(jiǎn)單。海量場(chǎng)景下需求總是多樣化的。

　　后來我們發(fā)現(xiàn)沒有必要把所有東西都放到一個(gè)核心上去。比如存款核心系統(tǒng)，這個(gè)核心系統(tǒng)某一個(gè)版本的系統(tǒng)就對(duì)應(yīng)某一種業(yè)務(wù)，比如存款核心2.0可能專門對(duì)應(yīng)通用存款，3.0版本可能對(duì)應(yīng)高頻交易場(chǎng)景，3.1版本可能對(duì)應(yīng)同業(yè)之間的合作存款。不同版本的核心對(duì)應(yīng)的是不同的業(yè)務(wù)產(chǎn)品，從這一層面來說基于業(yè)務(wù)特性實(shí)現(xiàn)了分布式。

　　對(duì)于我們來說，互聯(lián)網(wǎng)核心可以被拆開，也可以被迭代，也可以成長(zhǎng)，也可以消亡。

　　2.1.3基于微核心的技術(shù)體系互聯(lián)網(wǎng)核心

　　性能的解耦也就是前文提到的，通過DCN節(jié)點(diǎn)的方式來做解耦，進(jìn)而實(shí)現(xiàn)其橫向擴(kuò)張和縱向擴(kuò)張?？傊?，從功能到業(yè)務(wù)特性到性能都可以來實(shí)現(xiàn)解耦，因而微眾目前的架構(gòu)就是，我們的產(chǎn)品要選擇合適的微核心組件，對(duì)應(yīng)到這個(gè)產(chǎn)品的交易庫后就可以讓這個(gè)產(chǎn)品跑起來，跑起來后可以把所有信息再匯總。每個(gè)產(chǎn)品都有自己的交易庫后，這個(gè)交易庫最終的數(shù)據(jù)工具會(huì)在行業(yè)級(jí)的大數(shù)據(jù)平臺(tái)再一次匯總，以供實(shí)時(shí)查詢、數(shù)據(jù)統(tǒng)計(jì)等需求。

　　一言以蔽之，在構(gòu)建分布式核心系統(tǒng)的同時(shí)要在最后通過大數(shù)據(jù)平臺(tái)采集和匯總數(shù)據(jù)，來實(shí)現(xiàn)銀行視角的管理和滿足監(jiān)管要求的訴求。

　　2.2 應(yīng)用級(jí)分布式事務(wù)實(shí)現(xiàn)

　　在沒出現(xiàn)微服務(wù)的概念，沒有成熟的框架可以依賴時(shí)，我們當(dāng)時(shí)為了保證事務(wù)一致性，選擇在賬戶層，即每個(gè)互聯(lián)網(wǎng)核心里來實(shí)現(xiàn)應(yīng)用級(jí)的分布式事務(wù)。

　　這個(gè)實(shí)現(xiàn)邏輯是：服務(wù)發(fā)起者確保發(fā)起的子事務(wù)的狀態(tài)一致性；服務(wù)處理方提供相應(yīng)的異常處理接口，供調(diào)用方在異常狀態(tài)下使用；同步異常處理或登記差錯(cuò)登記表并觸發(fā)預(yù)警。在交易的處理流程上，盡量先做業(yè)務(wù)檢查，再做業(yè)務(wù)處理，降低事務(wù)異常的概率。一致性可以通過統(tǒng)一的分布式事務(wù)管理中間件來實(shí)現(xiàn)，也可以通過應(yīng)用代碼來實(shí)現(xiàn)。

　　03 分布式架構(gòu)管控工具體系

　　最后簡(jiǎn)要介紹一下分布式架構(gòu)的管控體系。

　　3.1 分布式架構(gòu)管理運(yùn)維發(fā)展路徑

　　分布式架構(gòu)對(duì)于管理運(yùn)維帶來了四大挑戰(zhàn)。其一，經(jīng)驗(yàn)豐富的運(yùn)維工程師成本高并依然有出錯(cuò)的可能；其二，架構(gòu)規(guī)模大，當(dāng)下微眾銀行管理的服務(wù)器已經(jīng)超過一萬兩千臺(tái)了，應(yīng)用節(jié)點(diǎn)更多，如果加上虛機(jī)的話可能會(huì)更多，此外可能還包括一些容器的管理；其三，7/24不間斷營(yíng)業(yè)對(duì)業(yè)務(wù)連續(xù)性有嚴(yán)格的要求；其四，分布式核心體系同時(shí)運(yùn)行超過90套核心系統(tǒng)服務(wù)全行客戶，版本配置管理，灰度發(fā)布等工作量大。這些挑戰(zhàn)對(duì)運(yùn)維的標(biāo)準(zhǔn)化、自動(dòng)化、智能化提出了更高的要求。

　　3.2 強(qiáng)化運(yùn)維體系建設(shè)，突出自動(dòng)化智能運(yùn)維能力

　　我們有一套非常嚴(yán)格的運(yùn)維工具、體系和管理辦法。我們當(dāng)時(shí)最重要的一個(gè)標(biāo)準(zhǔn)是——如何保證從架構(gòu)設(shè)計(jì)驅(qū)動(dòng)來進(jìn)行運(yùn)維管理。這就要求從架構(gòu)設(shè)計(jì)開始就要把運(yùn)維的邏輯考慮進(jìn)去，而且架構(gòu)做完設(shè)計(jì)以后到最終系統(tǒng)上線的運(yùn)行態(tài)要求盡量一致。另外還要遵循這樣四條原則：

　　練好外功。建設(shè)面向運(yùn)維的自動(dòng)化工具集，提高運(yùn)維效率，降低人力成本以及人為可能造成的失誤。

　　練好內(nèi)功。從架構(gòu)設(shè)計(jì)驅(qū)動(dòng)運(yùn)維上線，設(shè)計(jì)態(tài)到運(yùn)行態(tài)的信息流閉環(huán)。

　　保證信息的準(zhǔn)確性。不單是技術(shù)平臺(tái)層（IaaS/PaaS）信息的管理，也要結(jié)合SaaS層信息，包括系統(tǒng)、服務(wù)等信息，確保從設(shè)計(jì)到運(yùn)維的落地的一致性。

　　保證信息的準(zhǔn)確性。對(duì)每項(xiàng)數(shù)據(jù)明確負(fù)責(zé)組織，建立數(shù)據(jù)校驗(yàn)機(jī)制，保證信息的準(zhǔn)確性。

　　除了運(yùn)維體系建設(shè)以外，目前在AIOps的領(lǐng)域我們也做了一些工作，包括一些容量預(yù)估和生產(chǎn)異常的根因定位。微眾銀行成立至今的運(yùn)維數(shù)據(jù)都在，我們實(shí)際上可以把這些運(yùn)維數(shù)據(jù)來做一個(gè)建模，以此來識(shí)別一些異常的定位和做一些根因的分析。目前來看，多層AI算法模型識(shí)別的準(zhǔn)確率可以達(dá)到90%以上，而根因定位準(zhǔn)確率也接近70%，都可以用來減輕人為運(yùn)維的壓力。

【51CTO原創(chuàng)稿件，合作站點(diǎn)轉(zhuǎn)載請(qǐng)注明原文作者和出處為51CTO.com】