中臺打破了應(yīng)用系統(tǒng)的壁壘，從企業(yè)全局梳理和規(guī)劃業(yè)務(wù)程，重構(gòu)了組織架構(gòu)、業(yè)務(wù)架構(gòu)與IT 架構(gòu)。
在梳理了企業(yè)的IT 現(xiàn)狀并回顧了SOA 的歷史之后，我們需要對中臺架構(gòu)進行一番詳細的介紹，阿里巴巴的Aliware 團隊曾經(jīng)給中臺下過這樣的定義：
將企業(yè)的核心能力隨著業(yè)務(wù)不斷發(fā)展以數(shù)字化形式沉淀到平臺，形成以服務(wù)為中心，由業(yè)務(wù)中臺和數(shù)據(jù)中臺構(gòu)建起數(shù)據(jù)閉環(huán)運轉(zhuǎn)的運營體系，供企業(yè)更高效地進行業(yè)務(wù)探索和創(chuàng)新，實現(xiàn)以數(shù)字化資產(chǎn)的形態(tài)構(gòu)建企業(yè)核心差異化競爭力。
現(xiàn)在中臺戰(zhàn)略常被簡單地概括為“大中臺，小前臺”，意思是說將企業(yè)的核心業(yè)務(wù)能力沉淀和聚集到由業(yè)務(wù)中心組成的中臺層上，前臺應(yīng)用以中臺為支撐，向輕量化、敏捷化轉(zhuǎn)變。本文核心觀點援引自作者所著的《大數(shù)據(jù)平臺架構(gòu)與原型實現(xiàn)：數(shù)據(jù)中臺建設(shè)實戰(zhàn)》一書，全書對數(shù)據(jù)中臺的理念、架構(gòu)和具體實現(xiàn)做了詳細論述。
圖1 是《企業(yè)IT 架構(gòu)轉(zhuǎn)型之道：阿里巴巴中臺戰(zhàn)略思想與架構(gòu)實戰(zhàn)》一書中給出的關(guān)于中臺戰(zhàn)略非常形象的描述。這張圖描述的是美軍現(xiàn)行的作戰(zhàn)模式，在一線戰(zhàn)場，美軍通常以班為單位組織軍事行動，這種極小型團隊行動敏捷，容易捕獲戰(zhàn)機，一旦發(fā)現(xiàn)敵情就通過指揮系統(tǒng)呼叫強大的炮火和空中支援給敵軍以重創(chuàng)。美軍的這種戰(zhàn)場組織陣型與中臺架構(gòu)的思想是一致的，戰(zhàn)斗小組就是“小前臺”，強大的炮火群和空中力量是“大中臺”。在強大中臺的有力支撐下，前端在進行業(yè)務(wù)運營和創(chuàng)新時會變得非常高效且靈活，企業(yè)可以根據(jù)最新的市場動態(tài)展開各種嘗試和調(diào)整，一旦發(fā)現(xiàn)并驗證了新的市場機遇，就可以調(diào)集中臺的強大能力迅速跟進，搶占市場。
中臺作為面向互聯(lián)網(wǎng)時代的企業(yè)新一代IT架構(gòu)最大的威力不在于解決眼前的問題，而是系統(tǒng)性、結(jié)構(gòu)性地重組企業(yè)的IT 生態(tài)系統(tǒng)、業(yè)務(wù)架構(gòu)及組織架構(gòu)，它能幫助企業(yè)從本質(zhì)上提升競爭力，降低成本。它將帶給企業(yè)如下的能力與收益：
以中臺的視角看待企業(yè)的整個IT 生態(tài)，可以將其分成前臺、中臺及后臺三大組成部分，三者的定位如下：
前臺與中臺的關(guān)系是：業(yè)務(wù)中臺負責(zé)提供企業(yè)范圍內(nèi)共享的基礎(chǔ)業(yè)務(wù)服務(wù)，前臺應(yīng)用會對這些基礎(chǔ)業(yè)務(wù)服務(wù)進行組織編排，快速地在前端以產(chǎn)品形式將業(yè)務(wù)能力展開，以適應(yīng)日新月異的市場變化。
中臺與后臺的關(guān)系并不像前臺與中臺的關(guān)系那樣緊密，中臺架構(gòu)是為了讓企業(yè)擁有開放、創(chuàng)新和靈活的市場應(yīng)變能力而提出的，這對于生產(chǎn)、庫存、物流等后端系統(tǒng)的影響并不大，并且這些系統(tǒng)需要嚴(yán)謹(jǐn)和規(guī)范的組織與管理，因而會保持相對傳統(tǒng)的組織架構(gòu)與生態(tài)。
由此可見，中臺在企業(yè)的整體業(yè)務(wù)體系中起著核心作用，而建設(shè)中臺的最大挑戰(zhàn)也來自對中臺層各服務(wù)中心業(yè)務(wù)能力的提煉和萃取。
以零售和消費品行業(yè)的企業(yè)為例，往往會有如下一些面向市場和終端消費者的服務(wù)中心：
用戶中心：負責(zé)用戶信息的全面管理，建設(shè)和維護會員體系，制定并推行會員運營策略；
商品中心：負責(zé)商品的全面管理，包括SKU、品類及商品相關(guān)的各種屬性、標(biāo)簽的管理；
交易中心：負責(zé)統(tǒng)一管理線上和線下所有的購物車、訂單及交易數(shù)據(jù)，并提供交易相關(guān)的各種服務(wù)；
以上四個是比較有代表性的業(yè)務(wù)中心，每一家企業(yè)還可能會基于自己的業(yè)務(wù)模式組織其他諸如支付、門店、內(nèi)容、促銷等中心。從服務(wù)中心的職責(zé)和定位我們也可以發(fā)現(xiàn)中臺的一個重要特征，那就是應(yīng)用系統(tǒng)的邊界被徹底地打破了，不會再有CRM 和OMS 這樣的孤立業(yè)務(wù)系統(tǒng)了，而是將它們所承載的共享業(yè)務(wù)能力分拆并重組到了各個業(yè)務(wù)中心，每個業(yè)務(wù)中心對接和服務(wù)的是來自企業(yè)全渠道的需求，如何能支撐這些復(fù)雜多變的前端需求是建設(shè)中臺的挑戰(zhàn)之一。針對每個業(yè)務(wù)中心，在業(yè)務(wù)和技術(shù)上都必須要有專業(yè)的架構(gòu)師帶領(lǐng)團隊來統(tǒng)一梳理這些需求，識別哪些需求應(yīng)該由中臺實現(xiàn)，哪些需求應(yīng)該由前臺實現(xiàn)，這是確保中臺架構(gòu)能夠合理存在并穩(wěn)定發(fā)揮作用的重要前提，這個過程不會一蹴而就，而需要在不斷的迭代和試錯中逐漸明了。不難想象，如果這種切分不夠合理就會出現(xiàn)如下兩種結(jié)果：
如果本應(yīng)屬于共享的服務(wù)與邏輯切分到前臺，就會導(dǎo)致前臺應(yīng)用過“重”，且不可避免地會出現(xiàn)重復(fù)建設(shè)問題，因為前臺應(yīng)用無法從中臺獲得相關(guān)支持；
如果過多的非共享服務(wù)與邏輯切分到中臺，就會導(dǎo)致中臺服務(wù)的復(fù)用性變差，前臺應(yīng)用無法直接調(diào)用，因此會產(chǎn)生很多“副作用”和“連帶后果”。
以上兩種情形在現(xiàn)實里時有發(fā)生，這是企業(yè)打磨中臺的一個必經(jīng)階段，也是團隊磨煉對業(yè)務(wù)認知和對技術(shù)把控能力的一場“修行”。
就“服務(wù)”這個概念而言，中臺對外提供的“服務(wù)”與SOA 中倡導(dǎo)的“服務(wù)”并沒有本質(zhì)上的差別。在某種程度上，中臺的定位會更加有助于實現(xiàn)真正可重用的“服務(wù)”，因為中臺不再局限于某一個應(yīng)用上，而是超脫于應(yīng)用之上，宏觀地看待一個“服務(wù)”如何能支持不同場景下的共性需求。因此，那些在SOA 中對服務(wù)粒度進行界定和組織的方法依然是值得借鑒的，特別是對基礎(chǔ)服務(wù)、復(fù)合服務(wù)及業(yè)務(wù)流程服務(wù)這三個服務(wù)層次的劃分是非常實用的。
作為一個呼應(yīng)，我們來看一下中臺架構(gòu)下“會員管理”是如何進行的：原有的CRM 系統(tǒng)將不復(fù)存在，取而代之的是“用戶中心”，用戶中心沉淀了與用戶相關(guān)的共享服務(wù)，會員注冊就是其中之一，前臺應(yīng)用系統(tǒng)進行會員注冊時會調(diào)用用戶中心上的會員注冊API 來實現(xiàn)，當(dāng)然，前臺應(yīng)用可能需要對用戶數(shù)據(jù)進行一定的處理、轉(zhuǎn)換以適配統(tǒng)一的API 規(guī)范，這樣前臺各個應(yīng)用不再維護自己的“用戶模塊”，因此也不再需要同步會員數(shù)據(jù)。
前面我們討論的“中臺”更具體地說是指業(yè)務(wù)中臺，對于中臺的另一個組成部分“數(shù)據(jù)中臺”來說，它更側(cè)重于企業(yè)數(shù)據(jù)的統(tǒng)一收集和處理。相對于應(yīng)用系統(tǒng)而言，數(shù)據(jù)的平臺化要相對容易一些，這也是很多企業(yè)早期就能建立數(shù)倉這種中心化、平臺化的系統(tǒng)，而在應(yīng)用系統(tǒng)上卻陷入煙囪式的生態(tài)的原因之一。不過數(shù)據(jù)中臺并不是傳統(tǒng)數(shù)倉升級換代那么簡單，從技術(shù)上講，數(shù)據(jù)中臺完全構(gòu)建在大數(shù)據(jù)平臺上，數(shù)倉是數(shù)據(jù)中臺的重要組成部分，但遠遠不是全部。數(shù)據(jù)中臺通常還要具備實時的數(shù)據(jù)處理能力和高級的算法分析能力，當(dāng)數(shù)據(jù)處理完成后，數(shù)據(jù)中臺還要提供強大的“數(shù)據(jù)服務(wù)”，能將結(jié)果數(shù)據(jù)通過各種協(xié)議以實時或批量的方式提供給業(yè)務(wù)中臺或應(yīng)用前臺。
此外，業(yè)務(wù)中臺的建立也會對數(shù)據(jù)中臺的建設(shè)起到很大的促進作用。一方面由于業(yè)務(wù)的梳理和中心化，使采集業(yè)務(wù)數(shù)據(jù)變得相對簡單，業(yè)務(wù)中心的后臺數(shù)據(jù)庫將是數(shù)據(jù)中臺主要的外圍數(shù)據(jù)源；另一方面，業(yè)務(wù)中臺對業(yè)務(wù)的切分和領(lǐng)域建模將對構(gòu)建數(shù)據(jù)中臺上的數(shù)倉和數(shù)據(jù)服務(wù)有很大的指導(dǎo)意義，例如，每個業(yè)務(wù)中心天然就是一個大的數(shù)據(jù)主題，相應(yīng)地，也有會有一個獨立的API 的namespace 等。
下面我們把業(yè)務(wù)中臺和數(shù)據(jù)中臺放在一起，結(jié)合前面舉例的零售和消費品行業(yè)來看看一個完整的中臺架構(gòu)，如圖2 所示。
這是一張混合了技術(shù)和業(yè)務(wù)的中臺邏輯架構(gòu)示意圖，前臺應(yīng)用部分我們將零售和消費品行業(yè)需要對接消費者的若干應(yīng)用系統(tǒng)一一列舉了出來，但是在中臺架構(gòu)下它們已經(jīng)和傳統(tǒng)的“應(yīng)用系統(tǒng)”有了很大的差別，變得非?！拜p量”。過去很多自行實現(xiàn)的業(yè)務(wù)功能都通過調(diào)用業(yè)務(wù)中臺的各個業(yè)務(wù)中心完成了，如前面列舉的會員注冊功能，在中臺架構(gòu)下都是調(diào)用會員中心上的統(tǒng)一接口完成的。與此同時，各業(yè)務(wù)中心的數(shù)據(jù)都將通過數(shù)據(jù)中臺上的數(shù)據(jù)采集組件采集到大數(shù)據(jù)平臺上，然后通過批處理和實時處理機制構(gòu)建出企業(yè)的數(shù)倉體系和高級數(shù)據(jù)分析能力，最后通過構(gòu)建數(shù)據(jù)API （Web 服務(wù)）、OLAP 及專有的報表數(shù)據(jù)庫等手段，將結(jié)果數(shù)據(jù)以Restful API、JDBC/ODBC 或FTP 等形式提供給外部使用。
中臺由阿里巴巴提出并在業(yè)界獲得廣泛認可之后，阿里巴巴就一直希望通過阿里云平臺向企業(yè)用戶推廣一整套的中臺技術(shù)解決方案，這套方案就是Aliware——面向企業(yè)級互聯(lián)網(wǎng)架構(gòu)的PaaS 服務(wù)。Aliware 包含了企業(yè)級分布式應(yīng)用服務(wù)（EDAS）、消息隊列（MQ）、全局事務(wù)服務(wù)（GTS）等，這些服務(wù)涵蓋了企業(yè)應(yīng)用開發(fā)涉及的各個方面。但是中臺并非必須構(gòu)建在阿里云的這些PaaS 服務(wù)上，實際上，Aliware 是將當(dāng)前企業(yè)級應(yīng)用開發(fā)的主流技術(shù)和框架封裝成PaaS 服務(wù)供開發(fā)者直接使用，所以本質(zhì)上Aliware 與中臺架構(gòu)并沒有必然的關(guān)系。
中臺作為一種生態(tài)系統(tǒng)級的架構(gòu)，不會受底層技術(shù)的制約，反而倚重和遵循業(yè)界主流的技術(shù)體系，特別是開源的技術(shù)平臺與框架。簡單地說：
與技術(shù)相配套的是設(shè)計思想和方法論，現(xiàn)在微服務(wù)的主流設(shè)計思想是領(lǐng)域驅(qū)動設(shè)計，大數(shù)據(jù)的主要設(shè)計思想是數(shù)據(jù)倉庫理論。我們來分別介紹一下這兩種技術(shù)與它們使用的設(shè)計理論。
微服務(wù)架構(gòu)最大的特征是解構(gòu)了過去的單體應(yīng)用，按照業(yè)務(wù)功能對系統(tǒng)進行了更細粒度的切分，每一個微服務(wù)都是一個可獨立部署的單元，微服務(wù)內(nèi)部高內(nèi)聚，微服務(wù)之間低耦合。系統(tǒng)被微服務(wù)化之后會在很多方面得到提升和改善，過去在單一應(yīng)用服務(wù)器和數(shù)據(jù)庫服務(wù)器上部署的系統(tǒng)將轉(zhuǎn)變?yōu)榧冋姆植际较到y(tǒng)，部署于多臺服務(wù)器上，這相當(dāng)于賦予了系統(tǒng)水平伸縮能力，同時局部節(jié)點的失效也不會再導(dǎo)致整個系統(tǒng)宕機，而是可以被限制在有限影響范圍之內(nèi)。
微服務(wù)的這些優(yōu)勢使其在最近幾年幾乎成了企業(yè)級應(yīng)用的架構(gòu)標(biāo)準(zhǔn)，與之相配套的是一系列基礎(chǔ)設(shè)施服務(wù)和支撐技術(shù)。
經(jīng)過多年的沉淀和積累，業(yè)界在上述領(lǐng)域有很多成熟工具和框架，其中最主流的一站式方案非Spring Cloud 莫屬。
在微服務(wù)架構(gòu)逐漸形成規(guī)模之后，就會對硬件資源虛擬化和自動化部署提出要求，與此同時，伴隨著Docker 的崛起，人們發(fā)現(xiàn)容器化與微服務(wù)是一組絕佳搭檔，再配合DevOps 技術(shù)的推動，最終在業(yè)界形成了“微服務(wù) + 容器技術(shù)（Dockers + Kubernetes）+ DevOps”三位一體的微服務(wù)生態(tài)體系，這些技術(shù)匯集在一起為微服務(wù)的落地和持續(xù)演進鋪平了道路。
恰到好處的微服務(wù)設(shè)計是一項很有挑戰(zhàn)性的工作，識別、界定與設(shè)計微服務(wù)考驗的是開發(fā)人員對業(yè)務(wù)的理解和設(shè)計能力，這需要對業(yè)務(wù)反復(fù)梳理和提煉，再經(jīng)過仔細地斟酌和拿捏才能有一個比較好的方案。這與技術(shù)框架沒有太大的關(guān)系，考驗的是設(shè)計人員的“內(nèi)功心法”，也就是設(shè)計能力和對業(yè)務(wù)理解的透徹程度。以往諸多項目的經(jīng)驗表明，糟糕的設(shè)計會極大地削弱微服務(wù)的作用，讓其變得粗糙、難以被復(fù)用。過去，開發(fā)人員一直使用一些常規(guī)的方法論來設(shè)計微服務(wù)，如面向?qū)ο螅∣OD）的設(shè)計思想，但是取得的效果并不理想，直到后來領(lǐng)域驅(qū)動設(shè)計（Domain-DrivenDesign，也被簡稱為DDD）被社區(qū)發(fā)掘出來，逐漸成了微服務(wù)事實上的設(shè)計理論。
領(lǐng)域驅(qū)動設(shè)計最早起源于Eric Evans 在2003 年撰寫的一本名為Domain-Driven Design: Tackling Complexity in the Heart of Software 的著作，這本書全面系統(tǒng)地闡述了領(lǐng)域驅(qū)動設(shè)計的思想和方法論。早年間DDD 還較為小眾，沒有在業(yè)界得到推廣，但是伴隨著微服務(wù)的崛起，人們意識到領(lǐng)域驅(qū)動設(shè)計的諸多思想對于設(shè)計微服務(wù)有莫大的幫助，一個特別典型的例子就是根據(jù)限界上下文（Bounded Context）來劃定微服務(wù)邊界。
簡單總結(jié)一下，在技術(shù)上微服務(wù)是實現(xiàn)業(yè)務(wù)中臺的最佳技術(shù)方案，再借助領(lǐng)域驅(qū)動設(shè)計，中臺的業(yè)務(wù)中心可以構(gòu)建得足夠靈活和強大。
在數(shù)據(jù)中臺上，目前的技術(shù)選型也是非常統(tǒng)一的，基于Hadoop、Spark的大數(shù)據(jù)技術(shù)是當(dāng)前構(gòu)建數(shù)據(jù)中臺的主流方案，本系列也是以大數(shù)據(jù)技術(shù)為基礎(chǔ)來討論如何建設(shè)數(shù)據(jù)中臺的。
大數(shù)據(jù)涉及的技術(shù)非常多，在數(shù)據(jù)采集、存儲、消息隊列、批處理、實時處理、作業(yè)調(diào)度等諸多環(huán)節(jié)上都有對應(yīng)的技術(shù)和工具來完成相關(guān)工作，在后續(xù)的章節(jié)里我們會逐一討論它們，但通常人們會用Hadoop、Spark 來指代大數(shù)據(jù)技術(shù)，因為兩者不單單是技術(shù)，更代表著一個技術(shù)生態(tài)圈，在它們背后有一組相關(guān)的配套工具。
對于建設(shè)數(shù)據(jù)中臺的方法論（確切地說是數(shù)據(jù)中臺的批處理部分），傳統(tǒng)的數(shù)據(jù)倉庫理論依然是主要的方法論。數(shù)據(jù)中臺的使命是將企業(yè)的全域數(shù)據(jù)收集起來，然后規(guī)范地處理它們，最后給到前端應(yīng)用。對于如何規(guī)范地處理數(shù)據(jù)，目前業(yè)界最為成熟的理論是數(shù)據(jù)倉庫（數(shù)倉）。在經(jīng)過數(shù)倉體系的治理之后，最終會在數(shù)倉的最上層得到高質(zhì)量的數(shù)據(jù)集，然后通過Web Service、ODBC、JDBC等多種數(shù)據(jù)服務(wù)對外發(fā)布出去。
簡單總結(jié)一下，在技術(shù)上Hadoop、Spark 是實現(xiàn)數(shù)據(jù)中臺的主要技術(shù)方案，遵循數(shù)據(jù)倉庫理論對數(shù)據(jù)進行組織和處理，在最上層封裝為數(shù)據(jù)服務(wù)的形式去支持前臺和業(yè)務(wù)中臺對數(shù)據(jù)的需求。
