阿里中臺(大中臺小前臺)架構(gòu)詳解

1、第一章、大中臺小前臺戰(zhàn)略簡介什么是中臺？中臺的劃分阿里巴巴電商系統(tǒng)發(fā)展的四個階段什么是“大中臺，小前臺”戰(zhàn)略？“大中臺，小前臺”的由來第二章、中臺的定義技術(shù)中臺移動中臺EMAS研發(fā)中臺業(yè)務(wù)、數(shù)據(jù)“雙中臺” 組織中臺第三章、阿里各部分中臺介紹第四章、其他名企的中臺模型騰訊、海爾、滴滴目 錄2015年12月7日，時任阿里巴巴集團CEO的張勇通過一封內(nèi)部信說，“今天起，我們?nèi)鎲影⒗?巴巴集團2018年中臺戰(zhàn)略，構(gòu)建符合DT時代的更創(chuàng)新靈活的“大中臺、小前臺”組織機制和業(yè)務(wù) 機制。即從左邊的單項目單平臺，變成右邊的聯(lián)合中臺模式用戶提供服務(wù)項目A前臺項目B前臺項目A管理 后臺項目B管理 后臺提供配置

2、淘寶天貓支付寶聚劃算阿里媽媽阿里菜鳥盒馬生鮮用戶 中心商品 中心交易 中心評價 中心搜索 中心營銷 中心Aliware小前臺大中臺阿里巴巴提出來“大中臺，小前臺”的戰(zhàn)略什么是“大中臺，小前臺”戰(zhàn)略？“小前臺大中臺”的理論來自美軍的作戰(zhàn)理論。美軍目前的作戰(zhàn)單位都是11人以下小班排（類似前臺），而導(dǎo)彈智 慧系統(tǒng)類似于后臺。但是管理上的難度在于，后臺資源無法被前臺 直接有效使用，并且更新迭代遲緩。 設(shè)置“中臺”就是為了提煉前 臺共性需求，把后臺產(chǎn)品做成標準化組件供前臺部門使用 。01北歐游戲公司Supercell的超高人均產(chǎn)值背 后的組織設(shè)計02美軍的“特種部隊（小前臺）+航母艦群（大中臺）”模式阿

3、里巴巴的大中臺戰(zhàn)略主要來源于兩方面：Ilkka Paananen支付系統(tǒng)系統(tǒng)用戶開發(fā)工具數(shù)據(jù)分析基礎(chǔ)設(shè)施游戲引擎皇室戰(zhàn)爭部落沖突卡通農(nóng)場海島奇兵前臺中臺想了解更多關(guān)于美軍“ Team of Teams”的組織設(shè)計，可參考書蜜021賦能游騎兵排ranger platoon海豹突擊隊SEAL squads陸軍特種部隊Army Special Forces units中央情報局CIA美軍特遣部隊（the Task Force）剛 開始管理模式試著讓他們在一個將 他們都包含在內(nèi)的指揮系統(tǒng)下運作。但是這樣隨之而來帶來的各式的問題等待“ 最高指揮 官” 理清狀況及 反應(yīng)， 導(dǎo)致決策 延誤團隊開始互相競 爭

4、及保護他們的 資源和自己的優(yōu) 越性每支團隊都想表 現(xiàn)自認為最好的 一面， 即使那對 整體行動毫無用 處團 隊 之 間 的 問 題從1支專家 團隊交接到另1支 專家團隊很困難而這樣的敏捷團隊，被稱為“小前臺”，而他們都有一個統(tǒng)一的“中臺炮火 群”來支持這些敏捷團隊。美軍小隊中臺 炮火群中臺的定義中臺是支持多個前臺業(yè)務(wù)且具備業(yè)務(wù)屬性的共性能力組 織，平臺是支持多個前臺或中臺業(yè)務(wù)且不具備業(yè)務(wù)屬性 的共性能力。2. 中臺支持的是多個前臺業(yè)務(wù)。1. 中臺是一種共性能力組織，支持了多個業(yè)務(wù)。中臺的定義還要求以下兩點：對于很多企業(yè)來說，現(xiàn)在會用Hadoop的集群來儲存業(yè)務(wù)數(shù)據(jù)，但這個不能說是中臺，它頂多是一

5、 個數(shù)據(jù)平臺?，F(xiàn)在大家比較公認的數(shù)據(jù)中臺，指的是確保OneID、OneData得以實現(xiàn)的組織，使 得數(shù)據(jù)不再是各前端業(yè)務(wù)獨立管理，而是通過統(tǒng)一的團隊在數(shù)據(jù)標識、指標、數(shù)據(jù)倉庫等方面 實現(xiàn)了跨業(yè)務(wù)的整合。之所以這樣大家會認為是名符其實的數(shù)據(jù)中臺，是因為指標一定是面 向 業(yè)務(wù)的，數(shù)據(jù)倉庫的建設(shè)一定也包含了一些業(yè)務(wù)邏輯。所以那個大大的Hadoop并不是數(shù)據(jù)中 臺 ，而是大數(shù)據(jù)平臺。1. 沒有業(yè)務(wù)屬性的不是中臺。如果只能支持一個業(yè)務(wù)的，只能稱為一個業(yè)務(wù)后臺，而中臺是為效率而生，它 的特性就是整合多種功能在一起，能夠同時支持多個業(yè)務(wù)發(fā)展的中間件。2. 只支持一個業(yè)務(wù)的能力不能稱為中臺業(yè)務(wù)中臺在前文中反復(fù)

