阿里的「大中台」現在可以算是網際網路架構中的乙個標誌了，通過多年的業務沉降，將核心業務能力逐漸抽象，成為公用性的中颱，以實現網際網路領域的快速響應機制。銀行是傳統行業中非常重視資訊化的，而且起步早，資訊化程度高，但是由於技術的高速發展，網際網路思維的衝擊使得銀行紛紛面臨必須轉型的困境，既包括業務轉型，也包括技術轉型。網際網路架構是銀行很想學習的，但是二者之間差異較大，這在轉型過程中是需要注意的。
本人是業務架構設計人員，雖在單位做了六年企業級業務架構設計，但是技術方面能力有限，不足以完整比較網際網路架構和銀行架構，僅從「中颱化」這個角度，談談銀行如果建中臺可能和阿里中颱有什麼不同。
一、阿里中臺簡介
本人最近有幸參加了一次單位組織的阿里培訓班，現場感受了「雲棲大會」精英們對技術的理解。培訓前後又讀了子柳老師的《**技術十年》和鍾華老師的《企業it架構轉型之道：阿里巴巴中臺戰略思想和架構實戰》，算是對阿里的中颱概念有個粗淺了解。阿里的中颱是個累積的過程，從2023年建立共享事業部開始，幾經曲折，但是一直在積累，直到2023年正式發展成中颱戰略。可見，這是個演化過程，這也符合一般對架構的認知，大型架構、好的架構都不是一蹴而就的設計，是根據實踐不斷磨合調整得來的。
目前的阿里中臺大約有十幾個共享業務單元，包括使用者中心、商品中心、交易中心等。**、天貓、聚划算等25個大型業務應用都是由中颱的共享業務單元支援的，共享業務單元則由阿里雲平台支援。共享業務單元的劃分原則其實不是可以簡單掌握的，要綜合考量設計、運營和工程因素，盡可能遵循「高內聚、低耦合」、「資料完整」、「業務可運營」和「漸進」的原則。阿里在劃分中颱時非常重視其業務價值和基於業務的設計，而且有業務架構崗位，每個共享單元都有業務架構師。但總體來講，其業務架構仍然是領域性的。這點在本人與阿里專家的交流過程中，他們也認為阿里仍然缺少更高一層的抽象，但是顯然這一層比較難於設計和維護。
阿里系統要解決的核心問題是高併發、可擴充套件，因此，業務通過中臺進行共享支援後，基礎設施必須能夠消解這種壓力。阿里採用去中心（也就是去esb）的hsf分布式服務框架，以支援服務的點對點呼叫，解決esb可能產生的瓶頸問題；採用微服務設計方式，提高變化響應；自研設計了分布式資料層框架tddl（taobao distributed data layer）以及分布式資料庫drds；研發了支援分布式事務處理的aliware txc；支援高效故障定位和運維監控的鷹眼平台；實現了限流和優雅降級設計，以及做保障的全鏈路壓測平台、業務一致性平台。這是一套完整的基礎設施，提供針對電商業務特點的支援。
總結起來，阿里中颱是其自身在業務不斷發展的過程中演進和磨合出的架構，其架構即體現了電商的業務特色，也包含了完整的技術支援體系。由於其靈活支援和快速響應能力，成為了網際網路架構的優秀實踐案例和設計標桿。
二、銀行的中颱可能會怎麼建？
銀行在與網際網路企業的競爭中倍感壓力，在金融科技的浪潮下紛紛推進數位化轉型工作，這個過程中，自然想要學學網際網路企業，特別是阿里這類頭部企業的經驗。阿里的中颱提高了服務的復用能力和開發效率，銀行是否能參考構建乙個通用框架呢？要注意哪些區別呢？
銀行如果嘗試構建金融行業通用框架，首先要解決的是流程問題。電商的中颱其實更容易抽象些，阿里的十幾個共享業務中心其實非常具有行業通用性，電商的在流程方面比較容易接受改變，在阿里提供大中台支援的前提下，無論是阿里內部還是輸出給其他同業客戶，流程方面都會比較容易接受改進，電商領域是在比較接近的流程下，尋找能力上、服務上的特色。
但銀行卻不是這樣，銀行的能力是高度同質化的，但是流程卻各不相同，因為流程的背後是組織結構和部門利益，各個銀行之間部門設定和職責邊界都是有差別的，按照康威定律，這種差別會直接體現在系統結構上。銀行都想談轉型，但真能為此大動干戈、大幅調整組織結構的很少，就是採購商用軟體，也通常是按照自己的部門結構進行本地化改造，將組織烙印深深地打在系統上。
這種差別下，銀行的中颱沉降過程可能會更多地面向功能沉降，在流程與能力解耦的原則下，將流程分離成微服務架構層，但是剝離可通用的能力作為中臺服務層，而不一定適合像阿里那樣構建為業務中臺，因為吸收變化的點不同。參考的架構圖如下：
銀行多是以產品驅動的，這點在設計上其實並不是一定要隨著「以客戶為中心」這種導向而改變，因為產品即服務、服務即產品，並不需要太糾結。
產品通常意味著會驅動後台的一系列服務和功能。在esb下，這是不同服務間的資訊流轉，其實阿里去掉esb並不意味著銀行也都要去掉esb，這要看實際需要，如果沒有那麼大的併發量、沒有那麼嚴重的堵塞要擔心，也就沒必要非乾掉esb，尤其是在銀行自己已經使用熟練的情況下，畢竟微服務架構下是否一定排除esb也是有不同聲音的。訊息佇列下，其實乙個產品就意味著相關服務的一組訂閱發布。
然後可以將銀行的產品按較大的流程環節進行微服務切分，這種流程可能會在不同的銀行有差別，有些業務a銀行有預處理過程，b銀行卻沒有；有些流程，a銀行乙個部門搞定，b銀行卻要兩三個部門協作。這些差異可能是內部文化的原因，也可能是規模的差異。而乙個銀行自己也可能會隨著規模的變化、業務重點的變化而調整，其實「能力」變化不大，但是流程卻可能變化較大。所以，將流程環節設計成乙個微服務層，便於快速變化。
再將可以相對穩定的業務功能，比如示例中的久期計算、缺口計算之類的較為通用，和評級計算、eva這些相對有變化，但不需要非得和流程攪在一起的功能，可以考慮沉降為中颱服務。服務盡可能無狀態，以方便遷移和改造。
資料則是企業級後台。微服務的處理結果準實時更新至企業級資料庫，中臺服務可以在企業級資料庫中查詢準實時資料，實時資料則可由呼叫方提供。
上述過程是以通用框架為目標進行描述，但如果是銀行自主研發，自研自用，一樣也可以參考。
銀行學習網際網路架構還應注意，阿里中颱是按照base原則的最終一致性設計的，而銀行傳統上是採用acid的強一致性。
上述建議是圍繞中颱化開展的討論，銀行學習網際網路架構，還應注意乙個非常重要的差別，但是這個不在技術範疇內，這就是企業的組織結構和內部文化。阿里的中颱是與其組織結構和企業文化共同成長的，如果想要移植其設計並且具有阿里的效果，那首先自己的內部要過關，技術也是有其生長土壤的。阿里對業務架構的重視，也恰恰是很多銀行需要認真思考的。
阿里中臺介紹
1，技術中臺提供了自建系統部分的技術支撐能力，幫助我們解決了基礎設施，分布式資料庫等底層技術問題，為前台特種兵提供了精良的 裝備。2，移動中臺提供了戰場一線火力支援能力，幫助我們提供更加個性化的服務，增強使用者體驗，為戰場提供了陸軍支援能力，隨機應變，所向披靡。3，業務中臺提供重用服務，例如使用者中...
阿里資料中臺建模
阿里中颱的概念，可以說是近些年來的頗為火爆的概念。從十餘年前的阿里在內部完成這一過程，並提出了 中臺 概念 到後面中臺概念逐步被外部接受並在2019年爆火興起。資料中颱爆火背後，既有傳統企業轉型焦慮的市場東風，又有阿里中臺戰略示範效應的推波助瀾。下圖為阿里中臺架構 來自網路 其內建 大中台 小前台 ...
銀行資料中颱的資料價值，銀行資料中臺建設實踐案例
在大資料 人工智慧 區塊鏈等新興技術的驅動下，各家銀行紛紛利用新技術制定數字轉型改革戰略，尋找差異化經營的可行模式。中臺概念 早期是由美軍的作戰體系演化而來的，技術上說的 中臺 主要是指學習這種高效 靈活和強大的指揮作戰體系。國內阿里巴巴約2017年左右對外率先提出資料中颱的概念，在技術層面指通過資...