中臺科普

目錄：

1.關於中臺的名言

2.中臺起源

3.中臺定義

4.中臺類型

5.中臺能力

6.中臺本質

7.中臺優點

8.中臺動態

9.排頭兵的中臺案例

10.建設中臺的兩大緣由

11.中臺究竟能解決的問題

12.中臺解決的痛點

13.中臺對中小型公司的意義

14.作中臺兩個關鍵點

15.中臺落地

16.中臺完整的體系

17.中臺技術本質

18.中臺技術架構

19.遙望將來10年—AI中臺

20.業務中臺

21.業務中臺&數據中臺

22.業務中臺&大數據

23.彩蛋

 

關鍵詞：   業務中臺/ 共享 / 公共通用 / 複用

 

 

書籍推薦：

《淘寶技術十年》

《企業 IT 架構轉型之道：阿里巴巴中臺戰略思想和架構實戰》

 

名言：

2014年馬雲也曾在阿里內部說過：一切業務數據化和一切數據業務化。

 

解釋：「一切業務數據化」，即業務中臺可以將企業相關業務領域的原生數據，作好統1、規範及標準，讓企業業務數據實時、統1、在線。這是業務中臺乾的事情。但此後，這些原生數據其實不能給企業產生大數據的價值。數據要有價值，要發揮洞察和預測的能力，便得「一切數據業務化」。「數據的回饋能力很重要，全部業務場景中收集和採集的數據，圍繞業務場景，根據調度算法或預測算法副作用到業務，這纔是一切數據業務化的本質和核心」，

 

 

起源：

中臺這個概念早期是由美軍的做戰體系演化而來的，技術上所說的「中臺」主要是指學習這種高效、靈活和強大的指揮做戰體系。國內知名的有阿⾥的「⼤中臺，⼩前臺」戰略。而且華爲在幾年前就提出了「⼤平臺炮火支撐精兵做戰」的企業戰略，「讓聽獲得炮聲的人能呼喚到炮火」 這句話形象的詮釋了大平臺⽀撐下小前臺的做戰策略。這種極度靈活又威力巨⼤的戰法，使之能夠迅速響應瞬息萬變的戰場，一旦鎖定目標，經過大平臺的炮火羣，迅速精準對於戰場進行強大的火⼒支援。

 

 

 

中臺定義：

1. 中臺是一種企業級能力複用平臺，是一種共性能力，支持了多個業務。核心是「功能複用」，構建「大中臺，小前臺」來知足業務快速擴展的需求；

2.主要職責是彙總全部業務數據，協同各個業務單元，提煉業務的共性需求，支撐前、後臺業務的快速發展

3.沉澱了大量的用戶行爲數據（包含非體系內用戶），爲大數據智能算法的新的商業模式奠基了基礎

5.做爲業務服務的提供方，不須要依賴業務的穩定性，而是須要不斷爲新業務提供能力支持。

 

 

 

中臺類型：

中臺—> 業務、數據、用戶、搜索、推薦、內容、技術、算法、移動、研發等一系列中臺

 

 

 

中臺的幾方面能力：

• • 針對多業務、複雜業務場景下需求的抽象和共性需求的整合；
• • 對業務、前端體驗、後端架構等多方面能力的高要求；
• • 對業務的深刻了解，以能在常規服務基礎上，提供創新性業務能力，爲業務創新作指引。

 

 

 

前臺/中臺/後臺

前臺：

由各種前臺系統組成的前端平臺。每一個前臺系統就是一個用戶觸點，即企業的最終用戶直接使用或交互的系統，是企業與最終用戶的交點。例如用戶直接使用的網站，手機App，微信公衆號等都屬於前臺範疇。

 

 

中臺：

 由於企業後臺每每並不能很好的支撐前臺快速創新響應用戶的需求，後臺更多解決的是企業管理效率問題，而中臺要解決的纔是前臺的創新問題。中臺戰略的構建，從功能上說，包括構建數據中臺、構建技術中臺、以及構建業務中臺。其中數據中臺的本質是將數據資產化，技術中臺的本質是將流程自動化，業務中臺的本質是將應用場景化。

 

後臺：

由後臺系統組成的後端平臺。每一個後臺系統通常管理了企業的一類核心資源（數據+計算），例如財務系統，產品系統，客戶管理系統，倉庫物流管理系統等，這類系統構成了企業的後臺。基礎設施和計算平臺做爲企業的核心計算資源，也屬於後臺的一部分。

 