6、提及，就是把各個項目的共通業(yè)務(wù)進行下沉，整合成通用的服務(wù)平臺項目A項目B項目C支付 中心商品 中心營銷 中心搜索 中心用戶 中心交易 中心前 臺業(yè) 務(wù) 中 臺業(yè)務(wù)中臺技術(shù)平臺，為了避免研發(fā)人員重復(fù)發(fā)明輪子，向各個項目提供通用的底層框架、引擎、中間件：項目A項目B項目CMQRPC框架分布式事務(wù)分布式緩存容器分庫分表前 臺技 術(shù) 中 臺技術(shù)中臺數(shù)據(jù)中臺，為各個項目進行各種數(shù)據(jù)采集和分析項目A項目B項目C數(shù)據(jù) 建模日志 分析用戶 畫像前 臺數(shù) 據(jù) 中 臺數(shù)據(jù)中臺算法中臺，為各個項目提供算法能力，比如推薦算法、搜索算法、圖像識別、語音識別等等：項目A項目B項目C語音識別圖像識別搜索算法推薦算法人機對話

7、垃圾過濾前 臺算 法 中 臺算法中臺當有大中臺思路之后，第一，我們這個體系里有什么樣的 能力，可以讓各業(yè)務(wù)很清楚的知道，也可以讓前臺業(yè)務(wù)方 更快的理解、選擇和使用中臺能力第二、我們提供了基礎(chǔ)解決方案，業(yè)務(wù)方根據(jù)需 要做定制開發(fā)滿足自己的業(yè)務(wù)特性，對前臺的業(yè) 務(wù)來說會更快。在阿里提出大中臺，小前端戰(zhàn)略之后的這近兩年時間里，阿里巴巴生態(tài)的基礎(chǔ)設(shè)施構(gòu)建 進一步完善。一個明顯變化是，在生態(tài)邊界擴張的同時，阿里的基礎(chǔ)服務(wù)組件，交易、營銷、會員、電子憑 證、資金、店鋪、評價等商業(yè)運作的環(huán)節(jié)都被體系化打磨好，作為完整的解決方案被用于各個創(chuàng)新業(yè)務(wù)當中。 而相對應(yīng)的，新業(yè)務(wù)能夠在直接利用這些解決方案的同時提出新

8、要求，并對這些服務(wù)進行針對性創(chuàng)新，從而進 一步促進平臺創(chuàng)新。其實阿里的中臺戰(zhàn)略發(fā)展是歷經(jīng)不同的階段，每一步的發(fā)展也見證阿里業(yè)務(wù)的發(fā)展。第二淘寶集市+淘寶 商城時期，分布式 業(yè)務(wù)系統(tǒng)階段。單一業(yè)務(wù)系統(tǒng)淘寶早期分布式業(yè)務(wù)系統(tǒng)淘寶集市+淘寶商城時期業(yè)務(wù)平臺化三淘時期業(yè)務(wù)中臺化垂直化事業(yè)部時期第一淘寶生長期， 單一業(yè)務(wù)系統(tǒng)階段。第三三淘(淘寶、天 貓、一淘)時期、業(yè) 務(wù)平臺化階段。第四個就是目前的 垂直化事業(yè)部、業(yè) 務(wù)中臺化階段。第一階段：單一業(yè)務(wù)系統(tǒng)第一個階段是淘寶早期的建立，業(yè)務(wù)簡 單，一個業(yè)務(wù)系統(tǒng)、幾臺機器就支撐了。 這個階段一開始使用的是PHP的系統(tǒng)。 隨著業(yè)務(wù)的發(fā)展，逐步改造成了Java技

9、術(shù)體系。系統(tǒng)名字叫Denali。淘寶首頁 2003年第二階段：分布式業(yè)務(wù)系統(tǒng)這就到了第二個分布式業(yè)務(wù)系統(tǒng)階段。阿里把 原來的單一系統(tǒng)拆分成多個高內(nèi)聚，低耦合的 中心化系統(tǒng)?，F(xiàn)在耳聞目詳?shù)挠脩糁行?，商?中心，交易中心，店鋪中心，就是這個階段出 現(xiàn)的。每個獨立的系統(tǒng)可以獨立設(shè)計、獨立接 需求、獨立發(fā)布，整個研發(fā)效率和系統(tǒng)穩(wěn)定性 都上了一個臺階。阿里知名的中間件體系也是 這個時候發(fā)展起來的。淘寶首頁 2003年第三階段：業(yè)務(wù)平臺化三淘時期淘寶拆分成立淘寶、天貓和一淘三個獨立的事業(yè)部。三個事業(yè)部的業(yè)務(wù)決策 鏈路更短，業(yè)務(wù)發(fā)展更快、技術(shù)人員也快速增長。而且三個事業(yè)部的定位不 一樣、業(yè)務(wù)發(fā)展方向不一樣、

