阿里的“大中臺”是互聯(lián)網(wǎng)架構中的一個標志，將核心業(yè)務能力逐漸抽象，成為公用性的中臺;銀行是傳統(tǒng)行業(yè)中非常重視信息化的，但由于技術的高速發(fā)展，互聯(lián)網(wǎng)思維的沖擊使得銀行紛紛面臨必須轉型的困境，既包括業(yè)務轉型，也包括技術轉型。

東方IC

一、阿里中臺簡介

本人最近有幸參加了一次單位組織的阿里培訓班，現(xiàn)場感受了“云棲大會”精英們對技術的理解。培訓前后又讀了子柳老師的《淘寶技術十年》和鐘華老師的《企業(yè) IT 架構轉型之道：阿里巴巴中臺戰(zhàn)略思想和架構實戰(zhàn)》，算是對阿里的中臺概念有個粗淺了解。

阿里的中臺是個累積的過程，從 2009 年建立共享事業(yè)部開始，幾經(jīng)曲折，但是一直在積累，直到 2015 年正式發(fā)展成中臺戰(zhàn)略?？梢?，這是個演化過程，這也符合一般對架構的認知，大型架構、好的架構都不是一蹴而就的設計，是根據(jù)實踐不斷磨合調整得來的。

目前的阿里中臺大約有十幾個共享業(yè)務單元，包括用戶中心、商品中心、交易中心等。淘寶、天貓、聚劃算等 25 個大型業(yè)務應用都是由中臺的共享業(yè)務單元支持的，共享業(yè)務單元則由阿里云平臺支持。共享業(yè)務單元的劃分原則其實不是可以簡單掌握的，要綜合考量設計、運營和工程因素，盡可能遵循“高內聚、低耦合”、“數(shù)據(jù)完整”、“業(yè)務可運營”和“漸進”的原則。

阿里在劃分中臺時非常重視其業(yè)務價值和基于業(yè)務的設計，而且有業(yè)務架構崗位，每個共享單元都有業(yè)務架構師。但總體來講，其業(yè)務架構仍然是領域性的。這點在本人與阿里專家的交流過程中，他們也認為阿里仍然缺少更高一層的抽象，但是顯然這一層比較難于設計和維護。

阿里系統(tǒng)要解決的核心問題是高并發(fā)、可擴展，因此，業(yè)務通過中臺進行共享支持后，基礎設施必須能夠消解這種壓力。

阿里采用去中心(也就是去 ESB)的 HSF 分布式服務框架，以支持服務的點對點調用，解決 ESB 可能產生的瓶頸問題;采用微服務設計方式，提高變化響應;自研設計了分布式數(shù)據(jù)層框架 TDDL(Taobao Distributed Data Layer)以及分布式數(shù)據(jù)庫 DRDS;研發(fā)了支持分布式事務處理的 AliWare TXC;支持高效故障定位和運維監(jiān)控的鷹眼平臺;實現(xiàn)了限流和優(yōu)雅降級設計，以及做保障的全鏈路壓測平臺、業(yè)務一致性平臺。這是一套完整的基礎設施，提供針對電商業(yè)務特點的支持。

總結起來，阿里中臺是其自身在業(yè)務不斷發(fā)展的過程中演進和磨合出的架構，其架構即體現(xiàn)了電商的業(yè)務特色，也包含了完整的技術支持體系。由于其靈活支持和快速響應能力，成為了互聯(lián)網(wǎng)架構的優(yōu)秀實踐案例和設計標桿。

二、銀行的中臺可能會怎么建?

銀行在與互聯(lián)網(wǎng)企業(yè)的競爭中倍感壓力，在金融科技的浪潮下紛紛推進數(shù)字化轉型工作，這個過程中，自然想要學學互聯(lián)網(wǎng)企業(yè)，特別是阿里這類頭部企業(yè)的經(jīng)驗。阿里的中臺提高了服務的復用能力和開發(fā)效率，銀行是否能參考構建一個通用框架呢?要注意哪些區(qū)別呢?

銀行如果嘗試構建金融行業(yè)通用框架，首先要解決的是流程問題。

