【51CTO.com原創稿件】導言

　　在互聯網金融快速發展的當下,面對爆發式增長的數據量、高并發海量交易場景，傳統集中式架構的性能瓶頸愈發凸顯。基于此,越來越多的銀行等金融機構近年來逐步關注和應用分布式架構。受??51CTO企業學院??邀請，微眾銀行科技合作支持部架構師劉力在第十一期“技術大咖面對面”中帶來了相關演講《微眾銀行：分布式架構之高可用》。特此整理，以饗讀者。

?[[392589]]??

　　正文

　　我將基于微眾銀行的實踐經驗，把我們的設計思路和做法分享給同業，希望可以和大家交流，共同在金融科技領域取得進步。

　　今天的分享內容主要集中在三個方面：第一，微眾銀行的分布式架構的設計思路；第二，分布式的核心系統是如何來匹配分布式架構的；第三，基于分布式架構的運維管控如何進行。此外，我也會就微眾銀行的分布式架構和微服務之間的關系進行解釋。

　　01 分布式架構的設計思路

　　1.1 整體原則：通過架構實現安全可控，解除對底層技術的依賴

　　建設分布式架構的前提：作為第一家民營互聯網銀行，微眾銀行起步比較晚，沒有太多歷史負擔；出于合規限制，當時獲準的籌建期是六個月，初始資本為30億；定位是普惠金融，因此需要全面降低成本。

　　縱觀這些前置條件，可以看到啟動資金的規模意味著我們在進行IT建設時天生不具備采購IOE的條件，普惠金融的定位在某種角度上意味著成本控制和底部組件的設定基本已確定。基于這一情況，我們從設計角度定義了三個不同原則：

　　其一，堅持技術通用性，不被單一廠商鎖定；

　　其二，極簡主義。盡量采用穩定成熟的技術，不依賴技術性能來完成整體的性能指標；

　　其三，依靠可控的。對一家金融機構的IT部門來說，從架構角度出發，可控的主要是架構規劃以及業務系統相關的程序代碼。其他無法獨立研發完成的部分就通過技術通用性來解決。

　　對于提供技術支持的廠商，我們希望他們的解決方案盡量白盒化，盡可能采用開源組件，開源社區本身具備一定的通用性，廠商自身有比較核心的研發能力。另外需要明確的一點是，如果計劃用X86來完成分布式架構，就要默認你的底層技術和系統是不穩定的。如何通過運維手段來面對和解決這種不穩定性也是需要提前在設計中有一定規劃的。

　　1.2 安全可控的核心技術建設理念：通過XML實現安全可控

　　下面將具體說明為了實現安全可控，我們如何設計搭建分布式架構。

　　主機：一般情況下，由幾十到一百臺X86服務器組成1個固定集群。這樣1個單獨的集群在分布式架構里也可以理解為1個單元。這個服務器集群提供應用計算服務、數據庫服務和存儲服務。我們通常也稱之為數據中心的1個節點，這種單元化的節點在我們內部被命名為DCN（后文將有所提及）。

　　數據庫：我們需要一個基于MySQL，至少是與其高度兼容的數據庫。而這個數據庫的特點在于——設計原則秉持“三幅本強同步”（稍后詳述）；數據放在本地磁盤上，而不依賴存儲；實現自動化的故障監控和恢復。

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

　　1.2.1 數據庫選型：以客戶為單位的分布式松耦合單主多副本強同步架構

　　關于數據庫選型，我們當時選擇的是騰訊TDSQL數據庫。在實踐過程中，我們發現所有分布式架構的設計實質上就需要對你的客群或者業務來進行劃分。

　　傳統銀行的IOE架構，程序基本運行在一、兩臺主機服務器上，數據一致性沒問題，但在需要擴容的時候，更換硬件、數據遷移都極為復雜，閑置和風險都比較高。相對地，很多互聯網企業在數據庫優化中會進行分庫分表，全量的分布式方式會獲得很好的靈活性和擴展性，但數據一致性很難保證，而且金融業務的安全性和穩定性要求比一般的互聯網業務也要高。綜合來看，這兩種模式就是各有千秋，所以我們思考的是能不能設計一種架構結合兩者的特點。

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

　　這樣做的優勢是：按客群拆分計算節點，每一個節點只支持部分客群，有效降低了單節點故障影響面，同時能夠控制運營風險；業務邏輯分散到多個計算節點上去，實現高性能要求；數據層則通過一主兩從的方式來實現數據高度冗余，滿足高可用性要求；我們默認情況下會是以主節點的數據為主，來規避CAP理論的限制。