10、業(yè)務(wù)的管控規(guī)則不一樣。而且在一些業(yè)務(wù)規(guī)則 上可能還相互沖突。我們都知道在做業(yè)務(wù)系統(tǒng)的時候，為了快速應(yīng)對每天的 業(yè)務(wù)需求變更，很多時候都是通過代碼來寫業(yè)務(wù)邏輯的。在業(yè)務(wù)抽象建模， 系統(tǒng)架構(gòu)的開放性方面都是不足的。這就會導(dǎo)致業(yè)務(wù)邏輯之間的耦合和相互 影響，研發(fā)效率大幅下降。第三階段：業(yè)務(wù)平臺化三淘時期在這一階段，系統(tǒng)架構(gòu)必須升級，這就進入了第三個業(yè)務(wù)中心平臺化階段。什么是平臺？就是要把基礎(chǔ)能力跟每個業(yè)務(wù)方的特性業(yè)務(wù)拆分，要把業(yè)務(wù)和 業(yè)務(wù)之間的邏輯進行隔離。比如說天貓的業(yè)務(wù)跟淘寶網(wǎng)的業(yè)務(wù)有可能是沖突 的，但他們需要在一個平臺上執(zhí)行，這時候阿里必須把業(yè)務(wù)的邏輯分開，開 始升級會員平臺、商品平臺、交易平

11、臺等等。平臺化最核心的是業(yè)務(wù)抽象建 模和系統(tǒng)架構(gòu)的開放性。業(yè)務(wù)抽象解決共性的80%問題，系統(tǒng)架構(gòu)開放性解 決20%的個性化問題。第三階段：業(yè)務(wù)平臺化三淘時期第三階段：業(yè)務(wù)平臺化三淘時期整個電商體系有10幾億的商品，涉及商品本身的物理屬性、不同渠道的銷售 價格、庫存等等。還有很多的不同類目的管控規(guī)則，比例醫(yī)療器械，必須要 有企業(yè)資質(zhì)證明，要有檢驗證明等等。而且還有些類目，因為市場定位不一 樣，管控的力度也不一樣，比例淘寶和天貓在手機的管控上也都有差異。怎 么去解決差異性的問題？就要通過建立元數(shù)據(jù)中心、規(guī)則中心、商品發(fā)布界 面自動生成、圖片掃描等等來實現(xiàn)商品管理的平臺化。第三階段：業(yè)務(wù)平臺化三淘時

12、期我們知道每一個人去逛淘寶買東西，每一筆交易都在交易平臺上發(fā)生，但是 在不同的交易的流程和規(guī)則是不一樣的。比如我們買實物商品、買虛擬商品， 還有線下洗頭服務(wù)等等，它的交易流程不同，有些是先支付在發(fā)貨，有些是 先發(fā)貨后支付。比如說汽車可能需要在購買的時候同時申請貸款。支付寶給 我們提供了很多支付方式，但不同業(yè)務(wù)需要的支付方式是不一樣的，這些東 西都是需要通過交易平臺來實現(xiàn)。平臺化要把不同業(yè)務(wù)的邏輯隔離開，避免 相互影響。舉例：交易平臺達人品牌商外部抓取行業(yè)運營服務(wù) 接口平臺發(fā)布百川開放基礎(chǔ)屬性動態(tài)屬性作者類型標簽閱讀量點贊數(shù)篩 選看圖購搭配帖子清單內(nèi) 容元 素視頻錨點商品照片文字平臺 能力質(zhì)量控

13、制規(guī)則定制頁面組件數(shù)據(jù)投放產(chǎn)品頭條極有家愛逛街清單用戶觸達微淘消息push分享組件第四階段：業(yè)務(wù)平臺化但隨著生態(tài)的復(fù)雜度、業(yè)務(wù)的復(fù)雜度、系統(tǒng)復(fù)雜度的升級，阿里又遇到了新的問題。平 臺化解決了領(lǐng)域內(nèi)部的問題，但是其中每一個業(yè)務(wù)的執(zhí)行都是跨領(lǐng)域的，涉及會員、商 品、交易、營銷、店鋪、評價、支付、物流、售后等等，業(yè)務(wù)邏輯橫跨幾十個系統(tǒng)。這就導(dǎo)致了非常大的挑戰(zhàn)，比如說店家賣一件衣服，就會有不同的規(guī)則，例如商品發(fā)布 規(guī)則、交易規(guī)則、營銷規(guī)則等。這些規(guī)則分散在不同的系統(tǒng)中，而且還是相互有關(guān)聯(lián)的。 逐漸地，新做一個需求需要1個月或更長的時間，這變成了一個復(fù)雜生態(tài)的協(xié)作問題， 而不僅僅是一個技術(shù)問題第四階段：

14、業(yè)務(wù)平臺化業(yè)務(wù)中臺化階段主要解決4個問題：1、信息獲取成本高。2、互聯(lián)互通成本高。3、服務(wù)具有不確定性。4、低水平重復(fù)建設(shè)。第四階段：業(yè)務(wù)平臺化解決問題的3個辦法：1、協(xié)議標準、運行機制。2、滿足標準的分布式執(zhí)行單元。3、中心化的控制單元。第四階段：業(yè)務(wù)平臺化業(yè)務(wù)中臺需要一個中心化控制單元，就是運營平臺。它主要由協(xié)議標準，能 力地圖、業(yè)務(wù)需求結(jié)構(gòu)分解、全局業(yè)務(wù)身份、業(yè)務(wù)全景圖、業(yè)務(wù)度量等構(gòu)成。 能讓我們有一個地方縱觀全局，把控細節(jié)。其中能力地圖是一個最基礎(chǔ)的設(shè) 施，要能把電商生態(tài)里面的能力都呈現(xiàn)出來，并在過程中不斷的優(yōu)化完善。 就象我們現(xiàn)在出行離不開高德地圖一樣，今后所有的業(yè)務(wù)方需要做業(yè)務(wù)規(guī)劃