電商的中臺其實更容易抽象些，阿里的十幾個共享業(yè)務中心其實非常具有行業(yè)通用性，電商的在流程方面比較容易接受改變，在阿里提供大中臺支持的前提下，無論是阿里內部還是輸出給其他同業(yè)客戶，流程方面都會比較容易接受改進，電商領域是在比較接近的流程下，尋找能力上、服務上的特色。

但銀行卻不是這樣，銀行的能力是高度同質化的，但是流程卻各不相同，因為流程的背后是組織結構和部門利益，各個銀行之間部門設置和職責邊界都是有差別的，按照康威定律，這種差別會直接體現(xiàn)在系統(tǒng)結構上。銀行都想談轉型，但真能為此大動干戈、大幅調整組織結構的很少，就是采購商用軟件，也通常是按照自己的部門結構進行本地化改造，將組織烙印深深地打在系統(tǒng)上。

這種差別下，銀行的中臺沉降過程可能會更多地面向功能沉降，在流程與能力解耦的原則下，將流程分離成微服務架構層，但是剝離可通用的能力作為中臺服務層，而不一定適合像阿里那樣構建為業(yè)務中臺，因為吸收變化的點不同。

參考的架構圖如下：

銀行多是以產品驅動的，這點在設計上其實并不是一定要隨著“以客戶為中心”這種導向而改變，因為產品即服務、服務即產品，并不需要太糾結。

產品通常意味著會驅動后臺的一系列服務和功能。

在 ESB 下，這是不同服務間的信息流轉，其實阿里去掉 ESB 并不意味著銀行也都要去掉 ESB，這要看實際需要，如果沒有那么大的并發(fā)量、沒有那么嚴重的堵塞要擔心，也就沒必要非干掉 ESB，尤其是在銀行自己已經(jīng)使用熟練的情況下，畢竟微服務架構下是否一定排除 ESB 也是有不同聲音的。消息隊列下，其實一個產品就意味著相關服務的一組訂閱發(fā)布。

然后可以將銀行的產品按較大的流程環(huán)節(jié)進行微服務切分，這種流程可能會在不同的銀行有差別，有些業(yè)務 A 銀行有預處理過程，B 銀行卻沒有;有些流程，A 銀行一個部門搞定，B 銀行卻要兩三個部門協(xié)作。這些差異可能是內部文化的原因，也可能是規(guī)模的差異。

而一個銀行自己也可能會隨著規(guī)模的變化、業(yè)務重點的變化而調整，其實“能力”變化不大，但是流程卻可能變化較大。所以，將流程環(huán)節(jié)設計成一個微服務層，便于快速變化。

再將可以相對穩(wěn)定的業(yè)務功能，比如示例中的久期計算、缺口計算之類的較為通用，和評級計算、EVA 這些相對有變化，但不需要非得和流程攪在一起的功能，可以考慮沉降為中臺服務。服務盡可能無狀態(tài)，以方便遷移和改造。

數(shù)據(jù)則是企業(yè)級后臺。微服務的處理結果準實時更新至企業(yè)級數(shù)據(jù)庫，中臺服務可以在企業(yè)級數(shù)據(jù)庫中查詢準實時數(shù)據(jù)，實時數(shù)據(jù)則可由調用方提供。

上述過程是以通用框架為目標進行描述，但如果是銀行自主研發(fā)，自研自用，一樣也可以參考。

銀行學習互聯(lián)網(wǎng)架構還應注意，阿里中臺是按照 BASE 原則的最終一致性設計的，而銀行傳統(tǒng)上是采用 ACID 的強一致性。

上述建議是圍繞中臺化開展的討論，銀行學習互聯(lián)網(wǎng)架構，還應注意一個非常重要的差別，但是這個不在技術范疇內，這就是企業(yè)的組織結構和內部文化。

阿里的中臺是與其組織結構和企業(yè)文化共同成長的，如果想要移植其設計并且具有阿里的效果，那首先自己的內部要過關，技術也是有其生長土壤的。阿里對業(yè)務架構的重視，也恰恰是很多銀行需要認真思考的。