銀行業(yè)務中臺這么搞，新產(chǎn)品上線提速60%

黎慧劍

湖南三湘銀行中臺管理部總經(jīng)理助理

• 銀行應用架構師，具有12年銀行科技從業(yè)經(jīng)驗；

• 曾從事核心系統(tǒng)、支付結算、營運管理、國際結算、金融市場、理財、BI等多個銀行業(yè)務領域的應用研發(fā)及架構設計工作，主導并完成三湘銀行中臺架構的規(guī)劃設計并實施落地。

前言：什么是中臺？

開始正題之前，首先要討論下什么是中臺。按網(wǎng)上搜集到的信息，有些人說中臺是技術中臺，像微服務開發(fā)框架、Devops平臺、PaaS平臺，容器云之類的；有些人說中臺就是微服務業(yè)務平臺，像最常見的什么用戶中心、訂單中心，各種微服務集散地，叫做”業(yè)務中臺“；還有人說中臺是組織的事情，組織架構有調(diào)整的話， 也可以叫”組織中臺“；也有人說中臺是一種思想，一種體系，可以快速聚合后臺的數(shù)據(jù)與能力。因此不同的人對中臺有不同的理解。

在三湘銀行去年做中臺項目的時候，我們在網(wǎng)上找到了一個定義：中臺是企業(yè)級能力復用平臺。這是我們?nèi)ツ瓯容^認同的概念，理由是：

• 企業(yè)級定義了中臺的范圍，區(qū)分開了單系統(tǒng)的服務化與微服務；

• 能力定義了中臺的主要承載對象，能力的抽象解釋了各種各樣中臺的存在；

• 復用定義了中臺的核心價值，傳統(tǒng)的平臺化對于易復用性并沒有給予足夠的關注，中臺的提出和興起，讓人們通過可復用性將目光更多的從平臺內(nèi)部轉換到平臺對于前臺業(yè)務的支撐上；

• 平臺定義了中臺的主要形式，區(qū)別于傳統(tǒng)的應用系統(tǒng)拼湊的方式，通過對于更細力度能力的識別與平臺化沉淀，實現(xiàn)企業(yè)能力的柔性復用，對于前臺業(yè)務更好的支撐。

在去年我們主要使用此定義描述對中臺的理解。

但是上面這些概念是否能真正解釋中臺？在中臺項目完成后，我又重新做了思考。如果按照上面的定義，并不能完全清晰說明什么是中臺。因為傳統(tǒng)的SOA架構、微服務架構、標準化和平臺化的一些改造都可稱之為”中臺“，所以中臺的概念感覺還不是太清晰。

我們看一個中臺的演變示例，它是參考了阿里架構的演變。假設有一家電商公司，一開始創(chuàng)建了中間藍色這塊食品電商平臺，實現(xiàn)了一些訂單、商品、用戶、支付的功能。食品電商平臺對應的業(yè)務部門是食品業(yè)務部。

后來隨著公司業(yè)務發(fā)展，又成立了藥品業(yè)務部，通過復制食品電商平臺的模式創(chuàng)建了對應的藥品電商平臺，其實這個新平臺用到的功能類似于食品電商平臺。但由于這兩個平臺售賣的貨物存在差異，兩個平臺并沒有結合。公司再大點，就汽車電商平臺。最后，三個平臺各自獨立發(fā)展自己的服務架構和內(nèi)部的業(yè)務管理。

在支付功能層面，這個公司的不同電商平臺可能會跟不同的支付機構進行合作來實現(xiàn)交易功能。三個電商平臺都有對應的用戶管理和支付功能。由于三者處于競爭關系，導致支付通道不能實現(xiàn)統(tǒng)一。

基于這些問題，公司不得不開始建中臺。把三個電商平臺負責用戶管理的人力集中起來，成立用戶拓展部，創(chuàng)建起用戶中臺，實現(xiàn)用戶的管理和營銷功能；同理公司又成立了支付結算部，創(chuàng)建支付中臺。當公司建立起用戶中臺和支付中臺，它的用戶管理和支付管理能力就能統(tǒng)一起來，整合了資源，這就是中臺的大致的演變示例。

根據(jù)這個示例我提出了一個新中臺概念，中臺是基于企業(yè)資源整合的需要，通過運營模式變革、組織架構調(diào)整、IT架構重構等方式形成的企業(yè)級服務復用能力。

• 中臺的戰(zhàn)略目標是實現(xiàn)企業(yè)資源整合；

• 中臺的能力體現(xiàn)在企業(yè)級的能力復用；

• 中臺的實現(xiàn)手段是運營模式變革、組織架構調(diào)整、IT架構重構，且運營模式變革是重點；

• 中臺可以解決一些問題：突破組織壁壘，不會因為組織間的競爭關系導致資源只能服務某一個部門；統(tǒng)一公司內(nèi)部資源，實現(xiàn)資源共享；快速支持業(yè)務創(chuàng)新。

一、為什么建中臺？

講完中臺的概念，我們想想銀行為什么要建中臺。

大部分銀行的組織架構和圖類似，銀行組織架構本身已經(jīng)區(qū)分出前中后臺的體系：像營業(yè)部、分支行、金融市場部等做具體對客業(yè)務拓展的部門屬于銀行前臺部門；對于一些做業(yè)務管理和產(chǎn)品設計的部門，像風險管理部、信貸審批部屬于銀行的中臺部門；而銀行內(nèi)部的管理機構，像辦公室、人力資源部等服務于銀行經(jīng)營的部門則屬于銀行的后臺部門。

再看看傳統(tǒng)銀行的IT架構設計。最上面的是銀行的渠道端，就是對客部分的系統(tǒng)和一些整合服務平臺；中間部分屬于銀行金融產(chǎn)品運營類的系統(tǒng)，由于銀行的金融產(chǎn)品種類特別多，所以對應系統(tǒng)也非常多；在后臺，會有銀行核心系統(tǒng)，包括互聯(lián)網(wǎng)核心系統(tǒng)、銀行核心系統(tǒng)和賬戶系統(tǒng)；最下面的是BI類的系統(tǒng)。從架構圖可以看出，銀行的系統(tǒng)數(shù)量非常之多。就拿三湘銀行這樣小的銀行來講，系統(tǒng)數(shù)量其實也有140多個。