15、， 業(yè)務(wù)創(chuàng)新，都可以到這兒來尋找需要的基礎(chǔ)能力。業(yè)務(wù)中臺化產(chǎn)品形態(tài)1、能力裂變2、能力詳情，活動評價1、業(yè)務(wù)新建/業(yè)務(wù)變更2、配置工具1、業(yè)務(wù)列表2、業(yè)務(wù)全景1、業(yè)務(wù)度量能力地圖需求結(jié)構(gòu)化業(yè)務(wù)清單業(yè)務(wù)度量了解/評估過程業(yè)務(wù)身份標識配置實現(xiàn)能力發(fā)布豐富度 質(zhì)量 可讀性第四階段：業(yè)務(wù)平臺化為了能將業(yè)務(wù)邏輯本身與實現(xiàn)邏輯分離，可以將業(yè)務(wù)邏輯下發(fā)給不同實現(xiàn)的 執(zhí)行系統(tǒng)，引入競爭，方便業(yè)務(wù)平臺的改造升級，阿里將控制信息從業(yè)務(wù)平 臺中抽離到業(yè)務(wù)中臺，以業(yè)務(wù)身份為主線來進行組織管理和呈現(xiàn)。并以生態(tài) 角色的視角來重構(gòu)信息架構(gòu)。這樣的變革對我們原來的系統(tǒng)架構(gòu)提出了更高 的要求。業(yè)務(wù)中臺化全局架構(gòu)業(yè)務(wù)leader

16、產(chǎn)品經(jīng)理 管理視圖運營小二 管理視圖商家管 理視圖消費者 視圖全局業(yè)務(wù)身份統(tǒng)一業(yè)務(wù)控制數(shù)據(jù)中心（業(yè)務(wù)領(lǐng)域、實體模型、業(yè)務(wù)規(guī)劃）基礎(chǔ)數(shù)據(jù)中心（精品、優(yōu)惠、運費、服務(wù)、商品等信息）過程數(shù)據(jù)訂單信息、物流信息招商平臺商家平臺營銷平臺物流平臺驅(qū)動商品平臺驅(qū)動交易平臺產(chǎn)生和處理第四階段：業(yè)務(wù)平臺化通過業(yè)務(wù)中臺化，阿里把所有業(yè)務(wù)的數(shù)據(jù)匯集沉淀。每個業(yè)務(wù)它是怎么出來 的，出來之后做了哪些業(yè)務(wù)需求，業(yè)務(wù)活動，每個業(yè)務(wù)活動的效果是怎么樣 的，都可以沉淀下來。當一個新業(yè)務(wù)來了之后，工程師都可以看到前人成功 和失敗的經(jīng)驗。逐步可以做一些系統(tǒng)建議，建議后人如何去做營銷活動，怎 么做效果分析。這樣能通過數(shù)據(jù)最終反過來支

17、撐阿里的業(yè)務(wù)創(chuàng)新。業(yè)務(wù)中臺化業(yè)務(wù)創(chuàng)新和智能化業(yè)務(wù)開發(fā)生命周期需求域?qū)崿F(xiàn)域上線運行域能力地圖需求結(jié)構(gòu)優(yōu)化業(yè)務(wù)清單業(yè)務(wù)全景全局業(yè)務(wù)身份需求映射頁面開發(fā)流程開發(fā)應(yīng)用部署服務(wù)檢查業(yè)務(wù)度量調(diào) 試測 試數(shù)據(jù)智能運 營 模 式建 議無數(shù)據(jù)業(yè)務(wù)控制數(shù)據(jù)業(yè)務(wù)度量數(shù)據(jù)第四階段：業(yè)務(wù)中臺化的意義“我想說的是業(yè)務(wù)平臺是在最基礎(chǔ)技術(shù)和前端大家能感受到交互技術(shù)中間的 一層。這一層不是外部消費者和入門級技術(shù)人員能直接感知到的。但是這一 層才是真正制約我們整個商業(yè)發(fā)展速度的核心地帶。業(yè)務(wù)平臺如何能支撐幾 千種業(yè)務(wù)，幾萬人在同一個時間里面進行變更，這個對業(yè)務(wù)業(yè)務(wù)的抽象能力 和系統(tǒng)架構(gòu)能力的要求都是極高的?！毙y 阿里業(yè)務(wù)平臺事

18、業(yè)部&淘寶基礎(chǔ)平臺技術(shù)部負責人阿里共享事業(yè)部：為了讓技術(shù)團隊同時支持淘寶和天貓的業(yè)務(wù)，同時也將兩套電商的與做梳理和 沉淀，將兩個平臺中公共的、通用的業(yè)務(wù)功能沉淀到了共享業(yè)務(wù)事業(yè)部，避免有些功能的重復(fù)建設(shè)和維護，更合理地利用技術(shù)資源。共享業(yè)務(wù)事業(yè)部淘寶天貓阿里原本對共享事業(yè)部的設(shè)計但事實上，共享業(yè)務(wù)事業(yè)部在淘寶和天貓這兩 個強大業(yè)務(wù)部門中夾縫生存，為了同時滿足兩個事 業(yè)部的需求，共享業(yè)務(wù)事業(yè)部經(jīng)常加班加點，疲于 奔命也無法滿足兩大事業(yè)部的要求。共 享 業(yè) 務(wù) 事 業(yè) 部淘寶天貓實際情況下共享業(yè)務(wù)事業(yè)部的狀況后來，阿里電商業(yè)務(wù)的團購入口聚劃算出現(xiàn)，這個流量入口威力巨大，可以讓平臺的銷量短 時間內(nèi)增

