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

黎慧劍

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

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

• 曾從事核心系統(tǒng)、支付結(jié)算、營運(yùn)管理、國際結(jié)算、金融市場、理財(cái)、BI等多個(gè)銀行業(yè)務(wù)領(lǐng)域的應(yīng)用研發(fā)及架構(gòu)設(shè)計(jì)工作，主導(dǎo)并完成三湘銀行中臺架構(gòu)的規(guī)劃設(shè)計(jì)并實(shí)施落地。

前言：什么是中臺？

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

一、為什么建中臺？

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

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

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

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

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

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

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

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

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

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

二、銀行業(yè)務(wù)中臺架構(gòu)設(shè)計(jì)

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

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

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

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

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

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

那針對上述問題，就有了四個(gè)對應(yīng)的業(yè)務(wù)中臺設(shè)計(jì)目標(biāo)：

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

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

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

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

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

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

1、用戶中心

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

設(shè)計(jì)用戶中心就是要解決這些上面五個(gè)問題。

對于用戶中心來說，首先要解決的就是用戶生命周期的問題。可能大家也會有疑問，為什么會叫做用戶中心，而不把它稱為客戶中心？

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

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

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

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

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

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

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

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

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

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

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

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

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

2、產(chǎn)品中心

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

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

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

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

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

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

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

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

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

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

3、核算中心

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

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

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

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

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

這是我們設(shè)計(jì)核算中心的一個(gè)大的流程圖：

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

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

4、賬戶中心

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

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

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

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

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

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

我們在設(shè)計(jì)賬戶中心的時(shí)候，也設(shè)計(jì)了賬戶的基本模型：

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

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

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

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

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

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

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

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

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

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

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

5、支付中心

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

對支付中心的設(shè)計(jì)我們提了一些概念：

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

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

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

6、交易中心

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

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

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

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

下面這個(gè)圖是一個(gè)訂單的處理過程：

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

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

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

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

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

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

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

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

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

三、三湘實(shí)踐經(jīng)驗(yàn)分享

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

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

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

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

1、發(fā)起中臺建設(shè)項(xiàng)目

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

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

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

• 第三，報(bào)行里面去審批，像三湘當(dāng)時(shí)是報(bào)了行辦會、董事會匯報(bào)批準(zhǔn)以后才開始建中臺。

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

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

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

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

3、堅(jiān)持自主設(shè)計(jì)、嚴(yán)守架構(gòu)定位

這點(diǎn)對于城商行來說有一定的借鑒意義。

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

堅(jiān)持自主完成高階設(shè)計(jì)，包括功能設(shè)計(jì)（需求分析）、詳細(xì)接口設(shè)計(jì)，并要求廠商嚴(yán)格按照設(shè)計(jì)進(jìn)行實(shí)施。

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

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

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

4、“架構(gòu)并行，平滑過渡”

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

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

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

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

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

>>>>

Q&A

Q1：請問中臺建好后，效果達(dá)到預(yù)期了嗎？

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

Q2：怎么看中臺對中小銀行的價(jià)值？

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

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

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

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

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

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

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

Q6：業(yè)務(wù)架構(gòu)后面會考慮結(jié)合微服務(wù)嗎？

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

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

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

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

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

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

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

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

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

Q11：除了這六個(gè)業(yè)務(wù)中臺，還有啥中臺準(zhǔn)備做？

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

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

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

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

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

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

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

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

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

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