結論：

中臺是真正爲前臺而生的平臺（能夠是技術平臺，業務能力甚至是組織機構），它存在的惟一目的就是更好的服務前臺規模化創新，進而更好的響應服務引領用戶，使企業真正作到自身能力與用戶需求的持續對接。

 

中臺本質：

中臺的本質是提煉各個業務線的共性需求，並將這些功能打形成組件化的產品。前臺要作什麼業務，須要什麼資源能夠直接找中臺，不須要每次去改動本身的底層，而是在更豐富、靈活的「大中臺」基礎上獲取業務能力支持，讓「小前臺」更加靈活敏捷，中臺架構被認爲是將來企業級架構的方向。中臺相似一個變速齒輪，將前臺的快速響應和後臺的複雜，穩定可靠，變化週期相對較慢的矛盾適配起來，快速驅動業務創新的同時，又保持了IT架構的穩定

 

中臺系統的優點：

• • 服務重用：鬆耦合的服務帶來業務的複用；
• • 服務進化：隨着新業務的不斷接入，共享服務也需從僅提供單薄業務功能，不斷的自我進化成更健壯更強大的服務，不斷適應各類業務線，真正成爲企業寶貴的IT資產；
• • 數據累積：各個業務的數據都沉澱在同一套中臺服務，能夠不斷累積數據，最終發揮大數據威力；
• • 快速響應：更快的經過共享服務的組合響應新業務；
• • 下降成本：對於新業務，無需再投入新的重複的開發力量，減小人員成本；
• • 效能提高：開發人員更專一某一領域，開發更快，更易維護。

 

 

 

排頭兵的中臺動態：

2017 年 12 月，滴滴出行執行總監賴春波透露了滴滴如何搭建出行業務中臺的過程：滴滴從專業深度、人力資源、用戶體驗、全局打通四個維度，將快車、出租車、專車、順風車、代駕等多個業務的垂直化架構整合到了同一套架構體系中。因爲滴滴的業務和用戶命令輸送相對具有一致性，滴滴的中臺建設也主要基於數據的維度。進一步地，在業務更爲複雜、服務更爲多元的企業中，須要建構的中臺模式也將更爲複雜。

 

2018 年 11 月 26 日，據報道，美團正在嘗試打通美團 APP 全平臺、大衆點評、摩拜各個業務之間的數據，構建數據中臺。

 

2019 年 3 月 19 日，字節跳動也被曝出正在搭建「直播大中臺」，抖音、西瓜視頻、火山小視頻這 3 款 APP 的直播技術和運營團隊將被抽出、合併，支撐旗下全部的直播產品。

 

阿里巴巴的數據業務雙中臺。畢竟阿里的「大中臺小前臺」戰略人盡皆知，其威力也是顯而易見的。業務中臺將後臺資源進行抽象包裝整合，轉化爲前臺友好的可重用共享的核心能力，實現了後端業務資源到前臺易用能力的轉化。數據中臺從後臺及業務中臺將數據流入，完成海量數據的存儲、計算、產品化包裝過程，構成企業的核心數據能力，爲前臺基於數據的定製化創新和業務中臺基於數據反饋的持續演進提供了強大支撐。

 

 

排頭兵的中臺案例：

阿里雲——業務數據雙中臺

阿里巴巴——移動中臺

阿里巴巴——技術中臺

騰訊——數據中臺和技術中臺

百度——搜索中臺

京東——數據中臺

廣發銀行——業務中臺

海通證券—— 數據中臺、技術中臺、業務中臺三元統一

恆生電子 —— 數據中臺+技術中臺+業務中臺+行業級業務中臺

 

 

舉例：

講到中臺，必定會提到兩個例子，一個是13年馬雲參觀supercell，而後在15年肯定了阿里的中臺戰略；另外一個是華爲的中臺戰略轉型，也就是那句著名的「讓聽得見炮火的人指揮戰鬥」；

 

舉例：