19、長幾十倍，因此，淘寶、天貓業(yè)務(wù)紛紛涌 進聚劃算，1688也加入其中。一時間，個部分的業(yè) 務(wù)壓力都陡然增加。共 享 業(yè) 務(wù) 事 業(yè) 部淘天寶貓1688聚劃算為了更好地進行資源調(diào)配，集團對組織架構(gòu)和資源進行調(diào)整、整合，要求三大電商平臺如果要和聚劃算對 接，必須經(jīng)過共享業(yè)務(wù)事業(yè)部。這一重大舉措初構(gòu)共享 業(yè)務(wù)事業(yè)部的“中臺”地位，并且能夠很好地調(diào)配資源， 讓各大電商平臺有序地接入聚劃算平臺資源。淘寶天貓1688聚劃算共享業(yè)務(wù)事業(yè)部最終，共享業(yè)務(wù)事業(yè)部發(fā)展成現(xiàn)在的形態(tài)：即將阿里巴巴集團前段業(yè)務(wù)中公共、通用的業(yè)務(wù)沉淀到這個事業(yè)部，包 含了用戶、商品、交易等十幾個中心，實現(xiàn)了阿里真正的“業(yè)務(wù)中臺”，基于阿里

20、云平臺這個技術(shù)后臺的基礎(chǔ)上， 為阿里若干個“業(yè)務(wù)前臺”提供著最專業(yè)、穩(wěn)定的業(yè)務(wù)。大中臺，小前臺的核心戰(zhàn)略最早提出是 在 2015 年 7 月。彼時阿里巴巴有近 4 億用戶，服務(wù)超過 1000 萬各類企業(yè)，業(yè)務(wù)種類繁多， 業(yè)務(wù)之間相互網(wǎng)狀依賴。團隊眾多，相互依賴， 對業(yè)務(wù)響應(yīng)也越來越慢，這是內(nèi)部原因而外部原因，則是大數(shù)據(jù)和云計算逐漸成為新 經(jīng)濟時代的石油與引擎時，阿里巴巴更迫 切的需要找到能夠?qū)ν饨缱兓焖俜磻?yīng)，整合阿里 各種基礎(chǔ)能力，高效支撐業(yè)務(wù)創(chuàng)新的機制。這樣，大中臺的建設(shè)迫在眉睫企業(yè)信息中心發(fā)展的問題突顯：煙囪式系統(tǒng)建設(shè)模式1688技術(shù)團隊1688天貓?zhí)詫毺詫?技術(shù)團隊2008年時淘寶的技

21、術(shù)團隊同時支持者淘寶和天貓兩大電商平臺。1999年成立的1688一直擁有在的技術(shù)團隊。阿里集團 三大電商體系的技術(shù)支持架構(gòu)如下：“煙囪式”系統(tǒng)建設(shè)模式煙囪系統(tǒng)是指一種由相互關(guān) 聯(lián)的元素緊密結(jié)合在一起的 集合，其中單個元素無法區(qū) 分、升級或重構(gòu)。煙囪系統(tǒng) 會一直維持存在直到有新的 系統(tǒng)將其完全取代。企業(yè)信息中心發(fā)展的問題突顯：煙囪式系統(tǒng)建設(shè)模式弊端一弊端二弊端三共享服務(wù)架構(gòu)的建設(shè)使阿里巴巴擺脫了因為“煙囪式”系統(tǒng)建設(shè)方式所帶來的的發(fā)展桎梏，最終成為阿里巴巴業(yè)務(wù)中臺戰(zhàn)略的核心組成重復(fù)功能建設(shè)和維護帶來重復(fù)投資；大量的功能和業(yè)務(wù)在多個系統(tǒng)中同時存在，是 很顯性的成本和資源浪費打通“煙囪式”系統(tǒng)間交互

22、的 集成和寫作成為必然；成本高昂；隨著企業(yè)的發(fā)展，打通這些“煙囪式”系統(tǒng)之間的連接不利于業(yè)務(wù)的沉淀和持續(xù)發(fā)展。系統(tǒng)上線幾年后，由于無法滿足業(yè)務(wù)發(fā)展不得不推到重建，這將 會大大影響多年業(yè)務(wù)的沉淀保留在阿里巴巴集團的中臺戰(zhàn)略中，共享服務(wù)中心是中臺架構(gòu)的基石，如何構(gòu)建穩(wěn)定可靠、最高效低支撐 前臺業(yè)務(wù)的共享服務(wù)能力，是中臺戰(zhàn)略成功落地的關(guān)鍵2、業(yè)務(wù) 能力1、PaaS的 能力（PaaS，Platform as a Service的縮寫， 是指平臺即服務(wù)，指將軟件研發(fā)的平臺 作為一種服務(wù)，以SaaS的模式提交給用 戶）PaaS層解決大型架構(gòu)在分布式、可 靠性、可用性、容錯、監(jiān)控以及運維層面上的通用需求。指