正因為銀行IT系統(tǒng)數(shù)量眾多，通常銀行都會存在以下幾個問題：

• 能力重復建設：不同系統(tǒng)基礎能力重復建設，例如客戶信息管理、賬戶管理,新建系統(tǒng)或優(yōu)化規(guī)則時造成整體成本的浪費和項目周期的增加；

• 系統(tǒng)調(diào)用復雜：新產(chǎn)品的實施會涉及多個關聯(lián)系統(tǒng)共同改造，導致改造成本高且實施周期長；

• 產(chǎn)品/賬戶/交易/核算緊耦合：產(chǎn)品與賬號、交易與核算的處理放在同一個模塊中實現(xiàn)，當需要產(chǎn)品支持不同的賬號類型、交易需支持不同核算規(guī)則時，則必須通過修改代碼邏輯或接入相應的新系統(tǒng)才能實現(xiàn)相應功能；

• 架構復雜難以重構：調(diào)整架構所需的成本、周期、業(yè)務影響和風險，因此多數(shù)采取局部優(yōu)化的方式，難以一次性完成整體架構重構。

從推出一個全新產(chǎn)品的實施周期來看，銀行跟新興互聯(lián)網(wǎng)公司會有不少差距。金融科技公司一般在1個月以下，傳統(tǒng)商業(yè)銀行通常要3個月以上，大行可能需要半年到一年時間。

到這里我們已經(jīng)看出為什么銀行要建業(yè)務中臺，其實銀行建業(yè)務中臺的驅動力不是來自業(yè)務部門。對于商業(yè)銀行來說，它的業(yè)務運營和組織架構本身就是前中后臺的模式，本身就切合中臺的設計理念。業(yè)務部門對中臺的建設并沒有太急迫的需求，動力不足，即使不建中臺，其業(yè)務的流轉還算順暢。實際上銀行的中臺項目的發(fā)起都是由科技驅動力為主。隨著互聯(lián)網(wǎng)金融競爭加劇，業(yè)務對需求的響應時間要求逐漸向互聯(lián)網(wǎng)企業(yè)看齊。而傳統(tǒng)銀行應用架構難以支持這種快速響應、快速上線的改變，因此科技部門迫切期望通過中臺項目改變IT的交付效率，這就是銀行建中臺最大的驅動力。

二、銀行業(yè)務中臺架構設計

對于中臺的建設，會有很多種不同的設計。主要以三湘銀行中臺設計為示例供大家參考。

首先我們講下建業(yè)務中臺要解決的問題。銀行建中臺最大的問題主要解決新產(chǎn)品上線成本高、周期長這兩個問題。

該圖是銀行某個簡單產(chǎn)品的流轉示意圖，左邊是渠道系統(tǒng)，中間兩個是產(chǎn)品系統(tǒng)A和產(chǎn)品系統(tǒng)B，負責提供產(chǎn)品的服務；右邊是銀行賬戶類的系統(tǒng)，像傳統(tǒng)核心和互聯(lián)網(wǎng)核心，還有涉及第三方支付系統(tǒng)。大家可以看到，我們?nèi)绻鲆粋€產(chǎn)品的購買，渠道系統(tǒng)要對接到每個產(chǎn)品系統(tǒng)來實現(xiàn)產(chǎn)品的展示，以及發(fā)起一個產(chǎn)品的購買交易。通常銀行會把一些產(chǎn)品的扣款，以及支付的一些功能落在產(chǎn)品系統(tǒng)上，由產(chǎn)品系統(tǒng)去對接銀行的核心，以及銀行相應的支付系統(tǒng)實行資金扣劃。

每創(chuàng)建一個產(chǎn)品，每個渠道系統(tǒng)要實現(xiàn)同樣的一套接口對接?？磮D右邊列出了主要的五個接口，實際上真實情況下接口數(shù)量會比圖中的更多。

對于產(chǎn)品系統(tǒng)來說，除了要提供渠道系統(tǒng)要訪問的接口以外，還要實現(xiàn)跟行內(nèi)核心系統(tǒng)以及支付系統(tǒng)對接的一些功能。大家可以看到，當產(chǎn)品系統(tǒng)越多，那渠道系統(tǒng)要實現(xiàn)對接的接口數(shù)就越多。

另外產(chǎn)品系統(tǒng)也需要對接行內(nèi)的一些系統(tǒng)，以接入核心系統(tǒng)系統(tǒng)為例，假設我們有兩個核心系統(tǒng)，一是銀行核心，二是互聯(lián)網(wǎng)核心，那么產(chǎn)品系統(tǒng)就要實現(xiàn)兩個核心系統(tǒng)的對接。如果是支付系統(tǒng)的話，每一個支付通道就要接一次，比如人行系就有大額支付、小額支付、超級網(wǎng)銀這三種支付通道，再加上微信、支付寶等等其他第三方支付通道。同時，產(chǎn)品系統(tǒng)還要實現(xiàn)記賬和支付的異常處理的功能，這些規(guī)則如果沒處理好，也會容易造成銀行的短款和賬務問題。這就是為什么銀行在現(xiàn)有傳統(tǒng)架構下創(chuàng)建一個新產(chǎn)品成本高和周期長的原因。建中臺的目的就是為了解決這么一個問題。

那針對上述問題，就有了四個對應的業(yè)務中臺設計目標：

• 快速創(chuàng)新，這是最主要的目標，支持創(chuàng)新產(chǎn)品的快速實施，并能有效降低整體成本和實施周期；

• 系統(tǒng)復用：不推翻現(xiàn)有銀行的整體應用架構，已有系統(tǒng)可以得到有效復用，無需重構現(xiàn)有系統(tǒng)；

• 全業(yè)務支持：支持銀行現(xiàn)有業(yè)務場景在新架構的落地；

• 平滑過渡：支持現(xiàn)有業(yè)務場景的新老架構并行和逐步遷移，實現(xiàn)業(yè)務的平滑過渡，降低中臺建設過程的實施風險。

基于以上四個目標，三湘銀行在去年建業(yè)務中臺的時候，挑選了銀行六個最基本的業(yè)務能力去建對應中臺，也是第一期業(yè)務中臺建設項目中六個最核心的功能：用戶中心、賬戶中心、支付中心、核算中心、交易中心、產(chǎn)品中心。

