專家視野 | 銀行新核心建設面臨四大風險

本文轉載自IBM認知基礎架構

對金融機構而言，傳統IT建設模式已無法適應互聯網金融業務發展需求與競爭壓力，轉型勢在必行，以銀行為例，新核心建設項目已經在眾多銀行啟動。以下內容來自社區組織的銀行同行線下交流，分享了新核心建設的風險和對策、架構選型分析等，供大家參考。

▶ ▶ 銀行新核心建設中存在哪些具體的風險和問題？針對這些風險和問題有哪些對策？

銀行新核心系統建設是一個巨大的系統工程，不僅僅是一個核心系統的建設，往往通過核心系統的更新，帶動周邊各業務系統的升級和優化，是個巨大的項目群工程。主要有以下風險：

1. 主管力不足。由於核心系統項目群建設工程巨大，協調各部門及內外部資源眾多，需要具有強有力的主管小組指揮和推動。因此，銀行對於核心系統的建設往往是一把手工程， 由行長或者 CIO 親自掛帥總指揮，推動項目進度。
2. 周期過長。核心系統項目群建設是個系統工程，涉及的全行各個業務，同時各個系統也都需要更新對接新的核心系統。因此從產品選型招標、IT 架構規劃規劃、方案設計、需求評審、組織開發、測試評估、試運行、正式上線、上線運維等等，各個環節，環環相扣，都有很大工作量，消耗人力、物力等資源，很容易延期上線。銀行核心系統建設周期往往少則 1 年，多則兩三年。
3. 項目經理經驗和能力不足。 項目經理是核心系統建設項目的靈魂人物（包括甲乙雙方的項目經理），由於核心系統建設的艱巨性和重要性，務必選擇最合適的人擔任項目經理，推進項目有序、可控、健康建設。
4. 耽誤銀行其他業務的發展。銀行新核心系統的建設，鑒於其重要性，往往是頭號工程，集合了全行最優勢的人力資源，信息科技部門的各項資源也重點傾斜向核心系統項目。因此，對於其他項目的關注度和支持力度勢必有所下降， 尤其是目前市場日新月異的創新產品推出，快魚吃慢魚的時代，一旦落後，則後期很難再追趕了。

▶ ▶ 銀行新核心架構應該如何選擇？分布式與集中式？如何評估？

不同的應用架構需求，衍生不同的數據系統架構，這裡僅以互聯網金融支付寶和傳統銀行進行對比：

1，分布式與集中式數據庫的分野

在業務體系上，支付寶和銀行在業務邏輯、監管方式、數據要求上完全不同； 業務決定技術， 這也造成了不同的技術路徑。 需要強調的是，盡管兩種不同的技術路徑，但技術原理卻是相同的。分布式和集中式數據庫各有優缺點，也就各有不同的適用環境。

2002 年，麻省理工學院 MIT 的教授在數學上證明了 CAP 理論。在分布式計算 （存儲） 的架構裡， 由於網路引起的時延是必然的 （Partition Network Toleration），因此對於一個操作在數據一致性（C=Consistency）和數據可用性（A=Availability）方面必須取舍一個。許多互聯網的業務類型（電商、搜索引擎等等），可以接受最終的數據弱一致性， 因此分布式計算模式加數據可用的高擴展架構成為 Web2.0 公司的平台基礎。而對於金融業需要數據實時強一致性的業務，採用關係型商業數據庫來滿足 ACID（代表 Atomicity 原子性、Consistency 一致性、Isolation 隔離性、Durability 持久性，是做到實時強一致性的基礎）也是歷史的正確選擇。

分布式計算、集中式計算不是誰替代誰，而是各有不同的用點。適合不同的業務場景需求。互聯網應用確實將分布式計算帶到了新的台階，但是並沒有突破計算機科學的 CAP 基本原理。因此有時候需要犧牲數據一致性換得處理能力的線形可擴展性。 而銀行業務需要注重數據的實時強一致性採用集中處理， 在一個統一的唯一數據視圖上進行橫向和豎向的擴展來滿足業務的吞吐量要求。 所以銀行的架構是集中和分布的綜合體。選擇完整性/可用性（C/A）保證數據的強一致性事務處理交易， 是銀行在過去的三十幾年的業務發展過程中要求遵循的基本架構及編程原則。採用數據庫、交易管理中間件從系統級提供的數據強一致性， 簡化業務應用的編程使其致力於業務功能的做到是銀行過去的最佳實踐。因此，集中式計算體系依然至關重要。 在支付寶交易中，這種保持數據弱一致性非事務處理交易，採用分布式計算則是最經濟的選擇。同理，與銀行核心交易無關的外圍業務也可以採用分布式架構，未來銀行的架構一定是一種集中式和分布式混合體系。

