2015年阿里巴巴集團啓動了中臺戰略，目標是要構建符合互聯網大數據時代的，具有創新性、靈活性的“大中臺、小前臺”的機制，即作爲前臺的一線業務能更敏捷、更快速的響應瞬息萬變的市場，而中臺將集合整個集團的運營能力，技術能力，對各前臺業務形成強有力的支撐。
那阿里集團爲什麼要建立一個“大中臺、小前臺”的架構呢？我們從阿里共享業務事業部的發展史說起。起初，阿里只有一個淘寶事業部，後來成立了天貓事業部，此時淘寶的技術團隊同時支撐着這兩個事業部。當時的淘寶和天貓的電商系統像我們很多大型企業的一樣是分爲兩套獨立的煙囪式體系，兩套體系中都包含的有商品、交易、支付、評價、物流等功能。因爲上述原因，阿里集團又成立了共享業務事業部，其成員主要來自之前的淘寶技術團隊，同時將兩套電商業務做了梳理和沉澱，將兩個平臺中公共的、通用的業務功能沉澱到共享事業部，避免重複建設和維護。後來上線的聚划算、1688、菜鳥物流等業務，均是基於這個“大中臺，小前臺”思路建設的。
上面說到的煙囪式的系統架構，相信IT行業的朋友們都有過親身經歷。我們來總結一下這個模式的弊端主要有哪些：
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行業最爲炙手可熱的名詞，很多企業甚至將互聯網轉型的期望完全寄託到大數據上，企業紛紛上馬大數據項目。但多數項目在落地實施時卻很難，主要有兩個問題：一是數據分佈廣、數據模型和標準不統一。需要進行數據層的打通、權限的控制、格式的轉換、以及數據的清洗和轉換等一系列複雜的工作；二是缺少“數據科學家”。也就是說人件，項目只有強大的軟件和硬件支持是遠遠不夠的。更重要的是要有能基於對業務的理解提出對大數據平臺需求的專家。此類專家需要懂數據採集、懂數學算法、懂分析、懂預測、懂市場應用…這樣的專家對任何企業來說都是難尋的，就算你的公司財大氣粗，可以把某某公司的專家挖過來，但他來到另外一個行業，另外一個公司，遇見另外一個全新的系統，由於對你公司的業務和技術熟悉程度較低，還是很難短時間帶來效益。而共享服務體系能很好的幫助企業培育出懂業務的專家，這些人員在自身擁有不錯的技術功底的前提下，加上對業務熟悉度的不斷提升，使之纔有希望成爲能發揮大數據平臺價值的“數據科學專家”。
結合當前我部門主營的系統，我覺得我們完全是可以借鑑這種中臺戰略思想來規劃和建設我們的新一代系統的。
首先把當前系統中各個業務的前端應用與後端服務解耦。將各個功能中的服務能力進行梳理、並沉澱。例如我們財務系統的生成憑證功能，據我所知，現在CBE，SSP，電子發票等都有這個功能，爲何不把它獨立出來一個通用的服務供大家調用？將重複、類似的服務進行整合，同時在單個服務的完善和增強的過程中注意服務的通用性，就可以避免其他相似“雙胞胎”服務的出現。
最後說一點，由於服務能力的集中管控，很大程度會促進我們一體化運維的能力，但在“大中臺、小前臺”的模式下，每一個服務都負責對N多個前端業務應用提供支持，這就要求運維在信息安全、備份、監控等方面要有更強的能力。