23、提供云化的核心業(yè)務(wù)支撐能力， 這層能力建設(shè)的好與壞，直接決定 了是否能真正支持上層業(yè)務(wù)達到敏 捷、穩(wěn)定、高效淘寶的共享服務(wù)中心包括多個服務(wù)中心，最初有四大服務(wù)中心：用戶中心、商品中心、交易中心、店鋪中心。隨著業(yè)務(wù)的不斷發(fā)展，越來越多的服務(wù)能力沉淀到了共享服務(wù)中心1、用戶中心:同時成立了專門負責用戶中心 運營的團隊后，顯著提升了對 業(yè)務(wù)需求的響應(yīng)效率；系統(tǒng)在 實現(xiàn)解耦后，服務(wù)的穩(wěn)定性和 可擴展性都得到了極大的提高。用戶中心少報進行業(yè)務(wù)服務(wù)化歷程中所構(gòu)建的第一個服務(wù)中心，它統(tǒng)一了淘寶原來各個業(yè)務(wù)線分散的用戶體系、用戶數(shù)據(jù)、 存儲、服務(wù)接口。選擇用戶中心作為第一個建設(shè)的 服務(wù)中心主要原因是，跟用戶相

24、 關(guān)的服務(wù)是被上層業(yè)務(wù)調(diào)用最頻 繁的服務(wù)，最大效率節(jié)省開發(fā)和 維護成本的同時，也最能驗證出 服務(wù)化后和系統(tǒng)解耦后給業(yè)務(wù)快 速相應(yīng)帶來的效果。另一個原因則是用戶中心相 比于商品、交易中心在業(yè)務(wù) 復(fù)雜程度和重要性上都要小 一些，最適合作為改造的“先行兵”。用戶中心構(gòu)建了整個阿里巴 巴集團統(tǒng)一的用戶體系，用 戶中心服務(wù)提供了統(tǒng)一的服 務(wù)接口，即簡化了上層業(yè)務(wù) 的使用，也方便了接下來對 用戶的大數(shù)據(jù)分析。2、商品中心:淘寶的商品中心建設(shè)非常有代表意義，商品管理是淘寶最復(fù)雜的業(yè)務(wù)場景之一，其對前臺提供的服務(wù)能力包括以下幾個方面1.商品描述能力：包括商品的描述數(shù)據(jù)模型、商品的存儲模型、對外提供的服務(wù)接口。

25、3. 商品管理能力：淘寶有全世界最大的商品庫，所以商品SPU數(shù)據(jù)只能自己建設(shè)，自己維護。2. 商品發(fā)布能力：指提供通用的發(fā)布接口和 標準的發(fā)布工具，業(yè)務(wù)層會根據(jù)業(yè)務(wù)需求提供滿 足業(yè)務(wù)需求的發(fā)布工具。這里可以感受到服務(wù)和 業(yè)務(wù)的邊界：“服務(wù)中心”一定是實現(xiàn)通用的能 力，個性化盡量在業(yè)務(wù)層實現(xiàn)?！?. 商品巡檢的能力：為了剔除不活躍的用戶和防止隨意熱詞題目帶 來糟糕的用戶體驗6. 商品的評價的能力。淘寶引入商品的評價體系可以評論商品和賣家， 評價中心的職責就是要識別正常的評價，剔除惡 意的差評與好評，建立更公平的商品評價體系。5. 商品數(shù)據(jù)分析的能力：商品中心能自動聚合推薦的類目數(shù)據(jù)并提供調(diào)整 的

26、決策支持。3、交易中心:服務(wù)中心都是這樣動態(tài)發(fā)展進化的過程，比如由于天貓業(yè)務(wù)的發(fā)展，對庫存有了更高的要求，所以后來從商品中心獨立出來了困村中心交易中心是電商的交易業(yè)務(wù)領(lǐng)域的服務(wù)中心，包含交易相關(guān)的服務(wù)信息，比如 購物車、交易流程、訂單管理、支持、結(jié)算、營銷等。初期，淘寶的交易中心聚合了很多相關(guān)的業(yè)務(wù)服務(wù)，后來隨著業(yè)務(wù)的發(fā)展， 交易中心有了相應(yīng)的調(diào)整，比如后來拆分出來了營銷中心4、店鋪中心:店鋪中心承擔了賣家店鋪管理、店鋪裝修、店鋪生命周期管理、店 鋪日常管理等業(yè)務(wù)，在店鋪體系下，發(fā)展了淘寶最具活力的第三方 店鋪裝修市場，這是平臺化的最好實踐嘗試服務(wù)化階段進入平臺化階段全面服務(wù)化階段關(guān)鍵服務(wù)中心

27、應(yīng)該是一個充滿生命力的個體，在整個體系中承擔自己專門的只能，跟隨整個體系一起 發(fā)展進化，它必須是：1. 不斷發(fā)展的：服務(wù)和服務(wù)中心都是伴隨業(yè)務(wù)發(fā)展變化的，淘寶的共享服務(wù)體系更是如此用戶中心 商品中心平臺 交易中心平臺 營銷中心平臺店鋪中心 店鋪中心 庫存中心用戶中心 商品中心 交易中心 評價中心 營銷中心 店鋪中心 庫存中心用戶中心 商品中心 交易中心 店鋪中心淘寶共享服務(wù)中心建設(shè)歷程2.一個服務(wù)中心可以進一步劃分嗎？會員中心會員服務(wù)交易中心訂單服務(wù)購物車服務(wù)會員數(shù)據(jù)交易數(shù)據(jù)共 享 服 務(wù)數(shù) 據(jù) 層單個服務(wù)模塊多個服務(wù)模塊服務(wù)中心的不同組成形式回答是肯定的，服務(wù)中心是業(yè)務(wù)領(lǐng)域的概念， 落地到業(yè)