阿里的共享服務部發展歷程，即供應鏈中臺。公司剛開始只有淘寶，後來意識到B2C模式的業務也會是電商領域重要的組成部門，因此出現了天貓，隨着天貓的不斷髮展，逐漸獨立成一個部門，可是這兩套都包含訂單、商品、庫存、價格、倉儲、物流等基本業務系統。這兩個系統互相獨立，各自運行。等到10年左右，阿里開始上線168八、聚划算等業務的時候發現，這些業務針對的領域雖然各不相同，可是他須要用到的系統功能也高度相似，主要也是訂單、商品、庫存、價格、倉儲、物流等系統。若是這些新業務的系統也都要所有從新開發一遍，這無疑是很大的資源浪費。明明既有的系統調整一下就能夠知足新業務的需求，爲何還要繼續開發新系統吶？在這個大的背景之下，阿里內部將共享服務部的職權不斷提高，統一將各個業務業務部門重複使用，反覆建設的功能和系通通一規劃和管理。

 

舉例：

滴滴在15年底開始啓動本身的中臺戰略，這與滴滴當時的業務發展階段也是相關的。2015 年底，滴滴在短期內造成了包括快車、出租車、專車、順風車、代駕等多業務的垂直化架構。這些業務雖然會有一些差異，可是核心系統和流程都是相似的。若是各自獨立開發，也會出現各類各樣的問題。好比說，開發成本太高，滴滴旗下的每一個業務，其實都是能夠單獨支撐起一家公司的，若是每一個業務都獨立作到極致，那麼開發成本和人力成本就會很是巨大，而若是爲了控制成本，就把系統的建設放緩，則意味着，不管是核心系統自己的質量，仍是對外的用戶體驗都不太好。在這樣的背景下，滴滴也開始考慮將諸多業務，以及各個城市的系通通一規劃，統一建設，提高服務前臺的能力。

 

 

建設中臺的兩大緣由：

一類是，許多業務需求或功能需求高度相似、通用化程度很高，可是因爲沒有專門的團隊負責規劃和開發，大量的系統重複開發、重複建設，致使複用性低、效率低、產研資源浪費、用戶體驗不統一；另外一類是，早期業務發展過程當中，爲了解決一些當下的業務問題，垂直的、個性化的業務邏輯與基礎系統耦合太深，因爲沒有平臺性質的規劃，橫向系統之間、上下游系統之間的交叉邏輯也很是多，這樣致使在新業務、新市場的拓展過程當中，系統無法直接複用，甚至無法快速迭代。

 

中臺究竟能解決的問題：

中臺做爲一種產品設計思路，或者系統架構思路，並不受限於公司的規模，理論上講，任何一家即將或者正在面臨業務高速增加的狀態時，都很值得利用和借鑑中臺的思路，將目前業務當中大量可複用的功能和場景進行梳理，爲業務的高速增加作好準備

 

舉例：

一、多業務來源數據統一

數據來自於高德、美團...等等，經過中臺系統，能夠把這些數據統一接入訂單庫

二、數據聚合

經過中臺聚合訂單，對外提供「訂單API」。運能系統經過訂單API扣減運能，財務系統經過訂單API結算。

三、快速擴展

企業若是後續要上新系統，好比會員、積分子系統等均可以直接和中臺接口對接，獲取到全渠道的業務數據，快速完成系統搭建，響應業務需求。

 

 

中臺解決的痛點：

痛點一：企業前方市場與企業內部支撐的衝突，即用戶和用戶的需求永遠是善變的。企業前方市場老是會趨於變化無序，而企業內部支撐總歸要趨於穩定有序

痛點二：前臺與後臺的衝突

前臺是對接用戶的，因此係統須要快速響應前端用戶的需求，快速創新、快速迭代。簡而言之，快速建設、錯了就推翻重來、不能耗費太大成本。

後臺是企業對內的，爲了支撐前臺愈來愈多的業務，後臺系統不斷地建設，系統不斷龐大起來。因此後臺系統須要紮實穩定，建成以後每每不能隨意改動。

痛點三：大企業的通病（各佔山頭、重複建設）大企業內部各處都是牆——部門牆、業務牆、數據牆

 

 

中臺對中小型公司的意義：

