阿里炒火的「中台」概念究竟是什麼？

作者 | 付曉岩

編輯 | Tina

很多企業都將促進業務與科技的深度融合作為發展戰略，也都想學學阿里的中台戰略，其實，除了中台戰略之外，基於企業級業務架構設計來實現組件化開發也是企業數字化轉型的優選路徑，是彌合業務與技術之間「數字鴻溝」的有效手段。未來，業務不再僅僅是業務，技術也不再僅僅是技術，誰先實現思維方式的改進，誰能更好地聯動整個企業，誰就能贏得競爭的先手，而業務架構能力可以在這方面發揮關鍵作用，而且是超越中台之上的作用。

阿里中台

阿里的中台是個累積的過程，從 2009 年建立共享事業部開始，幾經曲折，但是一直在積累，直到 2015 年正式發展成中台戰略。可見，這是個演化過程，這也符合多數人對架構的認知：大型架構、好的架構都不是一蹴而就的設計，是根據實踐不斷磨合調整得來的。

阿里的中台大約有十幾個共享業務單元，包括用戶中心、商品中心、交易中心等。淘寶、天貓、聚划算等 25 個大型業務應用都是由中台的共享業務單元支持的，共享業務單元則由阿里雲平台支持。共享業務單元的劃分原則其實不是可以簡單掌握的，要綜合考量設計、運營和工程因素，儘可能遵循「高內聚、低耦合」、「數據完整」、「業務可運營」和「漸進」的原則。阿里在劃分中台時非常重視其業務價值和基於業務的設計，而且有業務架構崗位，每個共享單元都有業務架構師。但總體來講，其業務架構仍然是領域性的。這點在本人與阿里專家的交流過程中，他們也認為阿里仍然缺少更高一層的抽象，也就是常說的企業級業務架構，但是顯然這一層比較難於設計和維護。

阿里系統要解決的核心問題是高並發、可擴展，也就是說，規模帶來的複雜度對阿里而言更具挑戰性。因此，業務通過中台進行共享支持後，基礎設施必須能夠消解這種壓力。阿里採用去中心（也就是去 ESB）的 HSF 分散式服務框架，以支持服務的點對點調用，解決 ESB 可能產生的瓶頸問題；採用微服務設計方式，提高變化響應，並通過大力推行 DDD（領域驅動開發）設計模式，提升設計效率；自研設計了分散式數據層框架 TDDL（Taobao Distributed Data Layer，又稱「頭都大了」）以及分散式資料庫 DRDS；研發了支持分散式事務處理的 AliWare TXC；支持高效故障定位和運維監控的鷹眼平台；實現了限流和優雅降級設計，以及做保障的全鏈路壓測平台、業務一致性平台等。這是一套完整的基礎設施，提供針對電商業務特點的支持。

總結起來，阿里中台是其自身在業務不斷發展的過程中演進和磨合出的架構，其架構即體現了電商的業務特色，也包含了完整的技術支持體系。由於其靈活支持和快速響應能力，成為了互聯網架構的優秀實踐案例和設計標杆。也正因如此，目前很多人提到「中台戰略」基本上就會想到阿里，畢竟他們是主打這張「牌」的。

中台背後

互聯網行業歷來有「勝者通吃」的傳統，阿里如今在業務和技術上的成功也使得「中台」這個詞名聲大噪，好像一顆「銀彈」就此誕生了。應該說，阿里確實很成功，業務規劃做的很好，符合自身行業特點和需要；技術上獨步青雲，因為有些場景只有他們有，也只有他們做到了。目前阿里在開源和標準制定方面也走在第一線，「雲棲大會」紅紅火火，IEEE 的區塊鏈金融標準制定工作也有阿里一份，阿里更是在 JAVA 標準方面做了很多世界範圍的工作，為軟體領域做了很多貢獻。但是，熟悉架構設計的朋友也都很清楚，軟體工程上是沒有「銀彈」的，而阿里的優秀也不是學學「中台」就可以移植的。

2018 年 12 月份，我跟阿里的高級管理人員、開發人員又有了一些接觸，使我對阿里的認知又深入了一些，不過我畢竟是個「外人」，有些說法難免有失偏頗。

從我的了解來看，阿里技術上的成功離不開其滴水穿石般逐漸形成的企業文化。

阿里在管理上首先有個明確的「底線」，也就是對誠信問題的「零容忍」和帶有末位淘汰性質的考核機制，「底線」把員工「逼」到了一個必須有較強自律性、自我負責的狀態；