我們認為業(yè)務中臺的定位為：作為產(chǎn)品系統(tǒng)與渠道系統(tǒng)、賬戶系統(tǒng)、支付系統(tǒng)、核算系統(tǒng)之間的橋梁，利用傳統(tǒng)銀行應用架構中已有的系統(tǒng)，通過標準業(yè)務模型來實現(xiàn)系統(tǒng)間的解耦。這個業(yè)務中臺的理念其實跟平臺標準化、或者SOA的理念很相近，不過還涉及到業(yè)務模型的調(diào)整。所以三湘銀行的業(yè)務中臺跟一個純IT項目還是有所區(qū)別的。

1、用戶中心

首先講用戶中心。那用戶中心要解決的其實有五個問題：客戶管理、生命周期管理、電子渠道互通、客戶信息整合、簽約管理。

設計用戶中心就是要解決這些上面五個問題。

對于用戶中心來說，首先要解決的就是用戶生命周期的問題?？赡艽蠹乙矔幸蓡枺瑸槭裁磿凶鲇脩糁行?，而不把它稱為客戶中心？

在做用戶中心設計的時候，我們有思考過這個問題，實際上用戶和客戶的定義是有所區(qū)別的。在傳統(tǒng)銀行來說，它通常會把開了賬戶的客戶才叫客戶，對其他用戶銀行基本上是不管的。就像游客，銀行基本上是不登記游客的信息。但是互聯(lián)網(wǎng)公司就不一樣了，互聯(lián)網(wǎng)公司會收集游客、注冊用戶、實名用戶、實體用戶的信息進行管理，包括登錄信息、瀏覽信息，目的是為了更好去做客戶的營銷，以及提升客戶體驗。我們把互聯(lián)網(wǎng)公司這套設計模式放到用戶中心里面。

我們要求把從游客開始到實體用戶這四類型的用戶都要管起來。

• 第一類游客，純過來瀏覽，但是沒有做過任何注冊，也沒有留下任何聯(lián)系方式的。但實際游客還有一個關鍵信息我們可以保留，那就是游客的設備號，就是他通過某個手機訪問，后期可以通過這個設備號就能找到這個游客是誰；

• 第二類是注冊用戶，只要他在銀行渠道或系統(tǒng)留下了聯(lián)系方式，像手機號、微信號、郵箱，就認為他是一個注冊用戶，這代表我們可以聯(lián)系到客戶；

• 第三類就是實名用戶，實名用戶顧名思義就是客戶在銀行系統(tǒng)中通過了實名認證，比如通過了身份證認證、人臉識別。這類用戶就叫實名用戶；

• 第四類實體用戶跟傳統(tǒng)銀行的概念一致，就是在銀行開過戶的客戶。

對于這四類用戶，在用戶中心都需要統(tǒng)一進行管理，包括用戶信息管理、用戶行為登記等等。

在用戶中心里面，還會設計統(tǒng)一登錄的功能，比如說用戶能夠在三湘銀行所有的電子渠道上支持用戶名這種方式登錄，或者手機號登錄，或者賬號郵箱登錄，就是在各個電子渠道都是一致的。同時，也可以通過一些設備的驗證方式，比如說人臉登錄、指紋登錄、手勢、掃碼這些登錄方式，也能支持一些第三方的登錄方式，像微信、支付寶授權登錄，這些登錄模式我們的用戶中心上面都能支持。

第二塊就是統(tǒng)一簽約。統(tǒng)一簽約這塊我們會把用戶所有簽約的數(shù)據(jù)，都會在用戶中心有管理起來，同時所有的簽約和解約的動作，都會在用戶中心上支持，這樣保證能在用戶中心查到用戶所有的簽約內(nèi)容，以及實現(xiàn)所有用戶的簽約解約的動作。

第三塊就是統(tǒng)一視圖，把所有跟客戶相關的信息，包括客戶的基本信息，客戶的私有資產(chǎn)、負債的信息，客戶的交易流水還有一些行為，都會統(tǒng)一在用戶中心對外展示。這就是統(tǒng)一視圖的概念。

實際上用戶中心的整體功能包括六部分：

下面這個圖是用戶中心大體功能示意圖，除了剛才介紹的客戶管理、統(tǒng)一視圖等功能以外，還有關聯(lián)管理能力，無非就是把客戶的收藏夾、收款人名冊、收件人地址類似這些信息在所有渠道上共享，這樣使用戶在銀行所有的終端都能獲取到他的信息，提升客戶的體驗。

所以說整個用戶中心等同于傳統(tǒng)銀行幾個系統(tǒng)的集合，一個就是ECIF，其次就是實時CRM，實時能獲取用戶360°的視圖，再加上對于用戶在所有渠道端操作和體驗的渠道支持，這就是對于傳統(tǒng)銀行用戶管理能力的整合。

2、產(chǎn)品中心

產(chǎn)品中心需要解決的問題有以下四點：產(chǎn)品目錄、產(chǎn)品管理、產(chǎn)品查詢、產(chǎn)品上下架。

對于產(chǎn)品中心，我還想解釋幾個概念：

我們做的產(chǎn)品中心就屬于狹義上的產(chǎn)品管理類系統(tǒng)。

上圖是我們產(chǎn)品中心整體的功能架構。

左邊是管理產(chǎn)品的基本屬性，包含產(chǎn)品的基本信息、銷售屬性，比如它在哪個渠道銷售、銷售額；促銷信息，某個產(chǎn)品在某個期限可以打折，或者通過優(yōu)惠券減免手續(xù)費等；收費信息，購買某個產(chǎn)品所需要收取的對應手續(xù)費，類似以上這些就是產(chǎn)品基本信息的管理。

但其實還會存在某些信息需要從各個產(chǎn)品系統(tǒng)上同步過來。相當于產(chǎn)品中心一方面會從傳統(tǒng)核心系統(tǒng)把產(chǎn)品同步回來，另外在產(chǎn)品中心維護好某些產(chǎn)品信息，也可以反向把這些信息同步到產(chǎn)品系統(tǒng)，實現(xiàn)對應的產(chǎn)品的創(chuàng)建。這是產(chǎn)品中心里面產(chǎn)品屬性管理的一個功能。