對於不少中小公司，當他們走出生存困境，進入到高速發展階段時，會遇到不少的問題，但大機率會遇到的一個問題是，過往的業務模型，產品能力頗有可能無法徹底承接住大規模用戶增加帶來的壓力。而當你具體到每一個用戶的時候，你又能發現，他們遇到的問題你以前都遇到過，只不過，由於一下來的太多，你無法像過去同樣提供達預期，甚至超預期的服務時，對方就會產生不滿。這也是爲何許多公司會生於拉新，死於留存的一個緣由。因此，在有可能的狀況下，公司將一些大機率長期有價值的功能，專門模塊化，進行開發和優化，確保即便業務規模進一步擴大，也可以知足業務需求。甚至，隨着能力或方法論的不斷優化，甚至有可能某一天成爲整個行業的方法論。對於中小公司而言，中臺的理念不見得是單獨拉幾十人搭建一箇中臺產研團隊，能夠將一些關鍵流程先行標準化，把一些反覆出現的場景當中的解決方案進行沉澱，部分須要產品化的功能先行產品化，可能對於一家業務剛剛開始起步的公司來講，就已經很重要了。

 

 

作中臺兩個關鍵點：

思惟：

必須思考的問題是，這個功能在如今或者未來能知足多少業務場景？若是未來有新的業務出現，是否是可以複用？或者說，須要作多大的調整才能夠複用？甚至於，這個功能有沒有可能對外輸出，提供SaaS化的服務。

環境：

響應多個業務部門，大量的精力耗散於不一樣部門之間的溝通協調。由於接下來的解決方案，是要服務於多個業務。須要看到不一樣需求之間的共性需求，並提煉出一個產品化的解決方案

 

 

中臺落地：

1、通用

標準統一，實現數據打通、可通用性。數據打通是須要整合企業內部被「部門牆」割裂的數據。

2、組件化

中臺提供的服務最好以組件化的方式讓業務端能夠即取即用。組件化設計能夠避免系統間耦合性大，牽一髮而動全身。這須要針對共用服務進行抽象設計。經過抽象出的組件化服務提供，前臺業務端能夠以組合挑選的方式「按需取件」，減小重複建設得以實現。

3、可複用

中臺提供的服務是應該能夠即取即用的。不只如此，此次用完，下次還來。業務A用了，業務B也來用。一箇中臺提供出的公用服務的價值高低，是「可用」和「可複用」的區別。

4、可共用

基礎服務有了，那經過中臺向前臺提供「相應的服務」仍是提供「一攬子的服務」？取決於服務提供的可開放共用的程度。就像咱們看到，各大互聯網決定中臺建設的開始，老是要伴隨企業層級的組織架構的調整。雖然各部門權限、各業務屬權，恐怕不是一句「開放共享」的願景就能徹底解決和無差異共用的，可是經過開放共享實現「可共用」的目標終究是中臺建設的原則。

5、靈活擴展

在一攬子的服務均可輸出後，業務量可能會短期大大激增。能扛得住大流量高峯時期的高併發、高可用將成爲一個大挑戰。底層的可靈活擴展能力將很是重要。企業應當應用DevOps、Docker等先進的開發技術理念，在中臺建設前就開啓數字化的技術轉型。

 

中臺完整的體系：

第一層：無數碎片化的、場景化的前臺業務應用，如零售、採購、招聘、報銷...

第二層：業務中臺，如零售中臺、人力中臺、財務中臺....

第三層：數據中臺：主數據（畫像標籤/關係圖譜）、數據模型、人工智能業務算法

第四層：後臺應用：如被分解後剩下的單一企業內部超穩定的收斂的應用

第五層：應用平臺：協同平臺（工做流引擎/消息引擎等）、應用組件（聚合支付/電子發票/電子合同/自動報稅等等）、集成開發平臺/定製開發平臺/實施平臺/運維平臺

第六層：技術平臺：微服務中間件、SQL/NOSQL數據庫、大數據技術平臺（如Hadoop和Spark）、AI技術引擎、雲IaaS平臺

 

 

中臺技術本質：

在軟件開發領域，有專門的名稱，叫作「重複造輪子」和「煙囪式架構」。企業在發展過程中，爲了解決當下的業務問題，快速上線了不少功能，而欠下了許多技術債，當企業進入成熟期以後，發現這些問題的存在，嚴重影響了企業的運行效率和運營成本。

 

中臺技術架構：

一、UI交互層：Windows UI、PC Web UI、移動App UI、微信小程序UI、攝像頭視覺識別人機界面、語音交互人機界面

二、邏輯層：面向對象技術/組件技術/SOA服務中間件/微服務中間件技術、人工智能NLP/機器學習

三、數據層：SQL數據庫/NOSQL數據庫、大數據計算平臺/數據倉庫數據湖/可視化