28、務(wù)架構(gòu)上并不需要一一對應(yīng)。服務(wù) 中心是根據(jù)業(yè)務(wù)和數(shù)據(jù)的完整性與獨立性來 設(shè)立的，服務(wù)中心包含的子模塊更多是從系 統(tǒng)設(shè)計和業(yè)務(wù)架構(gòu)層面來考慮的服務(wù)中心的設(shè)計一定要兼顧三方面的需求：設(shè)計、運營、工程設(shè)計層面運營層面工程層面遵循面向?qū)ο蟮姆治龊驮O(shè)計方法，即 業(yè)務(wù)和系統(tǒng)建模遵循面向?qū)ο蟮幕?原則。服務(wù)中心應(yīng)該是一個完整的業(yè)務(wù)模型， 要有數(shù)據(jù)運營和月整合的價值。共享服務(wù)的架構(gòu)屬于分布式架構(gòu)，解決了 一體化架構(gòu)在打歸母應(yīng)用上的問題，但是 也引入了分布式事務(wù)、問題排查等方面的 難題，所以在規(guī)劃中心的時候，一定要綜 合評估業(yè)務(wù)層對服務(wù)中心在數(shù)據(jù)庫、業(yè)務(wù) 以及運營方面的需求和技術(shù)上需要的投入業(yè)務(wù)可運營性原則：

29、我們期望服務(wù)中心是承載業(yè)務(wù)邏輯、沉淀業(yè)務(wù)數(shù)據(jù)、產(chǎn)生業(yè)務(wù)價 值的業(yè)務(wù)單元。一是指業(yè)務(wù)本身的活力，當業(yè)務(wù) 處于快速生長期，這時候的運營 目標是滿足上層的業(yè)務(wù)需求，這 個時候?qū)儆诔恋黼A段；第二個層面的運營是業(yè)務(wù)內(nèi)部孕 育出來的創(chuàng)新想法，比如淘寶基 于大數(shù)據(jù)分析技術(shù)生長起來的商 品巡檢技術(shù)、前臺類目自動聚合 推薦技術(shù)等。高內(nèi)聚、低耦合原則：高內(nèi) 聚是從服務(wù)中心的業(yè)務(wù)界域 來說的，在一個服務(wù)中心內(nèi) 的業(yè)務(wù)應(yīng)該是相關(guān)度很高、 依賴性很高的；而服務(wù)中心 之間應(yīng)該是業(yè)務(wù)隔離性比較 大的，追求盡可能的低耦合。數(shù)據(jù)完整性原則：服務(wù)化架構(gòu)一個很重要的業(yè)務(wù)價值就是數(shù)據(jù)模型統(tǒng)一，不光只是業(yè)務(wù)邏輯的關(guān)鍵數(shù)據(jù)，還要考慮到業(yè)

30、務(wù)的相關(guān)性的數(shù)據(jù)；不光是實時在線數(shù)據(jù)，還要考慮到離線計算的數(shù)據(jù)。漸進性的建設(shè)原則：服務(wù)化 架構(gòu)本來就是一種敏捷的實 踐，我們推薦小步快跑的方 式逐步推進，不是轟轟烈烈 地推翻重來。阿里巴巴業(yè)務(wù)中間件&穩(wěn)定性平臺企業(yè)級互聯(lián)網(wǎng)架構(gòu)淘寶阿里云天貓釘釘AE阿里媽媽1688阿里音樂聚劃算阿里影業(yè)螞蟻金服優(yōu)酷菜鳥MQDRDSCSBEDASARMSSchedulerX支撐輸出穩(wěn)定性平臺全鏈路壓測彈性伸縮線上壓測故障演練限流降級線上開關(guān)容量規(guī)劃業(yè)務(wù)審計強弱依賴分布式數(shù)據(jù)庫消息分布式服務(wù)負載均衡流式計算JStorm分布式緩存Tair分布式存儲HistoreTFSHBaseTDDLYuGongJingwei分布式

31、鏈路跟蹤&基礎(chǔ)數(shù)據(jù)應(yīng)用容器PandoraEagleyeTLOG負載均衡負載均衡SchedulerXNotifyMetaQHSFTengineTXCCongflgSeverVipSeverDiamondZookeeper中間件&穩(wěn)定性平臺移動中臺EMAS業(yè)務(wù)中臺&數(shù)據(jù)中臺基礎(chǔ)中間件基礎(chǔ)設(shè)施laas開發(fā)套件& 框架企業(yè)研發(fā)云功能組件移動網(wǎng)關(guān)消息推送移動APM業(yè)務(wù)中心數(shù)據(jù)中心會員中心商品中心交易中心訂單中心支付中心評價中心大數(shù)據(jù)計算服務(wù)大數(shù)據(jù)開發(fā)套件畫像分析數(shù)據(jù)可視化數(shù)倉規(guī)劃數(shù)據(jù)服務(wù)分布式框架EDAS消息隊列MQ實時監(jiān)控ARMS分布式數(shù)據(jù) 陣DRSGISECSSLBOSSRDSCDN前臺 業(yè)務(wù)后臺業(yè)