在產(chǎn)品中心那塊，屬于產(chǎn)品渠道和店鋪的管理，其實在做產(chǎn)品中心設計的時候，就考慮到把產(chǎn)品中心作為統(tǒng)一銷售管理的功能。在產(chǎn)品渠道里面，我們設計了店鋪和機構的概念，在店鋪（機構）底下設置了分類，那對于所有的產(chǎn)品，就會上下架到所有的分類里面。

比如說在分類里面會有一個推薦或熱銷的產(chǎn)品分類，那可以在產(chǎn)品中心進行配置把產(chǎn)品上架到對應的產(chǎn)品分類。那對于渠道系統(tǒng)來說，就能直接看到這些分類上面的產(chǎn)品清單和產(chǎn)品的信息。同時產(chǎn)品中心會實現(xiàn)所有產(chǎn)品信息的緩存，所以它能支持一個高并發(fā)的產(chǎn)品查詢。所以說所有的渠道系統(tǒng)不用再去訪問一個具體的產(chǎn)品運營系統(tǒng)，相當于手機銀行就不用再去訪問核心系統(tǒng)就能獲取對應的產(chǎn)品信息。所有要銷售的產(chǎn)品都從產(chǎn)品中心直接獲取就可以了。

同時產(chǎn)品中心還會有個功能——實現(xiàn)產(chǎn)品的過濾。渠道系統(tǒng)可以把查詢產(chǎn)品對應的渠道和客戶標簽送給產(chǎn)品中心，產(chǎn)品中心可以通過產(chǎn)品所設置的可銷售渠道以及可銷售客群來決定哪些產(chǎn)品能夠在渠道上能看到。

比如說有個客戶登錄了手機銀行，他查看他能購買的產(chǎn)品時候，產(chǎn)品中心就會根據(jù)該客戶能看到的產(chǎn)品返回對應的產(chǎn)品信息，不需要渠道系統(tǒng)再去做對應的產(chǎn)品信息過濾，從而實現(xiàn)千人千面的產(chǎn)品銷售展示功能。

3、核算中心

三湘銀行今年才開始建核算中心，去年建業(yè)務中臺的時候還沒有把核算中心建起來。

這是建核算中心要解決的4個問題。要理解這4個核算中心的問題，先講下銀行的賬務處理流程。其實銀行的賬務處理通常是這樣：客戶在銀行的交易系統(tǒng)上可能產(chǎn)生了一筆交易，這個交易可能是一個產(chǎn)品的購買，那這筆交易實際上會實時的輸送到核心系統(tǒng)來進行產(chǎn)品的扣賬，以及對客戶產(chǎn)品賬戶的入賬。

比如說一個理財產(chǎn)品的購買，客戶就需要實時把他理財購買所花的錢扣下來，同時對客戶生成一個理財產(chǎn)品的分戶，把他所持有的理財產(chǎn)品份額送入他的分戶里面。這部分交易需要實時實現(xiàn)，在我們銀行內(nèi)稱為“客戶賬”，就是跟客戶相關的賬。

其實銀行里面還有另外一部分賬，叫做總賬，就是銀行賬。銀行賬一般來說屬于銀行內(nèi)部使用，用于實現(xiàn)銀行核算報表，資產(chǎn)負債報表等信息。這些賬沒有要求一定要實時，所以通常在銀行里面夜間通過批次的方式進行記賬處理。

所以建核算中心就是為了要解決剛才說的4個問題，分成核算規(guī)則配置、批量過賬、實時過賬3個功能：

這是我們設計核算中心的一個大的流程圖：

大家可以看左邊，當你實時處理一筆交易的時候，交易系統(tǒng)是不需要再產(chǎn)生銀行核算的這部分賬戶。它也不需要關心銀行核算的規(guī)則，只需要實現(xiàn)銀行客戶賬的扣錢，以及產(chǎn)品的入賬。把這個做了就行了。然后交易系統(tǒng)就可以把這個交易數(shù)據(jù)，和它的交易流水直接送到核算引擎里面，那核算引擎會把交易流水的接口映射成銀行內(nèi)部的標準交易格式，再關聯(lián)上配置好的記賬賬套。比如說一筆交易流水會有多少借貸的分錄，以及借貸的金額該怎么計算，這些都是通過對應的配置實現(xiàn)，最終核算引擎會生成具體的銀行賬的借貸分錄，再把該分錄實時送給總賬記賬。這就形成我們實時記賬的功能。

同時對于批量來說，它其實跟實時記賬很像。批量的話，可能該系統(tǒng)通過準實時模式集合了一批的賬戶，或者說每天夜間集合了所有的賬戶，送給核算引擎，核算引擎也是用剛才處理的這些方式，把生成對應的這些交易數(shù)據(jù)快速登錄送到總賬去進行批量計算。這是一個核算大的流程設計。

4、賬戶中心

賬戶中心要解決的問題有四個：賬戶能力重復建設、跨系統(tǒng)記賬復雜、賬戶能力參差不齊、缺乏統(tǒng)一賬戶視圖。

在賬戶中心的設計里面，我們提出了三個概念：產(chǎn)品與賬戶分離、介質(zhì)與賬戶分離、賬戶與賬戶分離。

剛才在講到產(chǎn)品中心的時候，其實講到產(chǎn)品的概念，產(chǎn)品屬于一些運營規(guī)則集合。把產(chǎn)品跟它的賬戶分開有什么好處呢？舉個例子，在傳統(tǒng)的核心系統(tǒng)上，有一個產(chǎn)品已經(jīng)實現(xiàn)了一套規(guī)則，這個規(guī)則假設放在I類戶里是可以用的，但放在II類戶是用不了的。如果要實現(xiàn)同樣的產(chǎn)品規(guī)則，那必須要花時間重新進行開發(fā)，又比如未來遇到積分系統(tǒng)要實現(xiàn)類似的功能，我們又要去積分系統(tǒng)上實現(xiàn)對應的規(guī)則。

如果能把賬戶和產(chǎn)品剝離開，自然而然一套的產(chǎn)品規(guī)則可以應用在不同的賬戶上，就像剛才說的存款取利息的功能就可以放到I類戶也行，II類戶也可以，甚至像一些積分賬戶也能做到對應規(guī)則的處理。