2，平台型輕應用和縱向重度應用，支付寶和銀行的本質

從兩者本質上看，阿里有著互聯網企業的重要特徵：業務邏輯是平台型的輕應用，即商家賣貨，消費者買貨，阿里本身不涉及貨；支付寶也是消費者和商家之間的買賣並行交易，支付寶本質是交易工具，本身不靠資金的多少生存。

而以商業銀行為代表的金融體系則是靠資金來生存發展的， 它的業務邏輯則是典型的重應用： 比如銀行業務從資產負債表的構成就主要分為三類：存款、借款、債券等負債業務，儲備、 投資、信貸、放款等資產業務，以及支付結算、基金托管、金融卡、擔保、理財等中間業務。 因此， 銀行一定要做集中式處理， 這不是簡單的金額加減問題，要涉及到客戶帳，分戶帳，會計總帳等系列後台邏輯數據的變更，所有的帳務系統要有相應的規則統一管理。 借和貸必須在一個邏輯處理事務單元實時完成並保證 ACID。而阿里的支付借和貸之間是脫鉤的，個人支付寶帳戶的扣款和商戶的支付異步進行。 支付往往滯後帳戶扣款。因此僅僅是銀行交易的一半途徑且不遵循複雜的會計體系原則。

因此，兩者的業務應用場景在本質是有區別的：支付寶只是做了支付這一步， 而銀行在支付的背後， 需要有整個帳務邏輯和金融風險管控。後者要求每一步操作，不論是查詢還是交易都必須有可跟蹤的、有時間戳的日志。 如果在銀行帳務系統的處理上採用網上購物這種數據弱一致性非事務處理交易架構，錯帳、亂帳的風險會提高，由此產生金融風險、法律糾紛的風險提高。記得在銀行未做到數據大集中之前，銀行業務對帳的時間就很長，帳務出現差錯，要追帳，查帳，糾錯的壓力也就相應而來。

▶ ▶ 傳統架構和分布式架構並存情況下， 如何平衡兩種技術體系？

一切看業務需求和特徵，應用系統能採用集群部署的，盡量集群部署，採用分布式架構；應用系統無法集群部署，應用系統對穩定性和性能看重的，採用集中式架構；數據庫系統對性能要求高的，寫比例較高的，盡量採用集中式架構；數據庫對性能要求一般，讀比例較高的，單計算節點無法滿足計算需求的，盡量採用分布式架構部署。

一般業務系統都有多個應用部件，WEB、應用、數據庫等，根據特徵和需求，可採用不同的架構，因此分布式和集中式架構其實是相互融合的，兩種架構是共存的。

▶ ▶ 銀行的傳統架構核心如何向互聯網轉型？是否需要一個傳統核心，一個互聯網核心這種雙核架構？

首先要明確為什麼銀行傳統核心要向互聯網轉型， 傳統核心是面向較為固定和增長趨勢的管道， 網點機構、 終端設備 （包括手機銀行、網銀），為其提供帳務類的服務，帳務類交易有一定的規律性，帳務交易額度較高，動帳交易頻率一般。而隨著互聯網金融業務的快速發展，引入了大量互聯網的帳務類交易，面向的用戶群體也從較為固定轉為非固定，在特殊活動期間，如雙 11，將帶來超高的用戶量和業務並發，而日常的一些業務活動，如秒殺、搶購、一元購、秒貸等等，也將給帳務類交易帶來一些無法預測的瞬時峰值， 所以對傳統的核心考驗不再局限於固定的管道和增長，而是湧入式和爆發式的，傳統核心靠集中式的架構已難以支撐這種業務規模和衝擊。

其次要明確當前向互聯網轉型是否是迫切和有必要的， 還是可以採用逐步過渡的方式去進行。比如引入了互聯網金融類的業務，但涉及到核心帳務類的交易體量和並發度實際並沒有給傳統核心帶來多大的壓力，或者說互聯網金融類的業務大多數還只是查詢類業務，只在互聯網金融系統內部進行，較少的動帳交易在核心系統完成，這時過早的將核心系統向互聯網轉型， 或許會對其他非互聯網類業務造成一定的影響，甚至動作較大，造成其他業務的大量改造。所以向互聯網轉型的過程要平穩，優先保證非互聯網類業務的穩定、正常運行時首要目標。