32、務(wù)EMASDerOps云效構(gòu)建頻率 構(gòu)建時長 構(gòu)建成功率構(gòu)建故障恢復(fù)時間 圈復(fù)雜度代碼重復(fù)率 測試覆蓋率 版本發(fā)布頻率 需求交付周期服務(wù)監(jiān)控 K8S容量監(jiān)控 消息流量監(jiān)控 日志手機錯誤定位藍綠部署 Feature toggle 用戶行為分析 告警通知BI度量運維監(jiān)控DevOps 云平臺發(fā)布單元產(chǎn)品度量模板管理基礎(chǔ)權(quán)限流水線構(gòu)建輕量審計資源彈性回收持續(xù)交付流水線SCM管理分層分級流水線整合廣義工具流水線模板過程數(shù)據(jù)手機和可視化作業(yè)狀態(tài)可視化自定義業(yè)務(wù)流程云彈性伸縮代碼倉庫依賴倉庫代碼腳手架自動對接代碼倉庫 生成工程腳手架 生成標準流水線自動化測試Sonar安全性組件掃描測試管理 測試自動化 功能

33、測試 界面測試中心化SCM調(diào)度K8SAWSdocker物理機VMWare部署平臺部署編排 自動部署職場復(fù)雜部署 支持彈性部署支持多種OS部署 支持多種層平臺部署 支持多流配置管理工具發(fā)布平臺發(fā)布質(zhì)量報告 灰度發(fā)布 藍綠環(huán)境 A/B測試審批和協(xié)同 版本和環(huán)境管理監(jiān)控平臺指標監(jiān)控 日志監(jiān)控 行為監(jiān)控 儀表盤 APM告警數(shù)據(jù)中臺從后臺及業(yè)務(wù)中臺將數(shù)據(jù)流入，完成 海量數(shù)據(jù)的存儲、計算、產(chǎn)品化包裝過程，構(gòu) 成企業(yè)的核心數(shù)據(jù)能力，為前臺基于數(shù)據(jù)的定 制化創(chuàng)新和業(yè)務(wù)中臺基于數(shù)據(jù)反饋的持續(xù)演進 提供了強大支撐。業(yè)務(wù)中臺將后臺資源進行抽象包裝整合， 轉(zhuǎn)化為前臺友好的可重用共享的核心能力， 實現(xiàn)了后端業(yè)務(wù)資源到前

34、臺易用能力的轉(zhuǎn) 化業(yè)務(wù)、數(shù)據(jù)“雙中臺”螞蟻金服電子商務(wù)物流文娛支付寶余額寶（基金）借唄花唄C2C淘寶B2C天貓C2B聚劃算B2B1688O2O天貓超市OAO盒馬生鮮菜鳥物流優(yōu)酷高德地圖UC微博友盟業(yè)務(wù)模式用戶 中心服務(wù)服務(wù)服務(wù)服務(wù)服務(wù)管理管理管理管理管理數(shù)據(jù)庫數(shù)據(jù)庫數(shù)據(jù)庫數(shù)據(jù)庫數(shù)據(jù)庫交易 中心商品 中心營銷 中心物流 中心微服務(wù)管理消息隊列應(yīng)用監(jiān)控應(yīng)用監(jiān)控業(yè)務(wù)中臺基礎(chǔ)件分布式數(shù)據(jù)庫業(yè)務(wù)系統(tǒng)+數(shù)據(jù)應(yīng)用系統(tǒng)業(yè)務(wù)中臺數(shù)據(jù)安全 體系數(shù)據(jù) 質(zhì)量數(shù)據(jù) 服務(wù)數(shù)據(jù) 安全數(shù)據(jù)中臺 基礎(chǔ)件數(shù)據(jù)中臺數(shù)據(jù) 采集數(shù)據(jù) 計算資源管理風險管理質(zhì)量監(jiān)控高危操作審計管理權(quán)限管理主數(shù)據(jù)中心商品數(shù)據(jù)庫存數(shù)據(jù)訂單數(shù)據(jù)商家數(shù)據(jù)用戶數(shù)據(jù)

35、物流數(shù)據(jù)風控評估 模型價格波動預(yù)警庫存積壓 預(yù)警資金流預(yù)警算法模型其他用戶畫像人群精選標簽工廠接口查詢DMP接口配置數(shù)據(jù)服務(wù)前臺中臺后臺快速響應(yīng)的 作戰(zhàn)單元A快速響應(yīng)的作戰(zhàn)單元B快速響應(yīng)的作戰(zhàn)單元C人IT+DTBP人力三支柱財戰(zhàn)略投資財務(wù)風控硅基生命碳基生命投前評估+投后服務(wù)業(yè)務(wù)+算法中臺組織中臺系統(tǒng) 積木決策 算法HRBP跟投式 行研跟投式 風控規(guī)資源池建設(shè)物實物+數(shù)據(jù)規(guī)則設(shè)計公平公正研究院看得見的手監(jiān)督管理委員會騰訊組織架構(gòu)調(diào)整歷程騰訊變陣的開端：強化2B、對標今日頭條、搭建大中臺云與智慧產(chǎn)業(yè)事 業(yè)群（CSIG）平臺與內(nèi)容事業(yè) 群（PCG）騰訊VS阿里 中臺戰(zhàn)略六大事業(yè)群技術(shù)委員會理分配技術(shù)資源、跟蹤技