四、基礎設施層：雲計算IaaS（服務器、存儲、網絡、文件系統）

PS:雖然業務中臺，根本不是在這個分層視角維度體系來看事的。不過話說回來，中臺應用要具體代碼實現，還得依賴這些具體的技術。這就是他們倆之間的關係。

 

 

遙望將來10年—AI中臺：

將來的應用是：產業互聯網、社會化商業，處處鏈接；咱們講了將來的技術是：人工智能最佳算法調度，而非寫死的業務邏輯規則代碼，阿里雲都成立十週年了，應用了10年的雲計算。

 

雲技術上半場是：

一、UI層：移動App、微信小程序

二、邏輯層：分佈式微服務、分佈式消息中間件

三、數據層：分佈式關係數據庫、分佈式NOSQL數據庫

四、數據層：實時大數據計算平臺

五、基礎設施層：虛擬化、容器

 

雲技術下半場應該是：

一、UI層：IoT智能硬件傳感器、麥克風語音交互、攝像頭視覺識別

二、邏輯層：人工智能關聯推薦&最佳資源調度

三、數據層：跨鏈區塊鏈

四、基礎設施層：量子計算

 

數據輸入：

採集數據：

智能硬件傳感器收集

攝像頭視覺識別收集

麥克風語音交互收集

互聯網爬蟲收集

互聯網OpenAPI來收集

 

PS:將來也不是在邏輯技術層寫死業務規則邏輯代碼，而是設計好模型、觸發消息，經過人工智能最佳調度算法自動調整模型、自動設置閾值來觸發邏輯規則條件發生。因此，中臺應用邏輯是活的，是大數據訓練的人工智能智能執行的。

 

 

 

 

AI 中臺主要成分：

• • 業務理解，根據業務需求設計實施方案，服務編排，通用方案模板管理；
• • 數據處理，包括數據獲取和數據準備與分析；
• • 模型學習 包括特徵工程、模型訓練和模型評估，以及可複用模型庫、算法庫管理；
• • 運行監控 包括模型自動部署運行、性能監控和對外服務接口管理。

 

 

 

中臺與平臺的區別：

中臺和平臺都是某種共性能力，區分二者的重點一是看是否具有業務屬性，二是看是不是一種組織。中臺是支持多個前臺業務且具有業務屬性的共性能力組織，平臺是支持多個前臺或中臺業務且不具有業務屬性的共性能力。

中臺是動態變化的，是數據驅動不斷訓練調整人工智能業務算法和業務模型的。平臺是靜態的，一旦版本發佈，無論你是今年調用這個功能，仍是明年調用這個功能，出來的效果是同樣的

 

業務中臺

 

背景：

企業級業務架構設計來實現組件化開發也是企業數字化轉型的優選路徑，是彌合業務與技術之間「數字鴻溝」的有效手段。

 

舉例：

阿里從 2009 年創建共享事業部開始，幾經曲折，可是一直在積累，直到 2015 年正式發展成中臺戰略。大型架構、好的架構都不是一蹴而就的設計，是根據實踐不斷磨合調整得來的。阿里的中臺大約有十幾個共享業務單元，包括用戶中心、商品中心、交易中心等。淘寶、天貓、聚划算等 25 個大型業務應用都是由中臺的共享業務單元支持的，共享業務單元則由阿里雲平臺支持。共享業務單元的劃分原則其實不是能夠簡單掌握的，要綜合考量設計、運營和工程因素，儘量遵循「高內聚、低耦合」、「數據完整」、「業務可運營」和「漸進」的原則。阿里在劃分中臺時很是重視其業務價值和基於業務的設計，並且有業務架構崗位，每一個共享單元都有業務架構師。但整體來說，其業務架構仍然是領域性的

 

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

 

總結：

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

 

 

業務中臺&數據中臺：

 

1 職能上

業務中臺，更可能是業務支持，好比客戶中心，平臺、身份、驗證，這些統一的東西來自一個地方，分別支持多個系統對業務的管理要求，不一樣系統開發的時候，能夠直接從這裏獲取這個功能，而不須要再開發，從而把更多的系統鏈接在一塊兒。

數據中臺，利用獲取的各種信息、行爲習慣信息和算法，獲取分析結果，好比業務中臺參照的客戶標準和分類方法就是基於數據中臺運算的分析結果，例如需求偏好（客戶標籤）。