　　這樣做的負面影響是：需要配套自動化管理工具，降低管理復雜度，提升運維效率；需要健全數據庫技術，實現高效率的數據強同步機制。

　　1.2.2數據中心節點的分布邏輯：通過DCN架構構建全分布式銀行系統

　　微眾銀行的數據中心節點的分布邏輯即：按客戶維度拆分多組DCN，每組DCN只會支持一定容量的客戶，客戶數量增加時復制部署DCN即可，一組DCN會在同城的不同數據中心有三個或三個以上副本。

　　簡單來說，每組DCN就像微眾銀行的1個分行。比如拆出100個節點就相當于開了100家小分行，而這100家小分行任意一個節點出現問題，都不會影響到全量業務或者客群。如此一來，就相當于把所有的業務和客群打散到了所有的分布式的小節點里面去。且每個分布式節點的規格、計算資源和數據庫的定義也是標準的。

　　1.2.3 實踐用例：微眾銀行分布式架構整體邏輯視圖

　　如何進行分布式節點的客群分配呢？我們有一個專門的組件叫GNS（Global Naming Service），是整個以客戶為單位的可控分布的核心。這個組件會在每個用戶進來時自動分配1個GNS編號。這個GNS編號有一定的編寫規則，會為新用戶分配1個分布式節點，以后新用戶相關的業務處理和數據保存基本就會固定在這個節點上。后續業務處理過程中通過查找GNS編碼就會馬上找到用戶所在的節點。如果每個DCN節點的配置都固化下來就非常有利于做橫向擴容。隨著用戶規模增長需要，只要固定地增加DCN節點就可以進行，系統處理能力就可以無限橫向擴展。

　　1.2.4 微眾IDC 2.0架構：同城六中心多活+異地災備

　　當前在微眾銀行IDC2.0的架構中實現同城多活的方法，跟DCN節點的設計也密切相關。首先我們有一個全局的負載均衡機制，業務從外網進入后會被分配到某個數據中心。業務接入后會通過消息通道進行處理，進而訪問到后臺不同的業務應用，最后落入主庫進行所有的寫庫操作。萬一出現問題，不管是外網訪問的問題、應用問題還是數據庫的問題，在IDC故障時，備庫會切換成主庫來承擔數據庫的讀取和寫入。數據庫的切換機制速度極快，因為每筆業務在操作中寫完主庫后會再寫兩個副本，這兩個副本分布在不同的數據中心。這個步驟完成后才會反饋到用戶，繼續下面的業務流程。

　　由此看到，微眾銀行實際上是把同城多活的機制交由數據庫本身的高可用機制來完成。這種做法的優點在于，它并不依賴底層硬件的同步來完成，只用數據庫的機制來進行，大體可以實現RPO等于0。達成這樣一種狀態：業務基本不會發生中斷，但RPO會有秒級切換。

　　1.2.5 通過消息總線路由機制實現高效穩定的同城多活架構

　　如何通過消息總線的路由機制來實現高效穩定的同城多活架構？

　　首先，微眾銀行有一個基于消息總線的分布式架構數據骨干。總線實現系統間通訊解耦。通過總線隔離機制，配合網絡隔離，實現法人間消息流轉控制。總線提供服務端負載均衡、限流、熔斷等保護機制，確保海量交易下服務的穩定性。

　　其次，交易盡量在本地處理。消息路由優先選擇本數據中心內的服務，減少跨數據中心的調用，降低交易延遲。

　　再者，賦予消息隊列靈活的路由尋址能力。使用消息地址定位組件，在系統間調用時提供消息尋址能力，避免應用代碼邏輯和服務部署地址的耦合。

　　最后，嚴格控制消息交換。支持跨法人消息路由，但通過服務治理，嚴格控制權限及策略。默認不可通訊，按需開通消息路由，避免不恰當的調用。

　　02分布式核心設計分享

　　這一部分的主要內容是關于分布式核心系統如何與分布式架構來結合。

　　2.1互聯網銀行微核心分布式特性

　　目前微眾銀行的互聯網核心系統，包括存貸核心、信用卡核心都是完全由微眾銀行自研的。因此我們在做核心系統的分布式時，其實進行了拆分。第一個拆分是我們的核心功能需要是分布式的。第二個是業務特性需要是分布式的。第三個是系統性能也需要是分布式的。

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