最後給出我們行的傳統核心轉向互聯網的一個參考， 我們按照互聯網核心的規劃，搭建了一整套互聯網金融系統，但原有生產核心沒有大的變化，涉及帳務類的交易，也是由互聯網金融系統提交生產核心處理。後面運行穩定了 1 年多，再逐步將一些涉及互聯網帳務類的交易從核心中摘除，由互聯網金融系統處理，最後全部涉及互聯網類的交易全部移交， 原核心生產繼續為其他非互聯網類業務提供帳務類服務。

▶ ▶ 面對大量的存量老系統，銀行向互聯網轉型過程中有何更加穩妥成熟的步驟處理這些系統？

採用雙核心架構，存量老系統的非互聯網類業務走原有核心系統，互聯網類業務走新互聯網核心。採取先新搭建完整的互聯網金融核心系統，涉及帳務類的交易繼續由原核心處理，再過渡到逐步將一些涉及互聯網金融的帳務類交易從原核心中剝離， 直至所有交易剝離完成，期間兩套核心並行運行，最後兩套系統同時提供非互聯網類業務和互聯網業務的帳務類交易。

相關方案參考：

銀行IT架構轉型思路及LinuxONE銀行行業解決方案分享

下載地址：

http://www.talkwithtrend.com/Document/detail/tid/417031

以下內容有助於解答閱讀中產生的疑問：

LinuxONE 對於中小銀行來說規模適用性和性價比有什麼優勢？

沒有確定性的體量標準， 從產品角度來說， LinuxONE 有兩款產品，一個入門級，一個企業級。LinuxONE Rockhopper 最高 30 個 CPU，滿足入門級需求，從幾百億到 2000 千億左右規模銀行的大規模整合，核心整合都是適用的，而 LinuxONE Emperor 最高 170 個 CPU，滿足更大規模的體量需求。LinuxONE 的配置粒度可以比較細，比如 1 個CPU 的粒度增加，所以需要根據具體的客戶目前的生產情況和發展預期來決定。

就硬體本身而言，由於製造工藝的複雜度，冗餘設計，整機設計等等原因，LinuxONE 相對於其他小型機硬體平台更貴一些。但在數據中心建設中，硬體只是其中一個很小的部分，圍繞硬體而產生的軟體，機房，電力，網路等方面將會帶來更為龐大的開銷。而 LinuxONE解決方案不但簡化了整體架構，還會帶來總體擁有成本的降低，具有明顯的解決方案性價比。

舉一個真實的城商行客戶案例，該城商行規模接近 2000 億。

以 Oracle 軟體費用為例，生產+災備模式下，3 台 LinuxONE 服務器（ 每 台 12 核 ， 共 36 核 ) ， 整 合10*S822(20c)+3*E850(48c+15*X3850(60c)， 354 個物理小型機 CPU 核，900 個 X86 核，共 1254 個 CPU 核。根據 Oracle 計價模式,Power 和 LinuxONE 按照實際物理核付費，X86按照 0.5 核的比例付費。即 LinuxONE 方案（36 核） ：原方案（804核） 約等於 ≈ 1： 22 ≈ 4.5%， 相當於 LinuxONE 方案能夠節約 95.5%的 Oracle 軟體成本。

採用 LinuxOne 架構如何做到內部安全隔離？

金融傳統的互聯網架構都是安全縱深非常深的架構模式，採用LinuxOne 的話，那麼相當於所有的虛擬機都在一個物理設備內，那麼它是如何做到內部的安全隔離？如何讓客戶可信？

LinuxONE 是商用服務器中唯一獲得 EAL 5+ 最高等級安全認證 （權威的第三方安全認證組織， CC ） ，EAL5+的標準是分區之間的隔離性等同於物理隔離，包括分區間的 CPU, 記憶體，存儲連接，網路連接等都可以物理隔離。在部署物理隔離時，從硬體底層通過微碼來做到物理分區，將 CPU,I/O,記憶體，網路獨占模式而不是共享。技術的可信度首先在於專業認證和市場案例，除了剛才提到的專業認證，我們已經幫助客戶在物理機上做到分區隔離。 比如某城商行客戶將兩個不同的業務網路部署在 LinuxONE 上，同時還有一個開發測試環境，做到 3個不同的物理隔離分區，相當於三台物理服務器。

同樣 CPU 數量的 Linuxone 和 x86 平台相比，性能差距有多大？

單從 CPU 性能比較，應該在 1：4 到 1：8 之間，但因實際場景不同，比如大規模整合，比如核心業務系統的強 I/O 處理業務，異構災備等等，1：20，1：30 甚至更高比例也是有的。

Linuxone 平台是否需要外接存儲？

需要外接存儲，支持類型涵蓋傳統的 SAN 架構，基於 IP 的存儲，軟體定義存儲，以及分布式存儲（比如 Ceph,GPFS）等。