數據中臺的數據來自業務系統，有原始數據（不一樣頻次的歷史快照+實時數據）、共享數據（拉到一塊兒）、萃取數據（已經整理的標準化數據、標籤、模型），再反哺給業務中臺用起來。以精準營銷爲例，數據中臺支持算法，業務中臺基於算法的結果，支撐實時推薦。

 

2 內容上

業務中心只能知道當前狀態，數據中心包含當前、歷史、處理數據。好比淘寶、天貓和支付寶，統一的用戶中心數據庫放在業務中臺，登陸、查詢、修改都在此。

而業務的數據，會同步到數據中心，數據中心會保留全部變動記錄，相似於數倉的歷史快照再往上還會有算法模型和統計數據。

 

3 目的上

業務中臺更像一個功能模塊，而不是數據庫，目的是讓業務更專一業務，業務中臺的數據服務中心和業務聯繫緊密，實時作支持，更極致一些。

數據中臺的初衷是爲了讓數據沉澱下來，產生價值，全部業務系統的數據，各業務觸點的信息，會流向數據中臺，解決企業數據孤島的現象，達成信息共享。

 

4 業務系統和兩個中臺的關係

業務中臺使得任何一條業務線都具有整個公司的核心能力。

中臺不影響原業務的管理流程和管理辦法，業務系統生產數據庫還保持在用，只是根據狀況，把業務數據同步到兩個中臺，共性的放到數據中臺。

對於有必定信息化基礎的傳統企業來講，各個系統，只要把共性和個性的部分作個拆分，把共性的匯聚到一塊兒，打通起來，就至關於業務中臺完成大半了，實現難度反而比數據中臺從新搭建來得比較小。

 

 

5 對中臺意義的理解

從技術角度，作中臺是爲了搭建一個靈活快速應對變化的架構，更快實現前端提的需求，避免高度複用的功能重複建設，這是敏捷開發、提升效率的地方。

從業務角度，藉助中臺沉澱能力，能夠支持快速創新，讓研發更靈活，業務更敏捷，以應對將來不可預知的市場變化。退一萬步講，有些功能其餘業務板塊已經作好了，那麼底層只要組合一下便可，更加靈活和快速。

 

業務中臺&大數據：

大數據的下半場爭奪核心是場景。基於業務中臺，實現場景內數據閉環，成爲競爭的關鍵。新業務方式，數據爲業務系統核心，基於技術中臺的能力，將企業內外部數據打通造成數據中臺，由數據中臺驅動業務中臺，並利用業務中臺的組件重構業務系統。因爲有中臺的支撐，各種開放服務能夠對前端應用的快速變化作出響應，所以商業價值會更高。

 

 

 

基於場景的數據閉環會愈來愈重要

單一場景的數據中臺驅動造成業務中臺，由業務中臺支持業務場景落地，而業務場景又會不斷反饋數據給到數據中臺，整個流程會實現數據閉環，循環往復，最終會使得業務更加智能化。場景自己會產生數據，這些數據應用在場景內不會受到限制。例如微信生態內的用戶我的數據很是敏感，但基於微信數據，提供微信生態內的個性化廣告、個性化服務的業務，數據自己不出場景，不受到太大限制。場景內產生的數據價值將來必定會超過外部數據。場景中產生的是正在發生的「熱數據」、「活數據」，用戶在使用Google、百度等搜索引擎時，在搜索結果頁上的每一次點擊（或者翻頁）都會做爲行爲數據被記錄下來，這些數據才能真實反映用戶當前在這個場景的偏好。場景內產生的數據，必定會是最適合場景自己需求，場景內造成的反饋閉環，可以幫助算法持續迭代和產品的關鍵突破，使用戶體驗不斷突破邊界。場景的價值度在逐步提高，這一過程當中，可以將場景理解沉澱，同時造成反饋閉環的，必定是業務中臺，所以，業務中臺是構建場景壁壘的第一個核心因素。數據智能公司可以不斷沉澱對場景的理解能力，創建自身的護城河。

 

舉例：

美團爲例，美團的超級大腦指揮調度着60萬送外賣小哥的行動，高峯期一個小時要處理29億次訂單派遣，天天要處理2000萬個訂單，整個流程徹底是基於數據驅動，由系統自動去運轉

