本文由 dbaplus 社羣授權轉載。
前言：什麼是中臺？
開始正題之前，首先要討論下什麼是中臺。按網上搜集到的信息，有些人說中臺是技術中臺，像微服務開發框架、Devops平臺、PaaS平臺，容器雲之類的；有些人說中臺就是微服務業務平臺，像最常見的什麼用戶中心、訂單中心，各種微服務集散地，叫做”業務中臺“；還有人說中臺是組織的事情，組織架構有調整的話， 也可以叫”組織中臺“；也有人說中臺是一種思想，一種體系，可以快速聚合後臺的數據與能力。因此不同的人對中臺有不同的理解。
在三湘銀行去年做中臺項目的時候，我們在網上找到了一個定義： 中臺是企業級能力複用平臺。 這是我們去年比較認同的概念，理由是：
- 企業級 定義了中臺的範圍，區分開了單系統的服務化與微服務；
- 能力 定義了中臺的主要承載對象，能力的抽象解釋了各種各樣中臺的存在；
- 複用 定義了中臺的核心價值，傳統的平臺化對於易複用性並沒有給予足夠的關注，中臺的提出和興起，讓人們通過可複用性將目光更多的從平臺內部轉換到平臺對於前臺業務的支撐上；
- 平臺 定義了中臺的主要形式，區別於傳統的應用系統拼湊的方式，通過對於更細力度能力的識別與平臺化沉澱，實現企業能力的柔性複用，對於前臺業務更好的支撐。
在去年我們主要使用此定義描述對中臺的理解。
但是上面這些概念是否能真正解釋中臺？在中臺項目完成後，我又重新做了思考。如果按照上面的定義，並不能完全清晰說明什麼是中臺。因爲傳統的SOA架構、微服務架構、標準化和平臺化的一些改造都可稱之爲”中臺“，所以中臺的概念感覺還不是太清晰。
我們看一箇中臺的演變示例，它是參考了阿里架構的演變。假設有一家電商公司，一開始創建了中間藍色這塊食品電商平臺，實現了一些訂單、商品、用戶、支付的功能。食品電商平臺對應的業務部門是食品業務部。
後來隨着公司業務發展，又成立了藥品業務部，通過複製食品電商平臺的模式創建了對應的藥品電商平臺，其實這個新平臺用到的功能類似於食品電商平臺。但由於這兩個平臺售賣的貨物存在差異，兩個平臺並沒有結合。公司再大點，就汽車電商平臺。最後，三個平臺各自獨立發展自己的服務架構和內部的業務管理。
在支付功能層面，這個公司的不同電商平臺可能會跟不同的支付機構進行合作來實現交易功能。三個電商平臺都有對應的用戶管理和支付功能。由於三者處於競爭關係，導致支付通道不能實現統一。
基於這些問題，公司不得不開始建中臺。把三個電商平臺負責用戶管理的人力集中起來，成立用戶拓展部，創建起用戶中臺，實現用戶的管理和營銷功能；同理公司又成立了支付結算部，創建支付中臺。當公司建立起用戶中臺和支付中臺，它的用戶管理和支付管理能力就能統一起來，整合了資源，這就是中臺的大致的演變示例。
根據這個示例我提出了一個新中臺概念， 中臺是基於企業資源整合的需要，通過運營模式變革、組織架構調整、IT架構重構等方式形成的企業級服務複用能力。
- 中臺的戰略目標是實現企業資源整合；
- 中臺的能力體現在企業級的能力複用；
- 中臺的實現手段是運營模式變革、組織架構調整、IT架構重構，且運營模式變革是重點；
- 中臺可以解決一些問題：突破組織壁壘，不會因爲組織間的競爭關係導致資源只能服務某一個部門；統一公司內部資源，實現資源共享；快速支持業務創新。
一、爲什麼建中臺？
講完中臺的概念，我們想想銀行爲什麼要建中臺。
大部分銀行的組織架構和圖類似，銀行組織架構本身已經區分出前中後臺的體系：像營業部、分支行、金融市場部等做具體對客業務拓展的部門屬於銀行前臺部門；對於一些做業務管理和產品設計的部門，像風險管理部、信貸審批部屬於銀行的中臺部門；而銀行內部的管理機構，像辦公室、人力資源部等服務於銀行經營的部門則屬於銀行的後臺部門。
再看看傳統銀行的IT架構設計。最上面的是銀行的渠道端，就是對客部分的系統和一些整合服務平臺；中間部分屬於銀行金融產品運營類的系統，由於銀行的金融產品種類特別多，所以對應系統也非常多；在後臺，會有銀行核心系統，包括互聯網核心系統、銀行核心系統和賬戶系統；最下面的是BI類的系統。從架構圖可以看出，銀行的系統數量非常之多。就拿三湘銀行這樣小的銀行來講，系統數量其實也有140多個。
正因爲銀行IT系統數量衆多，通常銀行都會存在以下幾個問題：
- 能力重複建設：不同系統基礎能力重複建設，例如客戶信息管理、賬戶管理,新建系統或優化規則時造成整體成本的浪費和項目週期的增加；
- 系統調用複雜：新產品的實施會涉及多個關聯繫統共同改造，導致改造成本高且實施週期長；
- 產品/賬戶/交易/覈算緊耦合：產品與賬號、交易與覈算的處理放在同一個模塊中實現，當需要產品支持不同的賬號類型、交易需支持不同覈算規則時，則必須通過修改代碼邏輯或接入相應的新系統才能實現相應功能；
- 架構複雜難以重構：調整架構所需的成本、週期、業務影響和風險，因此多數採取局部優化的方式，難以一次性完成整體架構重構。
從推出一個全新產品的實施週期來看，銀行跟新興互聯網公司會有不少差距。金融科技公司一般在1個月以下，傳統商業銀行通常要3個月以上，大行可能需要半年到一年時間。
到這裏我們已經看出爲什麼銀行要建業務中臺，其實銀行建業務中臺的驅動力不是來自業務部門。對於商業銀行來說，它的業務運營和組織架構本身就是前中後臺的模式，本身就切合中臺的設計理念。業務部門對中臺的建設並沒有太急迫的需求，動力不足，即使不建中臺，其業務的流轉還算順暢。 實際上銀行的中臺項目的發起都是由科技驅動力爲主。 隨着互聯網金融競爭加劇，業務對需求的響應時間要求逐漸向互聯網企業看齊。而傳統銀行應用架構難以支持這種快速響應、快速上線的改變，因此科技部門迫切期望通過中臺項目改變IT的交付效率，這就是銀行建中臺最大的驅動力。
二、銀行業務中臺架構設計
對於中臺的建設，會有很多種不同的設計。主要以三湘銀行中臺設計爲示例供大家參考。
首先我們講下建業務中臺要解決的問題。銀行建中臺最大的問題主要解決新產品上線 成本高、週期長 這兩個問題。
該圖是銀行某個簡單產品的流轉示意圖，左邊是渠道系統，中間兩個是產品系統A和產品系統B，負責提供產品的服務；右邊是銀行賬戶類的系統，像傳統核心和互聯網核心，還有涉及第三方支付系統。大家可以看到，我們如果要做一個產品的購買，渠道系統要對接到每個產品系統來實現產品的展示，以及發起一個產品的購買交易。通常銀行會把一些產品的扣款，以及支付的一些功能落在產品系統上，由產品系統去對接銀行的核心，以及銀行相應的支付系統實行資金扣劃。
每創建一個產品，每個渠道系統要實現同樣的一套接口對接。看圖右邊列出了主要的五個接口，實際上真實情況下接口數量會比圖中的更多。
對於產品系統來說，除了要提供渠道系統要訪問的接口以外，還要實現跟行內核心繫統以及支付系統對接的一些功能。大家可以看到，當產品系統越多，那渠道系統要實現對接的接口數就越多。
另外產品系統也需要對接行內的一些系統，以接入核心系統系統爲例，假設我們有兩個核心系統，一是銀行核心，二是互聯網核心，那麼產品系統就要實現兩個核心系統的對接。如果是支付系統的話，每一個支付通道就要接一次，比如人行系就有大額支付、小額支付、超級網銀這三種支付通道，再加上微信、支付寶等等其他第三方支付通道。同時，產品系統還要實現記賬和支付的異常處理的功能，這些規則如果沒處理好，也會容易造成銀行的短款和賬務問題。這就是爲什麼銀行在現有傳統架構下創建一個新產品成本高和週期長的原因。建中臺的目的就是爲了解決這麼一個問題。
那針對上述問題，就有了四個對應的業務中臺設計目標：
- 快速創新，這是最主要的目標，支持創新產品的快速實施，並能有效降低整體成本和實施週期；
- 系統複用：不推翻現有銀行的整體應用架構，已有系統可以得到有效複用，無需重構現有系統；
- 全業務支持：支持銀行現有業務場景在新架構的落地；
- 平滑過渡：支持現有業務場景的新老架構並行和逐步遷移，實現業務的平滑過渡，降低中臺建設過程的實施風險。
基於以上四個目標，三湘銀行在去年建業務中臺的時候，挑選了銀行六個最基本的業務能力去建對應中臺，也是第一期業務中臺建設項目中六個最核心的功能： 用戶中心、賬戶中心、支付中心、覈算中心、交易中心、產品中心。
我們認爲業務中臺的定位爲： 作爲產品系統與渠道系統、賬戶系統、支付系統、覈算系統之間的橋樑，利用傳統銀行應用架構中已有的系統，通過標準業務模型來實現系統間的解耦。 這個業務中臺的理念其實跟平臺標準化、或者SOA的理念很相近，不過還涉及到業務模型的調整。所以三湘銀行的業務中臺跟一個純IT項目還是有所區別的。
1、用戶中心
首先講用戶中心。那用戶中心要解決的其實有五個問題：客戶管理、生命週期管理、電子渠道互通、客戶信息整合、簽約管理。
設計用戶中心就是要解決這些上面五個問題。
對於用戶中心來說，首先要解決的就是用戶生命週期的問題。可能大家也會有疑問，爲什麼會叫做用戶中心，而不把它稱爲客戶中心？
在做用戶中心設計的時候，我們有思考過這個問題，實際上用戶和客戶的定義是有所區別的。在傳統銀行來說，它通常會把開了賬戶的客戶才叫客戶，對其他用戶銀行基本上是不管的。就像遊客，銀行基本上是不登記遊客的信息。但是互聯網公司就不一樣了，互聯網公司會收集遊客、註冊用戶、實名用戶、實體用戶的信息進行管理，包括登錄信息、瀏覽信息，目的是爲了更好去做客戶的營銷，以及提升客戶體驗。我們把互聯網公司這套設計模式放到用戶中心裏面。
我們要求把從遊客開始到實體用戶這四類型的用戶都要管起來。
- 第一類遊客，純過來瀏覽，但是沒有做過任何註冊，也沒有留下任何聯繫方式的。但實際遊客還有一個關鍵信息我們可以保留，那就是遊客的設備號，就是他通過某個手機訪問，後期可以通過這個設備號就能找到這個遊客是誰；
- 第二類是註冊用戶，只要他在銀行渠道或系統留下了聯繫方式，像手機號、微信號、郵箱，就認爲他是一個註冊用戶，這代表我們可以聯繫到客戶；
- 第三類就是實名用戶，實名用戶顧名思義就是客戶在銀行系統中通過了實名認證，比如通過了身份證認證、人臉識別。這類用戶就叫實名用戶；
- 第四類實體用戶跟傳統銀行的概念一致，就是在銀行開過戶的客戶。
對於這四類用戶，在用戶中心都需要統一進行管理，包括用戶信息管理、用戶行爲登記等等。
在用戶中心裏面，還會設計統一登錄的功能，比如說用戶能夠在三湘銀行所有的電子渠道上支持用戶名這種方式登錄，或者手機號登錄，或者賬號郵箱登錄，就是在各個電子渠道都是一致的。同時，也可以通過一些設備的驗證方式，比如說人臉登錄、指紋登錄、手勢、掃碼這些登錄方式，也能支持一些第三方的登錄方式，像微信、支付寶授權登錄，這些登錄模式我們的用戶中心上面都能支持。
第二塊就是統一簽約。統一簽約這塊我們會把用戶所有簽約的數據，都會在用戶中心有管理起來，同時所有的簽約和解約的動作，都會在用戶中心上支持，這樣保證能在用戶中心查到用戶所有的簽約內容，以及實現所有用戶的簽約解約的動作。
第三塊就是統一視圖，把所有跟客戶相關的信息，包括客戶的基本信息，客戶的私有資產、負債的信息，客戶的交易流水還有一些行爲，都會統一在用戶中心對外展示。這就是統一視圖的概念。
實際上用戶中心的整體功能包括六部分：
下面這個圖是用戶中心大體功能示意圖，除了剛纔介紹的客戶管理、統一視圖等功能以外，還有關聯管理能力，無非就是把客戶的收藏夾、收款人名冊、收件人地址類似這些信息在所有渠道上共享，這樣使用戶在銀行所有的終端都能獲取到他的信息，提升客戶的體驗。
所以說整個用戶中心等同於傳統銀行幾個系統的集合，一個就是ECIF，其次就是實時CRM，實時能獲取用戶360°的視圖，再加上對於用戶在所有渠道端操作和體驗的渠道支持，這就是對於傳統銀行用戶管理能力的整合。
2、產品中心
產品中心需要解決的問題有以下四點：產品目錄、產品管理、產品查詢、產品上下架。
對於產品中心，我還想解釋幾個概念：
我們做的產品中心就屬於狹義上的產品管理類系統。
上圖是我們產品中心整體的功能架構。
左邊是管理產品的基本屬性，包含產品的基本信息、銷售屬性，比如它在哪個渠道銷售、銷售額；促銷信息，某個產品在某個期限可以打折，或者通過優惠券減免手續費等；收費信息，購買某個產品所需要收取的對應手續費，類似以上這些就是產品基本信息的管理。
但其實還會存在某些信息需要從各個產品系統上同步過來。相當於產品中心一方面會從傳統核心系統把產品同步回來，另外在產品中心維護好某些產品信息，也可以反向把這些信息同步到產品系統，實現對應的產品的創建。這是產品中心裏面產品屬性管理的一個功能。
在產品中心那塊，屬於產品渠道和店鋪的管理，其實在做產品中心設計的時候，就考慮到把產品中心作爲統一銷售管理的功能。在產品渠道里面，我們設計了店鋪和機構的概念，在店鋪（機構）底下設置了分類，那對於所有的產品，就會上下架到所有的分類裏面。
比如說在分類裏面會有一個推薦或熱銷的產品分類，那可以在產品中心進行配置把產品上架到對應的產品分類。那對於渠道系統來說，就能直接看到這些分類上面的產品清單和產品的信息。同時產品中心會實現所有產品信息的緩存，所以它能支持一個高併發的產品查詢。所以說所有的渠道系統不用再去訪問一個具體的產品運營系統，相當於手機銀行就不用再去訪問核心系統就能獲取對應的產品信息。所有要銷售的產品都從產品中心直接獲取就可以了。
同時產品中心還會有個功能——實現產品的過濾。渠道系統可以把查詢產品對應的渠道和客戶標籤送給產品中心，產品中心可以通過產品所設置的可銷售渠道以及可銷售客羣來決定哪些產品能夠在渠道上能看到。
比如說有個客戶登錄了手機銀行，他查看他能購買的產品時候，產品中心就會根據該客戶能看到的產品返回對應的產品信息，不需要渠道系統再去做對應的產品信息過濾，從而實現千人千面的產品銷售展示功能。
3、覈算中心
三湘銀行今年纔開始建覈算中心，去年建業務中臺的時候還沒有把覈算中心建起來。
這是建覈算中心要解決的4個問題。要理解這4個核算中心的問題，先講下銀行的賬務處理流程。其實銀行的賬務處理通常是這樣：客戶在銀行的交易系統上可能產生了一筆交易，這個交易可能是一個產品的購買，那這筆交易實際上會實時的輸送到核心系統來進行產品的扣賬，以及對客戶產品賬戶的入賬。
比如說一個理財產品的購買，客戶就需要實時把他理財購買所花的錢扣下來，同時對客戶生成一個理財產品的分戶，把他所持有的理財產品份額送入他的分戶裏面。這部分交易需要實時實現，在我們銀行內稱爲“客戶賬”，就是跟客戶相關的賬。
其實銀行裏面還有另外一部分賬，叫做總賬，就是銀行賬。銀行賬一般來說屬於銀行內部使用，用於實現銀行覈算報表，資產負債報表等信息。這些賬沒有要求一定要實時，所以通常在銀行裏面夜間通過批次的方式進行記賬處理。
所以建覈算中心就是爲了要解決剛纔說的4個問題，分成核算規則配置、批量過賬、實時過賬3個功能：
這是我們設計覈算中心的一個大的流程圖：
大家可以看左邊，當你實時處理一筆交易的時候，交易系統是不需要再產生銀行覈算的這部分賬戶。它也不需要關心銀行覈算的規則，只需要實現銀行客戶賬的扣錢，以及產品的入賬。把這個做了就行了。然後交易系統就可以把這個交易數據，和它的交易流水直接送到覈算引擎裏面，那覈算引擎會把交易流水的接口映射成銀行內部的標準交易格式，再關聯上配置好的記賬賬套。比如說一筆交易流水會有多少借貸的分錄，以及借貸的金額該怎麼計算，這些都是通過對應的配置實現，最終覈算引擎會生成具體的銀行賬的借貸分錄，再把該分錄實時送給總賬記賬。這就形成我們實時記賬的功能。
同時對於批量來說，它其實跟實時記賬很像。批量的話，可能該系統通過準實時模式集合了一批的賬戶，或者說每天夜間集合了所有的賬戶，送給覈算引擎，覈算引擎也是用剛纔處理的這些方式，把生成對應的這些交易數據快速登錄送到總賬去進行批量計算。這是一個核算大的流程設計。
4、賬戶中心
賬戶中心要解決的問題有四個：賬戶能力重複建設、跨系統記賬複雜、賬戶能力參差不齊、缺乏統一賬戶視圖。
在賬戶中心的設計裏面，我們提出了三個概念：產品與賬戶分離、介質與賬戶分離、賬戶與賬戶分離。
剛纔在講到產品中心的時候，其實講到產品的概念，產品屬於一些運營規則集合。把產品跟它的賬戶分開有什麼好處呢？舉個例子，在傳統的核心繫統上，有一個產品已經實現了一套規則，這個規則假設放在I類戶裏是可以用的，但放在II類戶是用不了的。如果要實現同樣的產品規則，那必須要花時間重新進行開發，又比如未來遇到積分系統要實現類似的功能，我們又要去積分系統上實現對應的規則。
如果能把賬戶和產品剝離開，自然而然一套的產品規則可以應用在不同的賬戶上，就像剛纔說的存款取利息的功能就可以放到I類戶也行，II類戶也可以，甚至像一些積分賬戶也能做到對應規則的處理。
第二塊概念就是介質與賬戶分離。這裏面主要還是區分介質的概念。介質是由銀行提供給客戶，用於證明客戶身份的憑證，介質本身不具備金融屬性。真正具備金融屬性的是介質所綁定的賬戶。把介質跟賬戶區分開有很多好處，比如說客戶的卡丟了，他換卡只是換介質，只需要重新綁定原來的賬號，另外賬戶和介質分離後也能支持一個賬戶綁定多個介質。
最後一個概念是賬戶與賬戶分離，這其實相當於在設計上把所有的賬戶放在同一個層級中，而賬戶和賬戶之間的關係是通過賬戶中心的合約管理來去實現這些賬戶之間的關係。通過賬戶之間的合約可以實現各種各樣的賬戶層級關係支持，擴展性也會比較高。這也是賬戶中心的設計理念。
我們在設計賬戶中心的時候，也設計了賬戶的基本模型：
這個賬戶基本模型包括了賬戶的基本信息，賬單信息，凍結/止付信息，餘額信息，擴展信息，合約關係，介質綁定。我們把所有的賬戶都統一抽象爲這樣的一個模型，對所有的賬戶都會按照這個模型做管理和訪問。對賬戶來說，我們還會提供一些標準的基礎功能，比如說賬戶的限額管理、合約管理、智能路由、睡眠戶管理這些基本的賬戶功能。
其次我們還把賬戶的基礎功能標準化成幾個最基礎的原子服務：所有賬戶的操作無非都是開戶、銷戶記賬（存/取/衝正）、凍結解凍/止付解止、掛失、查詢、信息變更。這些功能對於所有的賬戶都是一樣的。把賬戶服務都標準化以後，在銀行裏面進行賬戶的處理，包括記賬、凍結等操作，都可以沿用這個統一模型去做處理。
對賬戶中心裏面剛纔說的合約概念，大家可能不清晰。其實我們把合約認定爲賬戶和賬戶之間的關係，並且通過合約可以實現賬戶和賬戶之間一個資金流向的管理。這個圖提出了5個賬戶流向的管理：
- 資金流轉合約：進行賬戶之間的資金流向限定，即限制賬戶資金只能向簽訂了合約的賬戶轉入；
- 虛擬子賬戶合約：賬戶上實下虛，將結算戶與虛擬戶結合形成類似會員卡性質的資金臺賬管理，虛擬戶的動賬聯動執行結算戶的動賬；
- 虛戶資金歸集合約：賬戶上虛下實，將多個結算戶資金歸集到一個虛擬戶統一展示，結算賬戶的動賬聯動執行虛擬戶的動賬；
- 資金歸集合約：將多個產品戶與結算賬戶關聯，通過產品戶控制結算賬戶的資金用途，產品戶的動賬聯動執行結算戶的動賬；
- 集團賬戶合約：通過合約將集團公司之間的賬戶關係關聯起來，供業務應用進行集團賬戶的操作和管理。
各種各樣的賬戶關係其實都是通過合約類型去支持，而且合約類型未來還可以不斷拓展。
在賬戶中心的建設裏面，我們也考慮到成本的問題。不可能說建一個賬戶中心就把原來的賬戶系統全部幹掉，把賬戶都遷移過來，所以在建賬戶中心的時候，要考慮賬戶中心本身有賬戶功，能但同時也能實現把原有的賬戶系統直接對接過來。比如說我們要把傳統核心的I類戶接入進來，可以通過一個適配接口把傳統核心接入賬戶中心。
那對於外圍的產品系統，它以後不會再直接去訪問傳統核心，而是所有對賬戶中心操作的處理都通過賬戶中心的標準服務去訪問，來實現對所有賬戶的處理。通過這種模式，可以讓所有渠道、產品系統對賬戶的操作都可以採取同一個模型，而且都通過賬戶中心來實行。那未來假設有某些系統我們要重構的時候，這時候自然而然就可以把對應的賬戶遷移到賬戶中心實現。這個模式可以極大地減少數據遷移的成本，以及避免了比較大的實施風險。
5、支付中心
所有銀行都有統一支付的概念。支付中心要解決的問題其實跟統一支付的概念類似：
對支付中心的設計我們提了一些概念：
我們把銀行的I類戶的扣賬也放到支付中心處理，並且將所有涉及的資產的動賬我們都放到支付中心去實現。
以下這個圖就是剛纔說的支付中心的大致功能圖。
其實我們把三塊支付、記賬、產品通道都交給統一支付去實現。這個支付模式和我們後面講的支付訂單模式會有關係。支付概念的變化是我們這次做中臺一個比較大的特點。
6、交易中心
交易中心原來在銀行基本不怎麼提到，交易中心主要解決的問題有：
那基於剛纔那幾個問題，我們在建中臺提到一個訂單的概念，就相當於我們利用了一個電商的訂單模型來去創建銀行的一個交易過程，大家可以看到現在這個圖，是我們交易中心裏面的訂單模型。
對於渠道系統來說，它每次發起一個產品購買行爲，其實就是創建了一個訂單，然後呢訂單裏面有的信息跟電商很類似，第一會有訂單最基本的信息——訂單日期、幣種、總金額、執行參數等信息；第二個就是產品的交付清單信息——產品信息、購買數量、支付金額、擴展信息，這個交付清單可以放多個產品在裏面；第三個的話就有費用調整清單，涉及到我在處理這張訂單需要收費或者促銷、優惠的調整，調整整體上要支付的金額，這個可以通過費用調整這塊實現；最後就是對於這個訂單通過什麼樣的支付工具去進行支付，比如通過I類戶還是II類戶，或者通過第三方的賬戶去支付。可以支持在訂單裏放進去多個支付工具，相當於多個支付方式來同時對一張訂單進行支付。
這個就是一個訂單的模型，跟電商的模型是非常類似的。
下面這個圖是一個訂單的處理過程：
一開始在渠道系統，我們會給客戶創建一個訂單，會包含剛纔說的支付和交付的信息，然後走到一個支付流程。支付流程也是通過統一支付進行對應的支付動作。支付的內容其實可支持很多種類，比如說客戶可以通過資金支付，也可以通過權益支付。比如說積分就是一種權益，代金券也是一種權益。甚至說客戶可以通過持有的產品去支付訂單。比如說客戶手上有一個理財的產品，那他可以通過理財產品的份額去支付訂單。當支付成功以後，就到了銀行把資產交付給客戶的過程。
那交付的話，其實跟剛纔類似，像貸款類交易，銀行就會把錢交付給客戶；對於某些交易會產生權益的，銀行就會把權益交付給客戶；比如說產品購買，銀行就會把錢交易給客戶。其實大家可以看到支付和交付都是通過統一支付實現，這也是爲什麼我們剛纔提支付中心時候提到三塊：包括記賬、產品、第三方支付，其實都統一放在統一支付，也是這個原因。通過統一支付支持的所有資產動賬類型，可以保證我們整個模型的簡單化。
同時對於訂單模式，我們也做過了一些演練，其實訂單模式在設計裏面可以支持銀行所有產品的處理，也包括一些特殊場景。
對於貸款類的交易，也可以通過訂單模型去實現。像我們貸款的放款，這在我們這屬於採購訂單。那客戶支付給銀行的實際上是一筆負債，客戶給銀行支付的你可以理解爲一筆借據，然後銀行交付給客戶的是資金，就把貸款的錢給到客戶。還款情況就是剛好相反。
所以銀行所有業務都可以基於這個訂單模型去處理。
基於剛纔我們講到的六個中心，這個圖就解釋了我們爲什麼通過這6箇中心能夠讓銀行的一些產品都快速上線，然後能夠降低我們開發的量。
最左邊的渠道系統不會直接跟產品系統產生對接，渠道系統只要需要按照這裏面的用戶中心、產品中心、交易中心這三個中心進行一次標準的接口對接，對接完以後不需要再去改造。假設我們現在新建了一個產品系統，產品系統只要按照六個中心的標準接口，實現對應產品信息的同步，實現對應的交付接口，實現對應的核算功能，這時候這個產品系統就能嵌入我們的整個業務中臺的體系裏面。這時候渠道系統就可以原生的訪問到這個產品的功能，實現對應的產品的銷售和運營的管理。所以，整體上要上新一個新的產品特別快。
這個圖算是業務中臺的一個整體的描述。這裏面最大的點就是可以看到，業務中臺最重要是解決了渠道系統和產品系統解耦的問題。
我們再回顧一下最早時候提的中臺的概念，中臺通過運營模式變革、組織架構調整、IT架構重構等方式形成的企業級服務複用能力。在我們這次的業務中臺建設裏面，除了組織架構調整我們沒有做以外，我們的運營模式也發生了一些變化。當然這個運營模式指的是IT層面對業務處理的運營模式。其次也做了一個IT方面架構的重構。所以在這個業務中臺建設裏面，我們其實是通過我們三個模型，貨架模型、訂單模型、支付模型，來實現渠道系統與產品系統的解耦，產品系統只需實現產品規則，無需處理支付；渠道系統無需改造；中臺業務系統配置或輕量級改造支持新功能，就可以支持一個產品的新上線。這就是一個業務中臺建設後的效果。
三、三湘實踐經驗分享
講完中臺的整體架構，接下來分享一下三湘銀行在去年建設中臺的大致經驗和情況吧。
三湘去年的中臺項目總共建了22個系統，但這22個系統不是全都是業務中臺，實際上業務中臺只佔了其中的六個系統，其他系統包含渠道中臺、數據中臺以及公共服務這些系統。
整體的項目從去年的3月份開始啓動，5月我們完成總體設計，6月完成招標工作，8月就完成了開發，9月完成測試和上線，10月份完成第二期，算是三湘銀行歷史以來最大的項目。這個項目建設了我們行的業務中臺，雖然在項目裏只佔了6個系統，卻是最核心的業務系統。另外項目也建設了我們行的數據中臺、渠道中臺和公共服務，同時我們也跟阿里合作部署了飛天私有云。這中間我們做了很多事情，整體投入相比大行來說不多，但是對於小的銀行來說，這個投入算是特別大的。大家可以通過這個案例可以看到建設中臺並不見得要花特別長的時間和週期，也不見得投入是特別大，同時也不見得一定說需要行方的人員充足情況下才能建。以外包的方式也可以去做一個相應的中臺建設。
但是在這個中臺建設的過程中，確實存在很多問題或者困難，是一步步克服過來的。我有一些經驗可以跟大家分享一下：
1、發起中臺建設項目
業務部門不會有動力去建設中臺，通常都是由IT部門發起，那麼IT部門要怎麼去說服行裏面去做中臺的項目呢？當時我們做了幾個事情：
- 第一，我們是聯合了一些專業機構共同去開展評估工作。有句話說得好，“外來和尚好唸經”，找專業機構可以讓銀行內部去信服我們的評估結果。如果是由行方人員評估，那麼行裏很可能會認爲我們是出於做項目的目的而得出的結果。
- 第二，評估的過程中必須要進行高層和業務的訪談。在這個訪談的過程中，讓高層和業務理解建中臺能帶來什麼好處，建中臺的理念是什麼樣的。
- 第三，報行裏面去審批，像三湘當時是報了行辦會、董事會彙報批准以後纔開始建中臺。
評估環節主要出的是兩份報告：第一份報告就是一個應用架構現狀評估。第二份就是應用架構整體的建設方案。這個整體的建設方案實際上就是中臺的整體框架。
2、建立開發規範
在建中臺的時候，會涉及到非常多的人，非常多的廠商。中臺爲了實行解耦，我們還分拆了很多的功能系統去建設。那對於這麼大面積的改動，一定需要一些公共的開發規範來去限制大家。不能各做各的，不然很難去整合。在建中臺的時候一定要規範先行。我們制定了好幾個規範，而且特別嚴格去實行。
這些都要求整個中臺建設過程中，所有人都必須嚴格執行規範，來保證我們系統建設不會出現偏差。
3、堅持自主設計、嚴守架構定位
這點對於城商行來說有一定的借鑑意義。
在建設中臺的時候我們是一直堅持自主設計。雖然我們當時的人員並不多，但是所有的高階設計都是我們行方自主完成的，並且是行方內部通過的。當然過程中也會和跟廠商的人員一起評審，不過最終所有的設計都是由行方的同事提出。
堅持自主完成高階設計，包括功能設計（需求分析）、詳細接口設計，並要求廠商嚴格按照設計進行實施。
廠商的產品可以拿進來，但必須嚴格執行由廠商適配我們的設計的要求，而不是我們根據廠商的產品來調整設計。這是銀行在建中臺必須明確的做法。如果把設計交給廠商，很容易出現廠商按照原生產品設計，最終出來的不是我們想要的效果。
同時在中臺建設中一定要嚴守架構設計定位。嚴守架構設計中每個系統的功能定位，並按定位落地系統功能，當出現定位模糊的情況快速進行明確和調整。已經明確的定位不接受任何開發人員的挑戰。不能因爲某些開發人員或者廠商覺得這個定位不合理，我們就會爲此放棄定位。
這麼短時間能把中臺建設起來，我覺得這兩個堅持是很重要的，這樣到最後系統整合測試的時候纔不會出現那麼多問題。
4、“架構並行，平滑過渡”
這點是爲了說服業務的。在建業務中臺過程中，當時我們沒有停止任何的業務需求，科技部一邊接常規的業務需求，一邊在建新的業務中臺。基於這種情況，要保證兩種架構是能平滑過渡。爲此提出了三點：
- 旁路架構：整體架構不阻斷原有交易，而是在原架構基礎上新增旁路架構，交易在兩個架構上可以正常處理；
- 複用已有系統：儘量複用原有系統功能，原有系統按照中臺標準新增接入接口，並保留原接口，兼容兩套接口模式並行，無需進行數據遷移；
- 逐步遷移：按產品逐個分批進行業務遷移，降低整體遷移的風險，出現問題影響範圍減少。
上面就是我在做業務中臺時總結出來的關鍵經驗，希望能給到大家一些參考。
Q&A
Q1：請問中臺建好後，效果達到預期了嗎？
A： 三湘的業務中臺的建設效果基本達到，新產品需求的實施週期平均縮減了60%，業務中臺5個系統的全部外包開發人員少於10個人。
Q2：怎麼看中臺對中小銀行的價值？
A： 中小銀行沒有大行那麼足的的網點資源和開發預算，同時也存在互聯網金融公司的競爭壓力，只有做到快速響應、低成本才能在競爭中生存，而業務中臺的方案就是以產品快速上線和降低成本爲目標的，對中小銀行應該有實現的價值。
Q3：你們實時數據處理這塊，架構是怎麼做的？實時計算引擎用的是什麼？
A： 三湘的實時數據處理採取的是OGG（Oracle Golden Gate）+ Kafka + Flink + Oracle/HBase的處理方案，利用OGG數據同步功能準實時獲取業務系統的數據變化，同時無需業務系統配合改造。
Q4：能簡單介紹一下數據中臺建設經驗？
A： 如果按照我的觀點，目前銀行的數據能力建設在嚴格意義上並不能稱之爲中颱，因爲在數據運營模式和架構上與傳統BI並沒有太大的區別，只是將傳統的能力合在一起稱爲數據中臺。數據中臺在數據標準、數據管控、數據倉庫、數據應用的開發模式和架構沒有太大的變化，只是建設前要充分考慮海量數據處理、實時數據服務的需求，同時一些互聯網企業也會將決策引擎納入數據中臺的範圍中，所以在數據中臺建設上是一個混合型的技術架構，需要充分利用傳統數據庫、大數據平臺、實時計算等技術特點實現所需的能力。
Q5：用戶中心與ECIF的功能邊界劃分？
A： 在三湘的業務中臺裏ECIF的功能是用戶中心的一部分，也就是用戶中心是完全替代ECIF的，具有ECIF的完整功能並擴充了其他用戶相關的功能。
Q6：業務架構後面會考慮結合微服務嗎？
A： 三湘在建設業務中臺的技術選型上本身就採用了分佈式的架構（阿里的SOFA），實際上也可以將每個中心視爲一個微服務，只是微服務劃分的粒度比較粗，未來如果要支撐更大的業務併發量，會考慮將每個中心的服務能再拆分爲更細粒度的微服務。
Q7：請問什麼是系統流水號？
A： 三湘流水號規範規定有3個流水號：統一流水號、系統流水號、接口流水號。統一流水號貫穿交易的全流程，由業務最前端的系統生成，整改交易流程的各個系統環節都必須保持不變；系統流水號（也可以叫業務流水號），用於每個系統確定交易在自身的唯一性，同一筆交易在當前系統重複處理時的系統流水號不允許改變（例如交易失敗重做），以保證業務不出現重複；接口流水號在每次接口調用的時候產生，用於控制網絡上的接口調用不會重複。
Q8：旁路架構是不是要做很多接口？但是原系統也沒有優化呀？
A： 業務中臺方案爲了業務的平滑過渡，要求原系統的業務處理流程和模式不改變，所以原系統的接口是需要保持不變的；業務中臺作爲旁路架構實際上進行了接口的標準化整合，整個中臺系統對外的標準接口並不多，以記賬接口爲例，賬戶中心僅提供了一個標準的通用記賬接口，而原來的核心繫統對外提供有十幾個不同類型的記賬接口。
Q9：賬務和核算的區別是什麼？
A： 按面對對象不同可以區分：賬務一般指客戶賬，是銀行客戶需要看到的賬務，需要實時記賬，比如客戶的活期賬戶的資金入賬和扣款、理財產品賬戶的份額增加和減少；覈算一般指銀行賬，是銀行自身經營管理的會計賬，用於管理銀行內部資金及產生資產負債表，銀行賬不被客戶使用，因此無需實時記賬，通常通過夜間批次在總賬系統統一進行記賬處理。
Q10：中臺系統裏有哪些開源框架？
A： 三湘在中臺建設上使用的是阿里的SOFA分佈式框架以及各個合作廠商自身的開發框架，廠商框架裏面實際上也會用到一些開源中間件，考慮到技術風險及當前人員技術能力的限制，在開發框架上並沒有使用純開源框架。
Q11：除了這六個業務中臺，還有啥中臺準備做？
A： 業務中臺並沒有限定範圍，只是初期先把最核心的基礎能力形成了業務中臺的框架，後續計劃要實現的業務中臺包括權益中心和營銷中心。
Q12：你們分佈式事務、分佈式數據庫都用了嗎？
A： 目前的業務中臺架構並沒有使用分佈式事務（技術不成熟），而是採用了更爲穩妥的接口層業務一致性機制，即通過異常業務邏輯發起業務交易衝正保障業務一致性；沒有使用分佈式數據庫，僅使用了分庫分表的技術。
Q13：大行的業務模型更復雜，大型銀行做業務中臺有什麼建議？
A： 個人認爲無論銀行大小，業務模型都是類似的，只是大行的業務審批更復雜，牽涉的業務部門更多；因此對於大型銀行，在建設業務中臺更應該考慮風險問題，一次性進行全部業務的切換對大行來說更不現實，建議採用旁路架構的模式進行業務的平滑過渡，這樣可以降低風險並減少建設中臺的阻力。
Q14：你們用什麼分庫分表？
A： 目前使用的是阿里的DBP中間件實現分庫分表，不過聽說阿里已經準備放棄掉這個中間件的後續研發計劃。
Q15：數據中臺和業務中臺如何互動的？
A： 數據中臺主要爲業務中臺提供實時的數據訪問需求，主要在客戶的統一視圖方面，供渠道系統實時獲取到資產、交易流水等信息；由於數據中臺是通過數據庫底層抽取數據的方式實現的數據同步，因此業務中臺不需要與數據中臺進行直接對接，僅用戶中心負責將數據中心的用戶視圖相關接口進行封裝並對渠道系統發佈。
作者介紹：
黎慧劍，湖南三湘銀行中臺管理部總經理助理。
- 銀行應用架構師，具有12年銀行科技從業經驗；
- 曾從事核心系統、支付結算、營運管理、國際結算、金融市場、理財、BI等多個銀行業務領域的應用研發及架構設計工作，主導並完成三湘銀行中臺架構的規劃設計並實施落地。
原文鏈接：