愈來愈火的"中臺"是什麼

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

阿里中臺

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

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

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

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

中臺背後

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

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

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

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

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

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

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

中臺之上

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

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

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

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

業務架構真正的威力仍是在企業級業務架構的構建上，這個過程足以將一個企業完整、深入地聯結在一塊兒，這不是領域級設計能夠解決的問題，是真正的「中臺之上」。

 

轉自：https://www.infoq.cn/theme/8?utm_source=wechat&utm_medium=infoq&utm_campaign=newinfoq&utm_content=0426theme8