《企業IT架構轉型之道-阿里巴巴中臺戰略思想與架構實戰》讀後感

轉至簡書：讀《阿里巴巴中臺戰略》-思企業IT架構之轉型
2015年阿里巴巴集團啟動了中臺戰略，目標是要構建符合網際網路大資料時代的，具有創新性、靈活性的“大中臺、小前臺”的機制，即作為前臺的一線業務會更敏捷、更快速的適用瞬息萬變的市場，而中臺將集合整個集團的運營資料能力，產品技術能力，對各前臺業務形成強有力的支撐。

那阿里集團為什麼要建立一個“大中臺、小前臺”的架構呢？我們從阿里共享業務事業部的發展史說起。起初，阿里只有一個淘寶事業部，後來成立了天貓事業部，此時淘寶的技術團隊同時支撐著這兩個事業部。當時的淘寶和天貓的電商系統像我們很多大型企業的一樣是分為兩套獨立的煙囪式體系，兩套體系中都包含的有商品、交易、支付、評價、物流等功能。因為上述原因，阿里集團又成立了共享業務事業部，其成員主要來自之前的淘寶技術團隊，同時將兩套電商業務做了梳理和沉澱，將兩個平臺中公共的、通用的業務功能沉澱到共享事業部，避免重複建設和維護。後來上線的聚划算、1688、菜鳥物流等業務，均是基於這個“大中臺，小前臺”思路建設的。如下圖所示：

1. 重複功能建設和維護帶來的重複投資。重複投資不僅消耗的是人力，財力，更重要的是時間！在目前高速發展的網際網路市場大環境下，商機是稍縱即逝的。

2. 打通煙囪式系統間互動的整合和協作成本高昂。各大企業不得不借助ESB產品，構建企業服務匯流排，打通各系統間的互動問題。當然，我們並非是要完全否定ESB系統，它的確是能在某種程度上實現系統間的互聯互通，但這種“中心化”的服務架構缺點也有不少。“中心化”架構的所有服務呼叫者和服務提供者之間的互動都必須通過這個中心點，而這個中心點的能力是很難進行擴充套件的；也許有人會說我可以通過增加中心服務匯流排例項的節點數量，以達到線性的擴充套件平臺能力。但這種做法其實過於理想化了，我來舉個例子，說明一下這種模式的“雪崩”隱患。假設企業的服務匯流排叢集數量是10臺，每個負載量是80%。當訪問峰值來臨時，有可能因為某一個應用的不規範呼叫或者某個服務提供者出現了異常，導致了其中1臺“罷工”。此時，服務路由壓力就落在了剩下9臺上，每臺的平均負載量就變成了88%（個別伺服器會更高），出現問題的概率就增加了。此時假設又有一臺不堪重負也“罷工”了，就會出現後面的8臺伺服器在訪問峰值時會瞬間被訪問洪流沖垮，這就是“雪崩效應”。（想起了原先公司經常出現的大面積宕機白屏…）

3. 不利於業務沉澱和持續發展。很多企業經常上演這樣的一幕：一個系統上線執行5、6年後，原先的系統升級改造已經不能滿足當下的業務發展訴求，需要整體升級，而這樣的升級往往意味著對原有系統推到重建，之前多年的業務服務能力沒有多少被沉澱下來，造成巨大的資產流失。

那“大中臺，小前臺”的共享服務體系到底有什麼優點呢？說到這，我先來給大家舉個例子吧。

大家都知道特種部隊在現代戰爭中是個狠角色，特種部隊強大的戰鬥力絕不僅僅是因為他們當中每個人都身體健壯、思維敏捷、百發百中，而是因為他們擁有一群強大的後盾來支援他們。特種部隊雖然人數不多，但可以調動鷹眼、武裝直升機、無人機、轟炸機、火箭、導彈、甚至是航空母艦。這就是為什麼他們十幾人可以打敗對方几百人上千人的原因。還有個簡單例子，一架飛機在天上飛行，通常機艙內只有1-2名飛行員，當飛機出現故障時，僅靠飛行員自己是無法快速、準確的定位問題、解決問題的。而地面指揮中心是有非常多的專家工程師，他們可以快速的幫助飛行員定位問題，並提出解決問題的方法。上述兩個例子就是“大中臺，小前臺”的典型應用，其中的“大中臺”就是把所有與勢能相關的公線資源全部收納，組成一個“火力中樞”。