其次是有一個開放的「上限」，阿里的員工晉陞主要是拼個人實力，每年有評審時間，每個人要通過方案講解等方式向評委會展示自己的年度成果，打分夠了就晉陞，而不會像一般大型企業那樣有各類明的、暗的類似於晉陞限制，並且有多種序列供員工選擇，前中後台，不同條線的員工大致都可以達到相同的晉陞高度，方便員工轉崗；

「底線」和「上限」之間就是鼓勵培養濃厚創新精神和好奇心。

這樣一套體制可以讓員工相信憑自己的實力能夠贏得一片天地，而這種氛圍，可以讓很多傳統企業，甚至在一些互聯網企業、科技企業中也存在的組織壁壘、部門主義、人浮於事、推諉扯皮等問題，得到一定程度的解決，儘管不會完全消除。應該說，阿里這些年的成功，包括中台戰略的落地在內，與這種企業文化的逐漸形成和穩固是分不開的，如果只是照搬阿里的中台技術，那麼學習者可能只是獲得了一套工具、一套技術棧，並不會真的改變自己。而且，有一點也不得不提及的，如果企業的業務規模遠達不到阿里這麼大，那麼有些技術手段或者工具其實發揮不出最大價值，但依然要付出一定的學習和遷移成本。獲得一把狙擊步槍並不代表你就成了狙擊手，學習阿里中台，也要在一定程度上學習能夠讓技術真正發揮其價值的環境，不要僅僅關注技術本身。對於大多數企業而言，都需要認真從自身的角度出發去考慮業務和技術的發展規劃問題。

中台之上

阿里其實挺重視業務架構設計的，每個共享單元都有自己的業務架構，這恰恰是很多企業沒有的。業務架構本身是一個有著二十多年歷史卻依舊不溫不火的領域，但是在阿里卻發展的挺好，雖然他們的建模方式選擇的是 DDD 方法。DDD 方法是一種從業務設計直通技術設計的系統分析方法，但其特點是面向領域級，對企業級設計支持有限，阿里對該方法的使用也證明了這一點。2018 年 12 月的 DDD 峰會上，除了阿里等公司實踐介紹外，也出現了一個業務架構專場，講的是畫布分析法。

應該說，隨著軟體設計的發展，人們對標準化、可復用設計方向的追求日益強烈，而近年對業務與技術深度融合的要求不斷提升，重視業務架構的人也在不斷增多。數字化社會、數字化轉型已經不再是新名詞，但是很多企業在這方面投入不菲，收效卻不高，究其根本，多是在業務架構上下的力氣太少，而在缺乏清晰規劃的情況下對技術又依賴過重、寄望太高，導致了業務向技術傳導的不暢和技術對業務的理解不深，使雙方無法順利「牽手」。很多技術人員依然保持著「業務的歸業務、技術的歸技術」這種設計思想，割裂了業務和技術之間的有機聯繫，而業務人員也苦於無法深入理解設計，往往對實現「一頭霧水」，無法幫助技術人員合理應用新興技術。

業務架構是連接企業頂層戰略和技術實現的橋樑，是連接業務人員和技術人員的橋樑，業務架構基於企業目標進行業務能力和流程的整體規劃，對業務能力進行標準化、組件化，實際上，遵循業務架構設計方法，不斷基於自身的實踐進行積累和調整，任何企業都能發現適合自己的架構，包括適合自己的「中台」規劃，之後再根據企業業務規模和發展預期選擇合適的技術棧。

業務架構並非「銀彈」，因為你不能簡單照搬別人企業的架構套在自己身上。它是一面鏡子，鏡子中照出的只能是你自己，而照鏡子的過程也是一個「賦能」的過程，賦予你認清自己的能力，「自知者明」。沒有這個過程，企業很難選擇出適合自己的發展方向和能力建設方向，更別提企業轉型了。

業務架構真正的威力還是在企業級業務架構的構建上，這個過程足以將一個企業完整、深刻地聯結在一起，這不是領域級設計可以解決的問題，是真正的「中台之上」。

作者介紹

付曉岩，原國有大行資深業務架構師，負責業務架構設計、項目管理，熱衷新技術探索與實踐，具有豐富的銀行業務經驗和企業級項目業務架構設計經驗，曾主導客戶關係、金融市場、同業、資管、養老金等多個領域核心系統的業務架構設計。公眾號：曉談岩說。

本文是 InfoQ 出品的《撥開迷霧說中台》專題的第 1 篇，本專題共 16 篇，分別就阿里中台戰略與其獨特文化的關係、企業中台戰略如何考慮業務和技術的平衡、為什麼業務架構存在 20 多年技術人員還覺得它有點虛等方面進行深入剖析。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！