第二塊概念就是介質(zhì)與賬戶分離。這里面主要還是區(qū)分介質(zhì)的概念。介質(zhì)是由銀行提供給客戶，用于證明客戶身份的憑證，介質(zhì)本身不具備金融屬性。真正具備金融屬性的是介質(zhì)所綁定的賬戶。把介質(zhì)跟賬戶區(qū)分開有很多好處，比如說客戶的卡丟了，他換卡只是換介質(zhì)，只需要重新綁定原來的賬號，另外賬戶和介質(zhì)分離后也能支持一個賬戶綁定多個介質(zhì)。

最后一個概念是賬戶與賬戶分離，這其實相當于在設計上把所有的賬戶放在同一個層級中，而賬戶和賬戶之間的關系是通過賬戶中心的合約管理來去實現(xiàn)這些賬戶之間的關系。通過賬戶之間的合約可以實現(xiàn)各種各樣的賬戶層級關系支持，擴展性也會比較高。這也是賬戶中心的設計理念。

我們在設計賬戶中心的時候，也設計了賬戶的基本模型：

這個賬戶基本模型包括了賬戶的基本信息，賬單信息，凍結/止付信息，余額信息，擴展信息，合約關系，介質(zhì)綁定。我們把所有的賬戶都統(tǒng)一抽象為這樣的一個模型，對所有的賬戶都會按照這個模型做管理和訪問。對賬戶來說，我們還會提供一些標準的基礎功能，比如說賬戶的限額管理、合約管理、智能路由、睡眠戶管理這些基本的賬戶功能。

其次我們還把賬戶的基礎功能標準化成幾個最基礎的原子服務：所有賬戶的操作無非都是開戶、銷戶記賬（存/取/沖正）、凍結解凍/止付解止、掛失、查詢、信息變更。這些功能對于所有的賬戶都是一樣的。把賬戶服務都標準化以后，在銀行里面進行賬戶的處理，包括記賬、凍結等操作，都可以沿用這個統(tǒng)一模型去做處理。

對賬戶中心里面剛才說的合約概念，大家可能不清晰。其實我們把合約認定為賬戶和賬戶之間的關系，并且通過合約可以實現(xiàn)賬戶和賬戶之間一個資金流向的管理。這個圖提出了5個賬戶流向的管理：

• 資金流轉合約：進行賬戶之間的資金流向限定，即限制賬戶資金只能向簽訂了合約的賬戶轉入；

• 虛擬子賬戶合約：賬戶上實下虛，將結算戶與虛擬戶結合形成類似會員卡性質(zhì)的資金臺賬管理，虛擬戶的動賬聯(lián)動執(zhí)行結算戶的動賬；

• 虛戶資金歸集合約：賬戶上虛下實，將多個結算戶資金歸集到一個虛擬戶統(tǒng)一展示，結算賬戶的動賬聯(lián)動執(zhí)行虛擬戶的動賬；

• 資金歸集合約：將多個產(chǎn)品戶與結算賬戶關聯(lián)，通過產(chǎn)品戶控制結算賬戶的資金用途，產(chǎn)品戶的動賬聯(lián)動執(zhí)行結算戶的動賬；

• 集團賬戶合約：通過合約將集團公司之間的賬戶關系關聯(lián)起來，供業(yè)務應用進行集團賬戶的操作和管理。

各種各樣的賬戶關系其實都是通過合約類型去支持，而且合約類型未來還可以不斷拓展。

在賬戶中心的建設里面，我們也考慮到成本的問題。不可能說建一個賬戶中心就把原來的賬戶系統(tǒng)全部干掉，把賬戶都遷移過來，所以在建賬戶中心的時候，要考慮賬戶中心本身有賬戶功，能但同時也能實現(xiàn)把原有的賬戶系統(tǒng)直接對接過來。比如說我們要把傳統(tǒng)核心的I類戶接入進來，可以通過一個適配接口把傳統(tǒng)核心接入賬戶中心。

那對于外圍的產(chǎn)品系統(tǒng)，它以后不會再直接去訪問傳統(tǒng)核心，而是所有對賬戶中心操作的處理都通過賬戶中心的標準服務去訪問，來實現(xiàn)對所有賬戶的處理。通過這種模式，可以讓所有渠道、產(chǎn)品系統(tǒng)對賬戶的操作都可以采取同一個模型，而且都通過賬戶中心來實行。那未來假設有某些系統(tǒng)我們要重構的時候，這時候自然而然就可以把對應的賬戶遷移到賬戶中心實現(xiàn)。這個模式可以極大地減少數(shù)據(jù)遷移的成本，以及避免了比較大的實施風險。

5、支付中心

所有銀行都有統(tǒng)一支付的概念。支付中心要解決的問題其實跟統(tǒng)一支付的概念類似：

對支付中心的設計我們提了一些概念：

我們把銀行的I類戶的扣賬也放到支付中心處理，并且將所有涉及的資產(chǎn)的動賬我們都放到支付中心去實現(xiàn)。

以下這個圖就是剛才說的支付中心的大致功能圖。

其實我們把三塊支付、記賬、產(chǎn)品通道都交給統(tǒng)一支付去實現(xiàn)。這個支付模式和我們后面講的支付訂單模式會有關系。支付概念的變化是我們這次做中臺一個比較大的特點。

6、交易中心

交易中心原來在銀行基本不怎么提到，交易中心主要解決的問題有：

那基于剛才那幾個問題，我們在建中臺提到一個訂單的概念，就相當于我們利用了一個電商的訂單模型來去創(chuàng)建銀行的一個交易過程，大家可以看到現(xiàn)在這個圖，是我們交易中心里面的訂單模型。

對于渠道系統(tǒng)來說，它每次發(fā)起一個產(chǎn)品購買行為，其實就是創(chuàng)建了一個訂單，然后呢訂單里面有的信息跟電商很類似，第一會有訂單最基本的信息——訂單日期、幣種、總金額、執(zhí)行參數(shù)等信息；第二個就是產(chǎn)品的交付清單信息——產(chǎn)品信息、購買數(shù)量、支付金額、擴展信息，這個交付清單可以放多個產(chǎn)品在里面；第三個的話就有費用調(diào)整清單，涉及到我在處理這張訂單需要收費或者促銷、優(yōu)惠的調(diào)整，調(diào)整整體上要支付的金額，這個可以通過費用調(diào)整這塊實現(xiàn)；最后就是對于這個訂單通過什么樣的支付工具去進行支付，比如通過I類戶還是II類戶，或者通過第三方的賬戶去支付。可以支持在訂單里放進去多個支付工具，相當于多個支付方式來同時對一張訂單進行支付。