　　我們當時在做核心和賬戶體系設計時希望功能能夠實現分布式，因而很早之前我們就對一些核心系統做了功能拆分。舉例來說，我們會把存款核心的邊界縮小到賬目核心和記賬的角度，在這之上的組合交易層，諸如支付、頭寸管理、反欺詐等部分會以單獨的功能來存在。這樣一來，設計產品時在合適的功能里面進行組合即可。換句話說，我們盡量把一些通用性的功能變成服務型的、平臺型的能力。

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

　　2.1.2微核心 – 業務特性的多核心分布

　　基于業務特性的分布式處理也是出于更好地適應業務發展的考量。因為很多系統在訴求方面其實有顯著差異，比如網銀app的常見場景是，客群變化不大，并發數量不大，但要求是能看到全局的產品，給用戶展示更多的內容。但如果是對接微信零錢通這樣的互聯網場景，對用戶來說這就只是一個單一入口，其他產品形態、用戶信息都不是他感興趣的。這個流程的特點就是交易極高頻，但整個流程非常簡單。海量場景下需求總是多樣化的。

　　后來我們發現沒有必要把所有東西都放到一個核心上去。比如存款核心系統，這個核心系統某一個版本的系統就對應某一種業務，比如存款核心2.0可能專門對應通用存款，3.0版本可能對應高頻交易場景，3.1版本可能對應同業之間的合作存款。不同版本的核心對應的是不同的業務產品，從這一層面來說基于業務特性實現了分布式。

　　對于我們來說，互聯網核心可以被拆開，也可以被迭代，也可以成長，也可以消亡。

　　2.1.3基于微核心的技術體系互聯網核心

　　性能的解耦也就是前文提到的，通過DCN節點的方式來做解耦，進而實現其橫向擴張和縱向擴張。總之，從功能到業務特性到性能都可以來實現解耦，因而微眾目前的架構就是，我們的產品要選擇合適的微核心組件，對應到這個產品的交易庫后就可以讓這個產品跑起來，跑起來后可以把所有信息再匯總。每個產品都有自己的交易庫后，這個交易庫最終的數據工具會在行業級的大數據平臺再一次匯總，以供實時查詢、數據統計等需求。

　　一言以蔽之，在構建分布式核心系統的同時要在最后通過大數據平臺采集和匯總數據，來實現銀行視角的管理和滿足監管要求的訴求。

　　2.2 應用級分布式事務實現

　　在沒出現微服務的概念，沒有成熟的框架可以依賴時，我們當時為了保證事務一致性，選擇在賬戶層，即每個互聯網核心里來實現應用級的分布式事務。

　　這個實現邏輯是：服務發起者確保發起的子事務的狀態一致性；服務處理方提供相應的異常處理接口，供調用方在異常狀態下使用；同步異常處理或登記差錯登記表并觸發預警。在交易的處理流程上，盡量先做業務檢查，再做業務處理，降低事務異常的概率。一致性可以通過統一的分布式事務管理中間件來實現，也可以通過應用代碼來實現。

　　03 分布式架構管控工具體系

　　最后簡要介紹一下分布式架構的管控體系。

　　3.1 分布式架構管理運維發展路徑

　　分布式架構對于管理運維帶來了四大挑戰。其一，經驗豐富的運維工程師成本高并依然有出錯的可能；其二，架構規模大，當下微眾銀行管理的服務器已經超過一萬兩千臺了，應用節點更多，如果加上虛機的話可能會更多，此外可能還包括一些容器的管理；其三，7/24不間斷營業對業務連續性有嚴格的要求；其四，分布式核心體系同時運行超過90套核心系統服務全行客戶，版本配置管理，灰度發布等工作量大。這些挑戰對運維的標準化、自動化、智能化提出了更高的要求。

　　3.2 強化運維體系建設，突出自動化智能運維能力

　　我們有一套非常嚴格的運維工具、體系和管理辦法。我們當時最重要的一個標準是——如何保證從架構設計驅動來進行運維管理。這就要求從架構設計開始就要把運維的邏輯考慮進去，而且架構做完設計以后到最終系統上線的運行態要求盡量一致。另外還要遵循這樣四條原則：

　　練好外功。建設面向運維的自動化工具集，提高運維效率，降低人力成本以及人為可能造成的失誤。

　　練好內功。從架構設計驅動運維上線，設計態到運行態的信息流閉環。

　　保證信息的準確性。不單是技術平臺層（IaaS/PaaS）信息的管理，也要結合SaaS層信息，包括系統、服務等信息，確保從設計到運維的落地的一致性。

　　保證信息的準確性。對每項數據明確負責組織，建立數據校驗機制，保證信息的準確性。

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

【51CTO原創稿件，合作站點轉載請注明原文作者和出處為51CTO.com】