我總結共享服務平臺體系的優點主要有如下幾點：

1. 服務可重用。通過鬆耦合的服務帶來業務的複用，不必為不同的前端業務開發各自對應的相同或者類似的服務。例如淘寶和天貓不必各自開都開發一個評價服務。

2. 服務被滋養。作者在書中提出了一個觀點：服務最不需要“穩定”。一個服務如果一味追求不變，那就是固步自封，就會逼著其他系統去建同樣的“輪子”。服務需要被滋養，不停的滋養，只有滋養才能最初僅提供單薄業務功能的服務逐漸成長為企業最為寶貴的IT資產，而服務所需的滋養正是來自新的業務不斷的接入。

3. 服務助創新。大家都知道創新不是一件容易的事情，因為有些本質上的創新按照傳統的開發模式是需要從分析、設計、開發，每一個環節都從0開始的，這樣一來就會導致投入成本大，開發週期長，可能等你開發完了，商機已經被別人搶佔了，公司領導可能考慮到上述因素就把你這個想法PASS掉了。而共享服務平臺中的諸多服務是經過清晰的沉澱，可以通過重新編排、組合，快速的響應市場，達成創新，武俠小說裡不常說天下武功，唯快不破嘛。

4. 服務敢試錯。說到試錯，其實試錯和創新有著千絲萬縷的關係，有時甚至可以劃等號，部分試錯是會變成創新的。共享服務平臺由於具備快速編排、組合服務的能力，可以以較小的成本投入來構建出一個新的前端業務，即使失敗了，公司損失也很小。這在傳統模式構建的系統中是幾乎不可能達成的。

5. 服務造BD。如今BIG DATE（大資料）成為近年來網際網路和IT行業最為炙手可熱的名詞，很多企業甚至將網際網路轉型的期望完全寄託到大資料上，企業紛紛上馬大資料專案。但多數專案在落地實施時卻很難，主要有兩個問題：一是資料分佈廣、資料模型和標準不統一。需要進行資料層的打通、許可權的控制、格式的轉換、以及資料的清洗和轉換等一系列複雜的工作；二是缺少“資料科學家”。也就是說人件，專案只有強大的軟體和硬體支援是遠遠不夠的。更重要的是要有能基於對業務的理解提出對大資料平臺需求的專家。此類專家需要懂資料採集、懂數學演算法、懂分析、懂預測、懂市場應用…這樣的專家對任何企業來說都是難尋的，就算你的公司財大氣粗，可以把某某公司的專家挖過來，但他來到另外一個行業，另外一個公司，遇見另外一個全新的系統，由於對你公司的業務和技術熟悉程度較低，還是很難短時間帶來效益。而共享服務體系能很好的幫助企業培育出懂業務的專家，這些人員在自身擁有不錯的技術功底的前提下，加上對業務熟悉度的不斷提升，使之才有希望成為能發揮大資料平臺價值的“資料科學專家”。

結合當前我部門主營的客服系統，我覺得我們完全是可以借鑑這種中臺戰略思想來規劃和建設我們的新一代系統的。

首先把當前系統中各個業務的前端應用與後端服務解耦。將各個功能中的服務能力進行梳理、並沉澱。例如我們從外呼業務中梳理出工單管理和問卷管理的能力；從知識庫中梳理出知識搜尋的能力；從85電商平臺中梳理出商品銷售和庫存管理的能力等等。然後將重複、類似的服務進行整合，同時在單個服務的完善和增強的過程中注意服務的通用性，避免其他相似“雙胞胎”服務的出現。由於服務能力的集中管控，很大程度會促進我們一體化運維的能力，但在“大中臺、小前臺”的模式下，每一個服務都負責對N多個前端業務應用提供支援，這就要求運維在資訊保安、備份、監控等方面要有更強的能力。