這個就是一個訂單的模型，跟電商的模型是非常類似的。

下面這個圖是一個訂單的處理過程：

一開始在渠道系統(tǒng)，我們會給客戶創(chuàng)建一個訂單，會包含剛才說的支付和交付的信息，然后走到一個支付流程。支付流程也是通過統(tǒng)一支付進行對應的支付動作。支付的內(nèi)容其實可支持很多種類，比如說客戶可以通過資金支付，也可以通過權益支付。比如說積分就是一種權益，代金券也是一種權益。甚至說客戶可以通過持有的產(chǎn)品去支付訂單。比如說客戶手上有一個理財?shù)漠a(chǎn)品，那他可以通過理財產(chǎn)品的份額去支付訂單。當支付成功以后，就到了銀行把資產(chǎn)交付給客戶的過程。

那交付的話，其實跟剛才類似，像貸款類交易，銀行就會把錢交付給客戶；對于某些交易會產(chǎn)生權益的，銀行就會把權益交付給客戶；比如說產(chǎn)品購買，銀行就會把錢交易給客戶。其實大家可以看到支付和交付都是通過統(tǒng)一支付實現(xiàn)，這也是為什么我們剛才提支付中心時候提到三塊：包括記賬、產(chǎn)品、第三方支付，其實都統(tǒng)一放在統(tǒng)一支付，也是這個原因。通過統(tǒng)一支付支持的所有資產(chǎn)動賬類型，可以保證我們整個模型的簡單化。

同時對于訂單模式，我們也做過了一些演練，其實訂單模式在設計里面可以支持銀行所有產(chǎn)品的處理，也包括一些特殊場景。

對于貸款類的交易，也可以通過訂單模型去實現(xiàn)。像我們貸款的放款，這在我們這屬于采購訂單。那客戶支付給銀行的實際上是一筆負債，客戶給銀行支付的你可以理解為一筆借據(jù)，然后銀行交付給客戶的是資金，就把貸款的錢給到客戶。還款情況就是剛好相反。

所以銀行所有業(yè)務都可以基于這個訂單模型去處理。

基于剛才我們講到的六個中心，這個圖就解釋了我們?yōu)槭裁赐ㄟ^這6個中心能夠讓銀行的一些產(chǎn)品都快速上線，然后能夠降低我們開發(fā)的量。

最左邊的渠道系統(tǒng)不會直接跟產(chǎn)品系統(tǒng)產(chǎn)生對接，渠道系統(tǒng)只要需要按照這里面的用戶中心、產(chǎn)品中心、交易中心這三個中心進行一次標準的接口對接，對接完以后不需要再去改造。假設我們現(xiàn)在新建了一個產(chǎn)品系統(tǒng)，產(chǎn)品系統(tǒng)只要按照六個中心的標準接口，實現(xiàn)對應產(chǎn)品信息的同步，實現(xiàn)對應的交付接口，實現(xiàn)對應的核算功能，這時候這個產(chǎn)品系統(tǒng)就能嵌入我們的整個業(yè)務中臺的體系里面。這時候渠道系統(tǒng)就可以原生的訪問到這個產(chǎn)品的功能，實現(xiàn)對應的產(chǎn)品的銷售和運營的管理。所以，整體上要上新一個新的產(chǎn)品特別快。

這個圖算是業(yè)務中臺的一個整體的描述。這里面最大的點就是可以看到，業(yè)務中臺最重要是解決了渠道系統(tǒng)和產(chǎn)品系統(tǒng)解耦的問題。

我們再回顧一下最早時候提的中臺的概念，中臺通過運營模式變革、組織架構調(diào)整、IT架構重構等方式形成的企業(yè)級服務復用能力。在我們這次的業(yè)務中臺建設里面，除了組織架構調(diào)整我們沒有做以外，我們的運營模式也發(fā)生了一些變化。當然這個運營模式指的是IT層面對業(yè)務處理的運營模式。其次也做了一個IT方面架構的重構。所以在這個業(yè)務中臺建設里面，我們其實是通過我們?nèi)齻€模型，貨架模型、訂單模型、支付模型，來實現(xiàn)渠道系統(tǒng)與產(chǎn)品系統(tǒng)的解耦，產(chǎn)品系統(tǒng)只需實現(xiàn)產(chǎn)品規(guī)則，無需處理支付；渠道系統(tǒng)無需改造；中臺業(yè)務系統(tǒng)配置或輕量級改造支持新功能，就可以支持一個產(chǎn)品的新上線。這就是一個業(yè)務中臺建設后的效果。

三、三湘實踐經(jīng)驗分享

講完中臺的整體架構，接下來分享一下三湘銀行在去年建設中臺的大致經(jīng)驗和情況吧。

三湘去年的中臺項目總共建了22個系統(tǒng)，但這22個系統(tǒng)不是全都是業(yè)務中臺，實際上業(yè)務中臺只占了其中的六個系統(tǒng)，其他系統(tǒng)包含渠道中臺、數(shù)據(jù)中臺以及公共服務這些系統(tǒng)。

整體的項目從去年的3月份開始啟動，5月我們完成總體設計，6月完成招標工作，8月就完成了開發(fā)，9月完成測試和上線，10月份完成第二期，算是三湘銀行歷史以來最大的項目。這個項目建設了我們行的業(yè)務中臺，雖然在項目里只占了6個系統(tǒng)，卻是最核心的業(yè)務系統(tǒng)。另外項目也建設了我們行的數(shù)據(jù)中臺、渠道中臺和公共服務，同時我們也跟阿里合作部署了飛天私有云。這中間我們做了很多事情，整體投入相比大行來說不多，但是對于小的銀行來說，這個投入算是特別大的。大家可以通過這個案例可以看到建設中臺并不見得要花特別長的時間和周期，也不見得投入是特別大，同時也不見得一定說需要行方的人員充足情況下才能建。以外包的方式也可以去做一個相應的中臺建設。