京東超過70%的商品採購都是機器推薦的，京東自營商品已超過2600萬種，只有經過數據造成業務中臺纔可以實現商品採購，不可能依靠業務人員去完成。

從價值度的角度來看，業務中臺可以覆蓋場景的全流程，解決全場景問題，實現技術賦能，按照效果進行收費，價值度最高。

 

【嘗試三句話說清楚】

一、業務中臺的核心是經過「服務複用」，構建「大中臺，小前端」來知足快速發放業務的市場需求，好比「聚划算」團購平臺在投入10多我的開發1個半月就上線，速度遠超過其餘電商平臺從零開始的模式。

二、業務中臺沉澱了信息數據，爲基於大數據挖掘新的商業模式奠基了基礎，好比螞蟻金服基於普通人消費行爲爲金融機構作的徵信系統。

三、業務中臺做爲服務提供者，不須要「業務穩定」，須要不停地提供新的業務支持。

 

 

 

 

 

彩蛋：

滴滴出行構建業務中臺的緣由及在過程當中遇到的問題和應對的策略

 

構建業務中臺的緣由

2015年底，滴滴出行在短期內造成了包括快車、出租車、專車、順風車、代駕等多業務的垂直化架構。滴滴啓動了中臺戰略整合業務系統。決定構建業務中臺主要出於四方面考慮：專業深度、人力資源、用戶體驗、全局打通

專業深度。因爲是多業務垂直化的架構，會有多個團隊開發一樣的架構，這就須要不少的工程師。每一個團隊都是用最快速的方式構建流程，因此技術很難作深。這樣一來，致使客戶端的流暢度不高，後端不穩定，影響可擴展性。

人力資源。原則上來講把每一個團隊加到足夠的人，每一個架構都能有很好的發展。但工程師的薪資都很是高，招聘大量工程師來作一樣的架構，研發成本高昂。很還有些時候，願意花錢，卻招聘不到合適的人。

用戶體驗。流暢度、穩定性、擴展性、界面、交易流程等都是影響用戶體驗的重要因素。在當時的組織結構和研發狀況下，會出現業務的顏色各異，交易流程卻相同的問題，很影響用戶的體驗。

全局打通。全部業務本質都是出行，出行本質有協同效應。但在各自獨立發展狀況下，協同性就徹底沒有，在構建中臺過程當中，能夠逐步把協同性加起來。

構建出行業務中臺在軟件複雜度上的挑戰

構建出行業務中臺並非只有好處，也必定會帶來不少問題，最大的問題是軟件複雜度。

從業務角度來講，把全部業務合併到一個體系下，自己就是很難的事，再加上滴滴出行是實時性O2O業務，場景差別很大，並且做爲互聯網公司，不只不少需求不明確，還會持續變化。這種狀況下，想要用一套相對穩定、相對固定的架構去支持全部業務，十分困難。

從組織角度來講，滴滴出行有多個事業部，業務涉及400多個城市，組織和我的的變化更快。

針對軟件複雜度的挑戰，中臺的目標是：在業務多元化發展的組織中，去構建一套工程架構，構建一套組織結構及對應的管理機制，以保證業務可持續的又快又好的發」。

攻破軟件複雜度問題的具體對策與實踐

在談具體對策與實踐以前，先來看看整個業務中臺的架構設計，以下圖。

 

整個的架構設計分幾個邊界的上下文，好處在於把相關性不強的邏輯拆開，同時在一個相關性下面，經過分層能夠去把業務進行更好的建模。調度層作爲入口去牽引多個業務線，業務流程層爲調度層作服務，狀態智能層用來支持上面兩層。

在對業務和產品進行更好建模的基礎上，進行「五化」：服務化、異步化、配置化、插件化、數據化。

服務化。服務化很常見，如下單爲例，以下圖：

 

下單流程可以調用不少服務，在多個層次，以接口層次結果拆解。這裏須要提醒的是服務化要注意以下三點：

  服務之間的協議和規範要創建好。

  注意控制力度，力度過小、太大都會有問題。

  隨着時間的發展，服務化自己要不斷的演進。

異步化。對每一個事件的非核心或不須要實時反饋給客戶端的邏輯進行拆解，核心的主流程會變簡潔。對非核心的邏輯在事件上作訂閱以後，進行二級處理。以結束訂單爲例，以下圖

 

