|
核心業(yè)務(wù)系統(tǒng)是銀行最重要的IT系統(tǒng)，號稱“銀行的心臟”。近幾年銀行核心業(yè)務(wù)系統(tǒng)的規(guī)模急劇擴大，面臨的運行風險、困難和挑戰(zhàn)日益增大。中小銀行核心系統(tǒng)IT架構(gòu)轉(zhuǎn)型，必將面對下面四個問題： 典型問題一：關(guān)于中小銀行核心系統(tǒng)轉(zhuǎn)型的必要性？ 胖核心的模式在目前銀行業(yè)務(wù)發(fā)展過程中有這么幾個很難逾越的障礙： 耦合性太強，賬務(wù)問題對聯(lián)機交易影響太過嚴重。 渠道擴展太快，胖核心的模式導致核心系統(tǒng)本身的擴展性跟不上渠道擴展的趨勢。 賬務(wù)規(guī)則及產(chǎn)品變化，胖核心的模式無法實現(xiàn)靈活性變更，每次變更需要在核心內(nèi)部做手術(shù)，風險很大。 既有巨大的批量業(yè)務(wù)，又有巨大的后臺聯(lián)機業(yè)務(wù)，從基礎(chǔ)架構(gòu)及數(shù)據(jù)庫優(yōu)化都不是太容易的事兒。 對于銀行的核心系統(tǒng)究竟是胖還是瘦，其實從很多年前開始到現(xiàn)在一直在討論，二者在從前的業(yè)務(wù)發(fā)展過程中應(yīng)該說各有利弊，所以采用胖瘦都有。但是隨著信息技術(shù)和互聯(lián)網(wǎng)技術(shù)的發(fā)展，銀行的業(yè)務(wù)模式和業(yè)務(wù)渠道在悄然發(fā)生天翻地覆的變化，面對這些變化，固有的胖核心模式還是遇到很多解決不掉的問題，所以這是核心進行剝離的驅(qū)動力。而且隨著信息技術(shù)的發(fā)展，類似系統(tǒng)間通訊鏈路太長的問題完全可以通過系統(tǒng)設(shè)計和技術(shù)手段來避免。因此，個人覺得胖核心在未來的銀行業(yè)發(fā)展過程中，肯定會需要做一些改造優(yōu)化，賬務(wù)從核心剝離，使得整個系統(tǒng)的模塊兒化、靈活化得以發(fā)展。 典型問題二：關(guān)于中小銀行核心系統(tǒng)基礎(chǔ)架構(gòu)的發(fā)展方向，究竟是分布式還是集中式？ 不同的應(yīng)用架構(gòu)需求，衍生不同的數(shù)據(jù)系統(tǒng)架構(gòu)，這里僅以互聯(lián)網(wǎng)金融支付寶和傳統(tǒng)銀行進行對比： 一，分布式與集中式數(shù)據(jù)庫的分野？ 在業(yè)務(wù)體系上，支付寶和銀行在業(yè)務(wù)邏輯、監(jiān)管方式、數(shù)據(jù)要求上完全不同；業(yè)務(wù)決定技術(shù)，這也造成了不同的技術(shù)路徑。需要強調(diào)的是，盡管兩種不同的技術(shù)路徑，但技術(shù)原理卻是相同的。分布式和集中式數(shù)據(jù)庫各有優(yōu)缺點，也就各有不同的適用環(huán)境。 2002年，麻省理工學院MIT的教授在數(shù)學上證明了CAP理論。在分布式計算（存儲）的架構(gòu)里，由于網(wǎng)絡(luò)引起的時延是必然的（Partition Network Toleration），因此對于一個操作在數(shù)據(jù)一致性（C=Consistency）和數(shù)據(jù)可用性（A=Availability）方面必須取舍一個。許多互聯(lián)網(wǎng)的業(yè)務(wù)類型（電商、搜索引擎等等），可以接受最終的數(shù)據(jù)弱一致性，因此分布式計算模式加數(shù)據(jù)可用的高擴展架構(gòu)成為Web2.0公司的平臺基礎(chǔ)。而對于金融業(yè)需要數(shù)據(jù)實時強一致性的業(yè)務(wù)，采用關(guān)系型商業(yè)數(shù)據(jù)庫來滿足ACID（代表Atomicity原子性、Consistency一致性、Isolation隔離性、Durability持久性，是實現(xiàn)實時強一致性的基礎(chǔ)）也是歷史的正確選擇。 分布式計算、集中式計算不是誰替代誰，而是各有不同的用點。適合不同的業(yè)務(wù)場景需求。互聯(lián)網(wǎng)應(yīng)用確實將分布式計算帶到了新的臺階，但是并沒有突破計算機科學的CAP基本原理。因此有時候需要犧牲數(shù)據(jù)一致性換得處理能力的線形可擴展性。而銀行業(yè)務(wù)需要注重數(shù)據(jù)的實時強一致性采用集中處理，在一個統(tǒng)一的唯一數(shù)據(jù)視圖上進行橫向和豎向的擴展來滿足業(yè)務(wù)的吞吐量要求。所以銀行的架構(gòu)是集中和分布的綜合體。選擇完整性/可用性（C/A）保證數(shù)據(jù)的強一致性事務(wù)處理交易，是銀行在過去的三十幾年的業(yè)務(wù)發(fā)展過程中要求遵循的基本架構(gòu)及編程原則。采用數(shù)據(jù)庫、交易管理中間件從系統(tǒng)級提供的數(shù)據(jù)強一致性，簡化業(yè)務(wù)應(yīng)用的編程使其致力于業(yè)務(wù)功能的實現(xiàn)是銀行過去的最佳實踐。因此，集中式計算體系依然至關(guān)重要。 在支付寶交易中，這種保持數(shù)據(jù)弱一致性非事務(wù)處理交易，采用分布式計算則是最經(jīng)濟的選擇。同理，與銀行核心交易無關(guān)的外圍業(yè)務(wù)也可以采用分布式架構(gòu)，未來銀行的架構(gòu)一定是一種集中式和分布式混合體系。 二，平臺型輕應(yīng)用和縱向重度應(yīng)用，支付寶和銀行的本質(zhì) 從兩者本質(zhì)上看，阿里有著互聯(lián)網(wǎng)企業(yè)的重要特征：業(yè)務(wù)邏輯是平臺型的輕應(yīng)用，即商家賣貨，消費者買貨，阿里本身不涉及貨；支付寶也是消費者和商家之間的買賣并行交易，支付寶本質(zhì)是交易工具，本身不靠資金的多少生存。 而以商業(yè)銀行為代表的金融體系則是靠資金來生存發(fā)展的，它的業(yè)務(wù)邏輯則是典型的重應(yīng)用：比如銀行業(yè)務(wù)從資產(chǎn)負債表的構(gòu)成就主要分為三類：存款、借款、債券等負債業(yè)務(wù)，儲備、 投資、信貸、放款等資產(chǎn)業(yè)務(wù)，以及支付結(jié)算、基金托管、銀行卡、擔保、理財?shù)戎虚g業(yè)務(wù)。因此，銀行一定要做集中式處理，這不是簡單的金額加減問題，要涉及到客戶賬，分戶賬，會計總賬等系列后臺邏輯數(shù)據(jù)的變更，所有的賬務(wù)系統(tǒng)要有相應(yīng)的規(guī)則統(tǒng)一管理。借和貸必須在一個邏輯處理事務(wù)單元實時完成并保證ACID。而阿里的支付借和貸之間是脫鉤的，個人支付寶帳戶的扣款和商戶的支付異步進行。支付往往滯后帳戶扣款。因此僅僅是銀行交易的一半途徑且不遵循復雜的會計體系原則。 因此，兩者的業(yè)務(wù)應(yīng)用場景在本質(zhì)是有區(qū)別的：支付寶只是做了支付這一步，而銀行在支付的背后，需要有整個帳務(wù)邏輯和金融風險管控。后者要求每一步操作，不論是查詢還是交易都必須有可跟蹤的、有時間戳的日志。如果在銀行帳務(wù)系統(tǒng)的處理上采用網(wǎng)上購物這種數(shù)據(jù)弱一致性非事務(wù)處理交易架構(gòu)，錯賬、亂帳的風險會提高，由此產(chǎn)生金融風險、法律糾紛的風險提高。記得在銀行未實現(xiàn)數(shù)據(jù)大集中之前，銀行業(yè)務(wù)對帳的時間就很長，帳務(wù)出現(xiàn)差錯，要追帳，查帳，糾錯的壓力也就相應(yīng)而來。 典型問題三：關(guān)于中小銀行核心系統(tǒng)如何解決互聯(lián)網(wǎng)業(yè)務(wù)遇到一系列挑戰(zhàn)，例如秒殺、快速響應(yīng)、彈性負載等等？ 應(yīng)該說互聯(lián)網(wǎng)的發(fā)展對銀行的業(yè)務(wù)模式和渠道模式起到了很大的推動作用，特別是隨著互聯(lián)網(wǎng)用戶監(jiān)管標準的變化，應(yīng)該說有很大一部分業(yè)務(wù)來自于互聯(lián)網(wǎng)模式。但是這個并不代表互聯(lián)網(wǎng)核心會主導銀行傳統(tǒng)業(yè)務(wù)。對于大部分銀行來講還是輻射本地，有其固有的客戶群體和固有的業(yè)務(wù)模式，更重要的是銀行業(yè)的交易業(yè)務(wù)的賬務(wù)規(guī)則和業(yè)務(wù)標準是不會隨著互聯(lián)網(wǎng)進行完全式的革命。所以傳統(tǒng)的核心可能會隨著時代的發(fā)展存在一些問題，但是并不代表傳統(tǒng)核心系統(tǒng)會消失。無論怎么發(fā)展，互聯(lián)網(wǎng)業(yè)務(wù)是屬于渠道，我們不能做喧賓奪主的事情。 傳統(tǒng)銀行核心系統(tǒng)的生命周期往往在10年左右，甚至更久。一些新興的企業(yè)進入到這個領(lǐng)域，特別是互聯(lián)網(wǎng)金融企業(yè)，快速推出新產(chǎn)品，蠶食銀行的中間業(yè)務(wù)，這也提出來一個問題，我們的后臺是否有一個靈活的架構(gòu)支撐這一需求。銀行后臺API化，服務(wù)化，把它暴露出來，這是一個關(guān)鍵的能力，表現(xiàn)就是業(yè)務(wù)敏捷化。這里也對核心的選擇提出了三個選擇點： 1.單核，構(gòu)建新型的單核系統(tǒng)。 2.雙核，保留傳統(tǒng)核心，構(gòu)建一個獨立的新核心，以滿足新興的需求。 3.無核，沒有絕對的核心，每個模塊各司其職，組件化配置。 但是不管銀行選擇單核，雙核，無核哪種形態(tài)，都需要將目標和自身的情況聯(lián)系起來，需要更細心的分析和摸索，不能一蹴而就，也沒有絕對選項。 對于銀行而言，在構(gòu)建新一代核心系統(tǒng)的時候，需要有更多的考量：簡單的說：看大做小，要看到未來業(yè)務(wù)需求對于核心系統(tǒng)提出的要求，也就是對核心系統(tǒng)提出的要求，比如技術(shù)發(fā)展趨勢，業(yè)務(wù)發(fā)展模式等等，但是也需要結(jié)合銀行自身的情況，自己已有的IT資產(chǎn)情況，IT服務(wù)和運維能力等等來實踐，就是要將夢想照進現(xiàn)實。 典型問題四：關(guān)于中小銀行核心系統(tǒng)如何建設(shè)，應(yīng)該遵循什么樣的決策思路什么樣的方案？ 基礎(chǔ)架構(gòu)層面： 核心系統(tǒng)是銀行承載客戶的賬戶和賬務(wù)業(yè)務(wù)系統(tǒng)，其重要性不言而喻。目前中小銀行“餿核心”架構(gòu)有多種版本，如題。核心系統(tǒng)的業(yè)務(wù)連續(xù)性最關(guān)鍵的還是數(shù)據(jù)庫的安全穩(wěn)定性。前端應(yīng)用可用負載均衡如等高可用方案保障穩(wěn)定性，而數(shù)據(jù)庫的穩(wěn)定性則題上幾種模式采用不同的方案，穩(wěn)定性各有千秋。 1、小型機 X86模式。目前大多數(shù)中小銀行采用的模式，數(shù)據(jù)庫（DB2或者ORACLE）采用小型機，雙機HA模式保障高可用，應(yīng)用則用X86 通過負載均衡方式保障高可用； 2、oracle一體機 X86 架構(gòu)，數(shù)據(jù)庫（oracle）采用其一體機保障高可用，X86服務(wù)器跑應(yīng)用； 3、X86架構(gòu)，其數(shù)據(jù)高可用性采用互聯(lián)網(wǎng)公司（如騰訊、阿里）的分布式數(shù)據(jù)庫，目前微眾銀行采用這種架構(gòu)，其高可用性是基于分布式數(shù)據(jù)庫在軟件層面保障。也有少部分銀行嘗試這種模式； 4、LinuxOne架構(gòu)。近年來IBM力推了基于大機架構(gòu)的開放平臺，這種設(shè)備既有傳統(tǒng)大機的穩(wěn)定性和高吞吐和負載能力，又結(jié)合了開放系統(tǒng)linux的優(yōu)勢，非常適合銀行核心系統(tǒng)類業(yè)務(wù)的運行。 不同模式其要求的資金投入和技術(shù)力量投入不一樣，銀行根據(jù)自己目前核心系統(tǒng)的模式及遷移工作的成本綜合考慮。 業(yè)務(wù)和應(yīng)用層面： 新建核心應(yīng)該還是主要也業(yè)務(wù)驅(qū)動去推進，由上向下，根據(jù)業(yè)務(wù)選擇需要建設(shè)哪些系統(tǒng)。首先第一步要對本行的所有開展的業(yè)務(wù)進行梳理，梳理完后收集業(yè)務(wù)需求。在業(yè)務(wù)需求確定后，可以著手進行核心的選型工作。確定是要做成集中化的“胖”核心，還是交易與賬務(wù)、管理分離的“瘦”核心。（也可以多與兄弟銀行交流學習）選型完之后，可以與各大廠商進行交流。交流完進行POC以及后續(xù)的招標工作。選擇一個實施經(jīng)驗比較豐富的廠商還是很有必要。后續(xù)的工作就是開發(fā)、數(shù)據(jù)遷移、測試、投產(chǎn)等一系列的工作。先從無到有吧，建議在一開始考慮要做核心的時候，要好好做一下數(shù)據(jù)治理（如數(shù)據(jù)標準化、元數(shù)據(jù)管理）與服務(wù)治理（服務(wù)的全生命周期管理）。后續(xù)所有系統(tǒng)的建設(shè)都按照統(tǒng)一標準規(guī)范去執(zhí)行。因為等核心上線后再去做這些會很麻煩。
資料推薦： 銀行技術(shù)架構(gòu)轉(zhuǎn)型思路及LinuxONE銀行行業(yè)解決方案分享 http://www./Document/detail/tid/417031 城市商業(yè)銀行新核心技術(shù)路線選型思考與IBM LinuxONE測試體驗分享 http://www./Document/detail/tid/417009 銀行新核心建設(shè)10大難點問題探討匯總 http://www./Document/detail/tid/416349 |
|
|