但是在這個中臺建設的過程中，確實存在很多問題或者困難，是一步步克服過來的。我有一些經(jīng)驗可以跟大家分享一下：

1、發(fā)起中臺建設項目

業(yè)務部門不會有動力去建設中臺，通常都是由IT部門發(fā)起，那么IT部門要怎么去說服行里面去做中臺的項目呢？當時我們做了幾個事情：

• 第一，我們是聯(lián)合了一些專業(yè)機構共同去開展評估工作。有句話說得好，“外來和尚好念經(jīng)”，找專業(yè)機構可以讓銀行內(nèi)部去信服我們的評估結果。如果是由行方人員評估，那么行里很可能會認為我們是出于做項目的目的而得出的結果。

• 第二，評估的過程中必須要進行高層和業(yè)務的訪談。在這個訪談的過程中，讓高層和業(yè)務理解建中臺能帶來什么好處，建中臺的理念是什么樣的。

• 第三，報行里面去審批，像三湘當時是報了行辦會、董事會匯報批準以后才開始建中臺。

評估環(huán)節(jié)主要出的是兩份報告：第一份報告就是一個應用架構現(xiàn)狀評估。第二份就是應用架構整體的建設方案。這個整體的建設方案實際上就是中臺的整體框架。

2、建立開發(fā)規(guī)范

在建中臺的時候，會涉及到非常多的人，非常多的廠商。中臺為了實行解耦，我們還分拆了很多的功能系統(tǒng)去建設。那對于這么大面積的改動，一定需要一些公共的開發(fā)規(guī)范來去限制大家。不能各做各的，不然很難去整合。在建中臺的時候一定要規(guī)范先行。我們制定了好幾個規(guī)范，而且特別嚴格去實行。

這些都要求整個中臺建設過程中，所有人都必須嚴格執(zhí)行規(guī)范，來保證我們系統(tǒng)建設不會出現(xiàn)偏差。

3、堅持自主設計、嚴守架構定位

這點對于城商行來說有一定的借鑒意義。

在建設中臺的時候我們是一直堅持自主設計。雖然我們當時的人員并不多，但是所有的高階設計都是我們行方自主完成的，并且是行方內(nèi)部通過的。當然過程中也會和跟廠商的人員一起評審，不過最終所有的設計都是由行方的同事提出。

堅持自主完成高階設計，包括功能設計（需求分析）、詳細接口設計，并要求廠商嚴格按照設計進行實施。

廠商的產(chǎn)品可以拿進來，但必須嚴格執(zhí)行由廠商適配我們的設計的要求，而不是我們根據(jù)廠商的產(chǎn)品來調(diào)整設計。這是銀行在建中臺必須明確的做法。如果把設計交給廠商，很容易出現(xiàn)廠商按照原生產(chǎn)品設計，最終出來的不是我們想要的效果。

同時在中臺建設中一定要嚴守架構設計定位。嚴守架構設計中每個系統(tǒng)的功能定位，并按定位落地系統(tǒng)功能，當出現(xiàn)定位模糊的情況快速進行明確和調(diào)整。已經(jīng)明確的定位不接受任何開發(fā)人員的挑戰(zhàn)。不能因為某些開發(fā)人員或者廠商覺得這個定位不合理，我們就會為此放棄定位。

這么短時間能把中臺建設起來，我覺得這兩個堅持是很重要的，這樣到最后系統(tǒng)整合測試的時候才不會出現(xiàn)那么多問題。

4、“架構并行，平滑過渡”

這點是為了說服業(yè)務的。在建業(yè)務中臺過程中，當時我們沒有停止任何的業(yè)務需求，科技部一邊接常規(guī)的業(yè)務需求，一邊在建新的業(yè)務中臺?；谶@種情況，要保證兩種架構是能平滑過渡。為此提出了三點：

• 旁路架構：整體架構不阻斷原有交易，而是在原架構基礎上新增旁路架構，交易在兩個架構上可以正常處理；

• 復用已有系統(tǒng)：盡量復用原有系統(tǒng)功能，原有系統(tǒng)按照中臺標準新增接入接口，并保留原接口，兼容兩套接口模式并行，無需進行數(shù)據(jù)遷移；

• 逐步遷移：按產(chǎn)品逐個分批進行業(yè)務遷移，降低整體遷移的風險，出現(xiàn)問題影響范圍減少。

上面就是我在做業(yè)務中臺時總結出來的關鍵經(jīng)驗，希望能給到大家一些參考。

>>>>

Q&A

Q1：請問中臺建好后，效果達到預期了嗎？

A：三湘的業(yè)務中臺的建設效果基本達到，新產(chǎn)品需求的實施周期平均縮減了60%，業(yè)務中臺5個系統(tǒng)的全部外包開發(fā)人員少于10個人。

Q2：怎么看中臺對中小銀行的價值？

A：中小銀行沒有大行那么足的的網(wǎng)點資源和開發(fā)預算，同時也存在互聯(lián)網(wǎng)金融公司的競爭壓力，只有做到快速響應、低成本才能在競爭中生存，而業(yè)務中臺的方案就是以產(chǎn)品快速上線和降低成本為目標的，對中小銀行應該有實現(xiàn)的價值。

Q3：你們實時數(shù)據(jù)處理這塊，架構是怎么做的？實時計算引擎用的是什么？

A：三湘的實時數(shù)據(jù)處理采取的是OGG（Oracle Golden Gate）+ Kafka + Flink + Oracle/HBase的處理方案，利用OGG數(shù)據(jù)同步功能準實時獲取業(yè)務系統(tǒng)的數(shù)據(jù)變化，同時無需業(yè)務系統(tǒng)配合改造。

Q4：能簡單介紹一下數(shù)據(jù)中臺建設經(jīng)驗？