結束訂單的時候有不少邏輯要作，可是都是經過MysqlBinlog處理或MQ處理。

配置化。服務化和異步化能解決不少迭代效率的問題，但因爲系統、業務的複雜性，各個業務都有些差別，體如今不一樣的產品線、城市、區域、時間等等，配置化核心是對這些進行建模，把每一個對象模型化，抽象成ID，在不一樣的服務化裏把這些可配置的能力進行抽象。具體抽象過程，以下圖。

 

第一級抽象採用是類 iptables 的規則引擎斷定產品分類，第二級的規則引擎，由模塊自定義。全部配置化都是用自生成平臺，要配置什麼，自定義配置便可，這個過程是動態進行的。當前業務中臺已經能夠支持上千個配置點，好比不一樣層次的計價規則不同、不一樣產品線的車樣子不一樣、不一樣的場景，如拼車和接送機，管控規則也不同等等。

插件化。配置化解決的是業務線差別問題，但遇到邏輯差別較大的狀況，就要作插件，統稱爲FPI。

 

在FPI的能力上，不一樣的團隊能夠開發不少插件，在特定的配置點下，把它的邏輯去進行加載。真正業務流程到這兒，能夠調起它對應的插件作出來。對於一些沒有差別化需求的業務，能夠用開發的default邏輯，這是更極端的靈活性的體現。

有靈活性的體現後，團隊還能夠作一些組織上的調整，原來看起來，每一個服務或者平臺是一個垂直化的架構，有些團隊是橫向，是FT，有些FT是接送機FT，專門作接送機的事情。

經過插件的形式在每一個系統加載它的插件，它就能夠跟着業務思考、跟着產品思考這個業務怎麼走、這個產品怎麼演化。相對的邏輯是更加專一的，這也帶來很好的組織結構對中臺的適應性。

數據化。在大數據時代，數據是不得不考慮的問題，因此在業務中臺，要實現全局打通，本質是要把數據打通。因此制定了離線分析與在線決策的方案，以下圖。

 

第一個是離線作分析，能夠作數據血緣、模型訓練，同時能夠把它放到在線決策層面，構建很好的智能客戶引擎和交易引擎，這個能夠干預，由於干預可讓升艙或者多業務線的清單成爲可能。由於有這樣的決策，使在線服務的管控和判決作得更加智能。

數據化方面，須要注意三方面：

  讓數據更加規範和標準化。

  構建完整的數據流，從在線到離線，從日誌到模型的在線使用。

  引入機器學習的算法、人工智能的算法去構建在線數據智能的決策。

這是業務中臺的五個對策，主要解決傳統的系統架構問題，怎麼作到高耦合和內聚，怎麼提升迭代。配置化和插件化解決靈活性問題，把靈活性開放給不一樣團隊。數據化其實是中臺賦能業務，有中臺的賦能才能變得更好。

 

經驗總結

 

第一點：從最大的業務孵化中臺是滴滴出行構建業務中臺最大經驗，由於最大的業務最複雜，把最複雜的業務搞定，用最複雜的業務落地別的業務會容易。從快車開始作，逐步整合專車、出租車、代駕等。

第二點：穩定，中臺對業務有收益，最根本的是保證穩定，穩定是發展的前提和基礎。在整個構建中臺的過程當中很是重視穩定性，有各類機制，包括灰度發佈、分層次發佈、流量回放、全鏈路壓測等等，保證代碼的質量和系統的穩定。

第三點：增強溝通，平衡多業務的優先級。滴滴出行有多個業務，有不少大區和城市，每一個地方都有不少需求，要有一套機制和資源池，如何保證相應每一個業務都能按照所對應的在公司的重要性的部分資源，要保障它的靈活性和效率，因此要有不少溝通工做，有不少平衡的工做。

第四點：中臺系統要不斷演進，不能一層不變，要發現問題、解決問題。業務中臺不是一蹴而就，而是要在發展過程當中不斷的變化，持續迭代。

第五點： 「沒有最好，只有最合適」！全部中臺都必定是適合某個公司特色，最合適的中臺是當你深刻了解業務、產品、系統、組織，並且不只瞭解今天在哪裏，還要了解過去是怎麼演變而來，將來又會怎麼演化。只有當了解全部的東西以後，才能作出最好的中臺架構的設計。

 

參照博客:http://www.javashuo.com/article/p-mvntgsnf-dv.html