A：如果按照我的觀點，目前銀行的數(shù)據(jù)能力建設在嚴格意義上并不能稱之為中臺，因為在數(shù)據(jù)運營模式和架構上與傳統(tǒng)BI并沒有太大的區(qū)別，只是將傳統(tǒng)的能力合在一起稱為數(shù)據(jù)中臺。數(shù)據(jù)中臺在數(shù)據(jù)標準、數(shù)據(jù)管控、數(shù)據(jù)倉庫、數(shù)據(jù)應用的開發(fā)模式和架構沒有太大的變化，只是建設前要充分考慮海量數(shù)據(jù)處理、實時數(shù)據(jù)服務的需求，同時一些互聯(lián)網(wǎng)企業(yè)也會將決策引擎納入數(shù)據(jù)中臺的范圍中，所以在數(shù)據(jù)中臺建設上是一個混合型的技術架構，需要充分利用傳統(tǒng)數(shù)據(jù)庫、大數(shù)據(jù)平臺、實時計算等技術特點實現(xiàn)所需的能力。

Q5：用戶中心與ECIF的功能邊界劃分？

A：在三湘的業(yè)務中臺里ECIF的功能是用戶中心的一部分，也就是用戶中心是完全替代ECIF的，具有ECIF的完整功能并擴充了其他用戶相關的功能。

Q6：業(yè)務架構后面會考慮結合微服務嗎？

A：三湘在建設業(yè)務中臺的技術選型上本身就采用了分布式的架構（阿里的SOFA），實際上也可以將每個中心視為一個微服務，只是微服務劃分的粒度比較粗，未來如果要支撐更大的業(yè)務并發(fā)量，會考慮將每個中心的服務能再拆分為更細粒度的微服務。

Q7：請問什么是系統(tǒng)流水號？

A：三湘流水號規(guī)范規(guī)定有3個流水號：統(tǒng)一流水號、系統(tǒng)流水號、接口流水號。統(tǒng)一流水號貫穿交易的全流程，由業(yè)務最前端的系統(tǒng)生成，整改交易流程的各個系統(tǒng)環(huán)節(jié)都必須保持不變；系統(tǒng)流水號（也可以叫業(yè)務流水號），用于每個系統(tǒng)確定交易在自身的唯一性，同一筆交易在當前系統(tǒng)重復處理時的系統(tǒng)流水號不允許改變（例如交易失敗重做），以保證業(yè)務不出現(xiàn)重復；接口流水號在每次接口調(diào)用的時候產(chǎn)生，用于控制網(wǎng)絡上的接口調(diào)用不會重復。

Q8：旁路架構是不是要做很多接口？但是原系統(tǒng)也沒有優(yōu)化呀？

A：業(yè)務中臺方案為了業(yè)務的平滑過渡，要求原系統(tǒng)的業(yè)務處理流程和模式不改變，所以原系統(tǒng)的接口是需要保持不變的；業(yè)務中臺作為旁路架構實際上進行了接口的標準化整合，整個中臺系統(tǒng)對外的標準接口并不多，以記賬接口為例，賬戶中心僅提供了一個標準的通用記賬接口，而原來的核心系統(tǒng)對外提供有十幾個不同類型的記賬接口。

Q9：賬務和核算的區(qū)別是什么？

A：按面對對象不同可以區(qū)分：賬務一般指客戶賬，是銀行客戶需要看到的賬務，需要實時記賬，比如客戶的活期賬戶的資金入賬和扣款、理財產(chǎn)品賬戶的份額增加和減少；核算一般指銀行賬，是銀行自身經(jīng)營管理的會計賬，用于管理銀行內(nèi)部資金及產(chǎn)生資產(chǎn)負債表，銀行賬不被客戶使用，因此無需實時記賬，通常通過夜間批次在總賬系統(tǒng)統(tǒng)一進行記賬處理。

Q10：中臺系統(tǒng)里有哪些開源框架？

A：三湘在中臺建設上使用的是阿里的SOFA分布式框架以及各個合作廠商自身的開發(fā)框架，廠商框架里面實際上也會用到一些開源中間件，考慮到技術風險及當前人員技術能力的限制，在開發(fā)框架上并沒有使用純開源框架。

Q11：除了這六個業(yè)務中臺，還有啥中臺準備做？

A：業(yè)務中臺并沒有限定范圍，只是初期先把最核心的基礎能力形成了業(yè)務中臺的框架，后續(xù)計劃要實現(xiàn)的業(yè)務中臺包括權益中心和營銷中心。

Q12：你們分布式事務、分布式數(shù)據(jù)庫都用了嗎？

A：目前的業(yè)務中臺架構并沒有使用分布式事務（技術不成熟），而是采用了更為穩(wěn)妥的接口層業(yè)務一致性機制，即通過異常業(yè)務邏輯發(fā)起業(yè)務交易沖正保障業(yè)務一致性；沒有使用分布式數(shù)據(jù)庫，僅使用了分庫分表的技術。

Q13：大行的業(yè)務模型更復雜，大型銀行做業(yè)務中臺有什么建議？

A：個人認為無論銀行大小，業(yè)務模型都是類似的，只是大行的業(yè)務審批更復雜，牽涉的業(yè)務部門更多；因此對于大型銀行，在建設業(yè)務中臺更應該考慮風險問題，一次性進行全部業(yè)務的切換對大行來說更不現(xiàn)實，建議采用旁路架構的模式進行業(yè)務的平滑過渡，這樣可以降低風險并減少建設中臺的阻力。

Q14：你們用什么分庫分表？

A：目前使用的是阿里的DBP中間件實現(xiàn)分庫分表，不過聽說阿里已經(jīng)準備放棄掉這個中間件的后續(xù)研發(fā)計劃。

Q15：數(shù)據(jù)中臺和業(yè)務中臺如何互動的？

A：數(shù)據(jù)中臺主要為業(yè)務中臺提供實時的數(shù)據(jù)訪問需求，主要在客戶的統(tǒng)一視圖方面，供渠道系統(tǒng)實時獲取到資產(chǎn)、交易流水等信息；由于數(shù)據(jù)中臺是通過數(shù)據(jù)庫底層抽取數(shù)據(jù)的方式實現(xiàn)的數(shù)據(jù)同步，因此業(yè)務中臺不需要與數(shù)據(jù)中臺進行直接對接，僅用戶中心負責將數(shù)據(jù)中心的用戶視圖相關接口進行封裝并對渠道系統(tǒng)發(fā)布。

免責聲明：本文內(nèi)容由21ic獲得授權后發(fā)布，版權歸原作者所有，本平臺僅提供信息存儲服務。文章僅代表作者個人觀點，不代表本平臺立場，如有問題，請聯(lián)系我們，謝謝！