參考：

https://www.sohu.com/a/331004369_692515

http://blog.sina.com.cn/s/blog_493a84550102z8uw.html

https://zhuanlan.zhihu.com/p/94941463

學阿里中臺，就要學最值錢的部分：中臺建設方法論！

阿里研究員--玄難，曾在《從應用到中臺--業務平臺的演進》的分享中提到，阿里中臺化主要解決4個問題：

1、信息獲取成本高

2、互聯互通成本高

3、服務具有不確定性

4、低水平重復建設

如何來解決這些問題呢？可以去看一下傳統的建筑行業和互聯網本身的基礎設施建設。基本上靠三個東西來共同解決一個復雜生態的協作問題：

1、協議標準、運行機制。

2、滿足標準的分布式執行單元。

3、中心化的控制單元。

比如說移動互聯網，我們現在之所以上網能用手機，它的根本是什么呢？網絡的協議，就是我們整個對網絡的理解，它是最基本的思考。

然后我們有很多設備，不管是什么品牌的手機，只要滿足3G協議、4G協議，就可以插上卡上網。也就是通過這張sim卡確定了我們的身份，從運營商控制網絡上獲取了控制信息。知道我們是誰，能不能上網，網絡速率等等信息。

01

阿里中臺建設的基礎協議

回頭來看阿里的電商生態，就是要根據對商業的理解，把一些基礎協議梳理出來。例如什么是業務？什么是業務身份？各個業務領域的邊界是什么？每個領域提供的基礎服務是什么？領域服務和領域服務之間的流程鏈接標準是什么？再在這些思想的指導下去建立業務平臺化的實施標準和業務管控標準。

電商業務中臺由一系列：業務能力標準、運行機制、業務分析方法論，配置管理和執行系統以及運營服務團隊構成的體系，提供各業務方能夠快速，低成本創新的能力。

02

中臺基礎設施：中心化控制單元

中臺建設需要一個中心化控制單元，就是我們的運營平臺。它主要由協議標準、能力地圖、業務需求結構分解、全局業務身份、業務全景圖、業務度量等構成。能讓我們有一個地方縱觀全局，把控細節。

其中能力地圖是一個最基礎的設施，要能把電商生態里面的能力都呈現出來，并在過程中不斷的優化完善。就象我們現在出行離不開XX地圖一樣，今后所有的業務方需要做業務規劃，業務創新，都可以到這兒來尋找需要的基礎能力。

為了能將業務邏輯本身與實現邏輯分離，可以將業務邏輯下發給不同實現的執行系統，引入競爭，方便業務平臺的改造升級，我們要將控制信息從業務平臺中抽離到業務中臺，以業務身份為主線來進行組織管理和呈現。并以生態角色的視角來重構信息架構。這樣的變革對我們原來的系統架構提出了更高的要求。

通過業務中臺化，我們把所有業務的數據匯集沉淀。每個業務它是怎么出來的，出來之后做了哪些業務需求，業務活動，每個業務活動的效果是怎么樣的，都可以沉淀下來。

當一個新業務來了之后，我們就可以讓他看到前人成功和失敗的經驗。逐步可以做一些系統建議，建議他怎么去做營銷活動，怎么做效果分析。這樣我們能通過數據最終反過來支撐我們的業務創新。

業務平臺是在最基礎技術和前端大家能感受到交互技術中間的一層。這一層不是外部消費者和入門級技術人員能直接感知到的。但是這一層才是真正制約我們整個商業發展速度的核心地帶。業務平臺如何能支撐幾千種業務，幾萬人在同一個時間里面進行變更，這個對業務業務的抽象能力和系統架構能力的要求都是極高的。

03

中臺化的核心目的是降低成本

阿里中件間&業務中臺 總監，謝良純，在采訪中提到，中臺化的核心目的是降低成本。成本可以從兩個維度看，一個是資源浪費方面的成本，即公司有三四個業務線都在做同樣的事情了，那技術上實現能不能融合可復用的部分？另一個則是時間成本，即新業務能夠足夠敏捷地去使用既有的技術模塊去做探索。

實際上，實現中臺化的環境是相當苛刻的。連Supercell 的 Paananen 自己都說，他認為Supercell 的經驗不是對所有公司都有效，有它自己的特殊性。他覺得 Supercell 的每個員工，都是能在外面成立公司自己當老板的，因此這種精英文化和中臺化在公司得以保持。

國際知名咨詢公司羅蘭貝格高級合伙人王欣曾表示，當企業發展到一定規模，一定會開始思考兩個問題：第一，組織是否存在重復建設和資源浪費；第二，如何沉淀企業核心競爭能力，以更好地支撐新業務的發展。這也是許多企業選擇中臺的原因，中臺在本身定位上，具備了以上先天優勢。

04

有了前臺和后臺，為什么還需要中臺？

行業觀察員王健，曾撰文分析企業為何需要中臺，企業后臺往往并不能很好的支撐前臺快速創新響應用戶的需求，后臺更多解決的是企業管理效率問題，而中臺要解決的才是前臺的創新問題。

大多數企業已有的后臺，要么前臺根本就用不了，要么不好用，要么變更速度跟不上前臺的節奏。

我們看到的很多企業的后臺系統，在創建之初的目標，并不是主要服務于前臺系統創新，而更多的是為了實現后端資源的電子化管理，解決企業管理的效率問題。這類系統要不就是當年花大價錢外購，需要每年支付大量的服務費，并且版本老舊，定制化困難；要不就是花大價錢自建，年久失修，一身的補丁，同樣變更困難，也是企業所謂的“遺留系統”的重災區。

總結下來就兩個字“慢”和“貴”，對業務的響應慢，動不動改個小功能就還要花一大筆錢。

中臺就像是在前臺與后臺之間添加的?組“變速?輪”，將前臺與后臺的速率進行匹配，是前臺與后臺的橋梁。它為前臺而生，易于前臺使用，將后臺資源順滑流向用戶，響應用戶。

中臺很像Pace-Layered中的SOD，提供了比前臺（SOI）更強的穩定性，以及?后臺（SOR）更高的靈活性，在穩定與靈活之間尋找到了?種美妙的平衡。

中臺作為變速齒輪，鏈接了用戶與企業核心資源，并解決了配速問題。

有了“中臺”這?新的Pace-Layered斷層，我們即可以將早已臃腫不堪的前臺系統中的穩定通用業務能力“沉降”到中臺層，為前臺減肥，恢復前臺的響應?；又可以將后臺系統中需要頻繁變化或是需要被前臺直接使用的業務能力“提取”到中臺層，賦予這些業務能力更強的靈活度和更低的變更成本，從而為前臺提供更強大的“能力炮火”?援。

所以，企業在平臺化的過程中，需要建設自己的中臺層（同時包括技術中臺，業務中臺和組織中臺等等）。

05

中臺建設要避開哪些“坑”？

阿里專家謝良純在采訪中曾提到，現在在中臺建設里面，常見的一些“坑”，有以下幾個：

1、要真正樹立一個認識：中臺是企業IT變革的一個起點，而不是單純認為，我就是做一個項目，我搞一個采購中臺，就解決了所有的問題，非也。你要深刻意識到它是變革的關鍵，認真去做戰略規劃，應該采用什么樣的技術、什么樣的平臺、什么樣的人員的配套？需要有這樣統一的規劃。把一個項目當成一個中臺去做，這是不合適的，但如果倒過來，我規劃了一個中臺，做一個項目的試點，這是對的，所以這就是一個認識的問題，不見得多投多少。把項目當成中臺去做，這個“坑”是很多人容易踩上的，這是一個最大的坑。

2、第二個“坑”發生在選擇中臺的技術平臺時，很多人想，我先選一個便宜的能用的平臺，以后我再選一個復雜的、更全面的平臺。事實上，他們不知道，這就跟“種菜”似的，一旦菜長起來了，你要把底下土壤換了，這幾乎是不可能的事情，一般要推倒重來。你一定要相信一點，如果開源軟件就能簡單解決這么復雜的大問題，阿里還養那么多技術專家干什么？在選擇技術平臺這一塊，這是一個大家踩的最多的一個“坑”。

3、第三個坑，我認為也是一個坑，我覺得大家對試點、試點項目這塊不太重視，往往會抱有這樣的想法“反正是試點、就試一試“。在中臺建設里頭，我覺得試點項目是非常重要的，你一定要抱著必勝的態度去做試點。因為中臺的建設會涉及到技術升級、業務升級、組織升級等很多變化，你只有抱著必勝的這樣一些態度去做試點，那這些相應的變化，你才能應對好，否則到最后你就湊合做個試點，大概率是失敗的。

06

中臺建設難題一：中臺團隊離業務遠

公眾號作者劉飛曾撰文指出，中臺團隊離業務遠的問題。

為什么中臺化的難度是：技術<數據<業務<組織？因為越往后，越需要業務團隊的介入，越要有業務認知才能做到中臺。而中臺團隊，天然就是離業務遠的。

各公司跟中臺團隊的協作，都存在很大的低效問題，一線的前臺業務團隊，要反復與中臺溝通，才能講清楚業務需求的背景，在大公司，跨部門協作都會徒增成本。另外對于中臺業務團隊來說，長期離業務很遠，沒有成長性，在判斷需求時也不準確，很難獲得前臺業務團隊的信任。

久而久之，就變成了中臺團隊純支撐、被動接需求的狀態，成為“雞肋中臺”。更大的問題在于，中臺團隊的價值就是整合需求、抽象能力的，在對用戶和業務不夠了解的前提下，這塊就會做得特別吃力。如果是多個前臺業務的需求有了沖突，中臺團隊未必能做好協調，多方要反復溝通扯皮。

針對這個問題，通常有兩個解決方案：

第一，中臺職責直接由最大業務方來擔任

像某找房App的中臺模塊，就是由二手房先行推進的；而大多數通用的乘客司機產品流程，在滴滴也都是快車先發起的。最大的業務方離業務足夠近，能自己決策判斷大多數需求，更加高效。

這樣以來，就從“硬找一個中臺團隊來收集大家需求”變成了“老大哥發揮余熱，把自己的能力共享出來”，具體要怎么用，仍然是各自團隊來決策和執行。

第二，讓中臺團隊做業務閉環

這只適用于少部分情況，即中臺業務本身可以自閉環。常見的比如各公司的賬號體系（包括注冊登錄）、阿里的支付和訂單流程、滴滴的地圖和導航。這些業務與其它業務的關聯度不大，可以解耦，可以自己完成從用戶到業務的認知和決策，那就可以獨立出來自己做，其它業務希望使用的時候，對接通用接口就可以了。

而大多數中臺團隊負責的業務不太容易自閉環。比如滴滴不同業務線的接單流程，就很難抽象出來讓中臺團隊直接閉環自己做；或者像阿里不同業務線的商品部分、訂單流程部分和支付部分可以抽象，但用戶體驗方面，不同前臺業務差異太大，則很難抽象。

07

中臺建設難題二：中臺需求優先級難排序

互聯網技術和管理專家 黃哲鏗，曾撰文闡述過這個問題主要的兩個解決辦法：

建立以價值為導向的需求治理機制
基于OKR的需求聚焦與創新

第一，建立以價值為導向的需求治理機制

以價值為導向的需求治理機制，其目的是把有限的開發資源，投入到更有價值的項目上，該機制分成幾個部分：

建立需求管理閉環。以價值為導向的需求治理機制，是在需求提報環節，提出該需求的價值預估，即這個需求將給業務帶來什么樣的價值，這些價值要能夠量化、能夠追蹤。比如，一個結算系統需求，價值是：提升客戶對賬效率20%，上線后會來驗證效果，看看是否達到預期。

整個閉環，分成：提交需求、排期開發、上線運營、需求調整，4個環節。

在提交需求環節，需求提報方要給出可量化的價值預估。

在排期開發環節，開發團隊將需求池里的需求按價值大小進行PK，價值高的需求會排在前面，優先安排開發資源 。

上線運營環節，對該需求的價值進行驗證，驗證的結果將影響需求提出方的信用等級，信用等級將用于需求PK階段，作為加減分項。

需求調整環節，也將價值做相應的調整，形成新的需求，反復迭代，形成流程的閉環。

制定需求優先級的準則。從緊急程度、重要程度將公司的需求分成三個等級，P0為優先級最高，P2為優先級最低。如下圖所示，橫坐標按重要程度，分為三類：公司戰略項目、各部門重要項目、非核心業務項目。

例如：公司戰略項目和部門重要項目，同時又非常緊急的，這類項目是P0級項目。其它類型項目，你可以輕易的對號入座了。

開發資源沖突解決辦法。在協商未果的情況下，自下而上層層升級，直到問題解決。此外，跟業務方的月度需求溝通會，季度需求復盤會，這類正式溝通會議要形成常態。

第二，基于OKR的需求聚焦與創新

什么是OKR？

OKR是一種戰略目標任務體系，是一套明確目標并跟蹤其完成情況的管理工具和方法，由英特爾公司發明。
OKR由一個需要極致聚焦的明確目標和量化該目標的數個關鍵結果這兩大主要部分組成。
O是Objectives，KR是Key Results，OKR就是Objectives and Key Results，即目標與關鍵結果法。

OKR由英特爾公司發明，安迪 · 格魯夫解釋道：

這種目標管理的兩個關鍵詞是 “目標”和“關鍵成果”， 它們分別對應著兩個目的： 目標是方向， 關鍵成果需要得到評估， 但是最終結果顯而易見，根本不需要出現 “我做了這個嗎，或者根本沒做？” 那樣的爭論，是或否，就是這么簡單。

英特爾按OKR方法，制定戰略，并將其轉化為可實施、可協作的項目。

簡而言之，OKR讓決策者和公司的其他成員總是能夠把時間和精力聚焦在最重要的任務上，從而完成公司的使命。

在OKR的目標和關鍵結果制定過程中，有一個非常重要的環節，叫做“對齊”，指的是每一次制定完OKR之后，要看看你上級的OKR，跟你定的OKR，是不是方向一致的，這叫“向上對齊”。

一旦出現了開發資源沖突，就把大家拉到一起，把各自的OKR列出來，看看我們是否在同一個方向上聚焦，如果不能達成一致。就把上級領導的OKR拉出來，看看他的OKR聚焦哪個方向，甚至看公司CEO的OKR，通過聚焦目標、對齊的方法來解決開發資源沖突。

08

本文要點小結

中臺建設的基礎協議

就是要根據我們對商業的理解，把一些基礎協議梳理出來。例如什么是業務？什么是業務身份？各個業務領域的邊界是什么？每個領域提供的基礎服務是什么？再在這些思想的指導下去建立業務平臺化的實施標準和業務管控標準。

中臺的基礎設施：中心化控制單元

就是運營平臺，它主要由協議標準、能力地圖、業務需求結構分解、全局業務身份、業務全景圖、業務度量等構成。能讓我們有一個地方縱觀全局，把控細節。

中臺化的核心目的是降低成本

一個是資源浪費方面的成本，即公司有三四個業務線都在做同樣的事情了，那技術上實現能不能融合可復用的部分。另一個則是時間成本，即新業務能夠足夠敏捷地去使用既有的技術模塊去做探索。

有了前臺和后臺，為什么還需要中臺

中臺就像是在前臺與后臺之間添加的?組“變速?輪”，將前臺與后臺的速率進行匹配，是前臺與后臺的橋梁。它為前臺而生，易于前臺使用，將后臺資源順滑流向用戶，響應用戶。

中臺建設要避開哪些“坑”

1、中臺是企業 IT 變革的一個起點，而不是單純認為，我就是做一個項目，我搞一個采購中臺，就解決了所有的問題

2、第二個“坑”發生在選擇中臺的技術平臺時，很多人想，我先選一個便宜的能用的平臺，以后我再選一個復雜的、更全面的平臺。

3、第三個坑，就是大家對試點、試點項目這塊不太重視，往往會抱有這樣的想法“反正是試點、就試一試”。

中臺建設難題一：中臺團隊離業務遠

有兩個解決方案：

第一，中臺職責直接由最大業務方來擔任。

第二，讓中臺團隊做業務閉環。

中臺建設難題二：中臺需求優先級難排序

有兩個辦法：

第一，建立以價值為導向的需求治理機制。

第二，基于OKR的需求聚焦與創新。

業務中臺建設方法論

今天準備分享下業務中臺規劃建設方法論對傳統企業架構規劃方法的改進。對于中臺建設方法論簡單來說應該結合如下幾個方面的核心思想，具體包括：

SOA思想：重點體現縱向到橫向，服務識別和基于服務編排和組合
微服務思想：體現構建的時候傳統單體進行微服務化，大拆小
中臺思想：體現在構建業務和應用架構的時候，共性業務能力下沉
云思想：重點體現由傳統的接口服務集成，轉變為集中化建設和能力服務開放

對于傳統企業架構思想可以看到基于業務驅動IT思路，從端到端流程分析出發進行企業核心的業務流程活動，業務對象識別，然后再規劃業務架構，數據架構，應用架構和技術架構，在應用架構中又包括了我們常說的集成架構規劃。

傳統企業架構方法核心說明

從頂朝下和從底朝上結合

在企業架構規劃中，架構分析的入口點，我們認為合理的方式是從整體的端到端流程分析入手，細化到各業務域的端到端，經過不斷的流程分解到3-4級流程，最終細化到最底層流程（如EPC流程，它是流程，本身也是業務功能）。另外的一個方式是直接從業務活動信息收集入手，如根據組織架構和崗位職責直接收集業務功能點。

第一種方式既看到面又看到點，從上到下層層推進；而第二種方法則是容易只看到點，但無法貫徹整個企業端到端流程。

當然，流程分析并不一定能夠涵蓋所有的業務功能點，因為有些業務功能本身便是最底層的EPC流程，往往并不是從高端的端到端流程分解而來，如用章管理是一個業務功能和EPC流程，但并不一定能夠掛接到高端流程上面。

這也是端到端流程分析要注意點，即從頂朝下和從底朝上要相互結合。高端流程分析和分解是建立全局思維，但是仍然要借助第二種方法收集完整的業務和活動。

從業務活動分析中發現業務對象

流程到子流程，再到業務活動，業務活動中承載的是業務單據和業務實體。需要對業務實體進行抽離，進行數據層面的數據建模和分析。分析在流程各個階段和活動中產生的業務實體之間的關聯和依賴關系。業務域對應到數據域和數據分類，進一步可以分析到具體的概念模型或邏輯模型。

流程分析偏業務操作和事件，而數據正是業務操作的對象。SOA中強調操作和數據解耦，則正好是分析的兩個維度。

業務組件劃分-微服務的雛形

業務架構中的業務組件劃分強調的是業務本身的高內聚和松耦合原則。

對于任何一個業務域基本有兩種類型，一種是數據驅動型，一種是工單任務型。如資源、資產等核心數據對象，業務操作層面重點是對數據對象實現全生命周期管理。因此業務組件劃分基本遵循底層為基礎數據支撐層，上層為生命周期管理層，覆蓋該數據對象的核心生命周期階段。這是業務組件劃分的一個基本思路。

對于業務架構的構建，特別是我們對某個業務域并沒有深入的理解前，最好的方式就是流程驅動分析，抽離數據進行數據建模，然后進行CRUD矩陣分析，分析數據和業務功能的關系。對底層的業務功能進行組合滿足高內聚松耦合的原則，然后從底向上的對細粒度的業務功能進行組合，形成高內聚的業務組件。當然在整個過程中往往我們會參考業界標準的業務架構參考模型，如供應鏈的scor模型，電信行業的etom模型等。

業務架構完成后，將會過渡到應用架構，業務架構和應用架構基本是對應的。

其中較大的差別點在于業務架構只關注業務，業務本身分為功能性需求，非功能性需求。非功能性需求中包括了平臺層面的支撐需求，即應用的集成支撐和數據的集成支撐，公共平臺層功能等。另外還包括了純技術層面的非功能性需求。對于前者需要體現到應用架構中我們往往會分為技術支撐平臺和應用支撐平臺。

技術支撐平臺包括了安全，管控等；而應用支撐包含了數據平臺，集成平臺和流程平臺等。應用架構一般會分為支撐層，應用層和決策層。

服務架構需要考慮業務系統間的集成點。這個集成點的分析我們期望可以將端到端流程結合應用架構中的業務系統，CRUD矩陣分析形成跨業務系統的跨系統交互流程圖。這種流程圖已不是純粹業務層面的流程圖，而是做系統交互分析的跨系統交互流程圖。所有的跨系統交互點則為流程驅動下的業務集成點。而CRUD矩陣分析則幫助我們分析出數據驅動的數據集成點。前者為業務服務為主，而后者即以數據服務為主。兩者在分析完備后最終都體現到應用集成架構中。

業務中的平臺級和非功能性需求轉化到應用架構中的底層支撐層，對底層支撐層中的核心技術進行抽取，最終轉化到一個完整的技術架構。技術架構和業務無關，它所提供的是底層技術支撐層能力。

技術架構逐步轉化到公共的平臺層，提供核心的資源池能力。業務組件本身轉化為能力單元，業務組件由平臺資源承載，提供業務服務能力。業務服務最終又可以通過靈活的配置形成完整的業務應用。因此我們所說的解耦不僅僅是業務組件間的橫向解耦，還包括了業務組件到底層平臺，業務組件到上層應用間的縱向解耦。

對傳統企業架構規劃方法的優化

從上面我們對傳統企業架構規劃方法的核心邏輯說明來看，傳統EA企業架構規劃方法仍然相當完整，但是我們也需要看到在整個SOA和云架構思想下，在中臺和微服務思想逐步演進的過程中，傳統的企業架構規劃也需要進行優化和調整。

傳統企業架構規劃方法仍然是按照傳統遺留大單體應用垂直縱向建設的模式來進行的規劃，同時很少考慮到了集中化的云平臺建設模式。然后在當前企業的信息化規劃建設，平臺+應用構建模式已經逐步成為主流。

同時在平臺+應用分層構建的模式下，進一步將傳統應用大單體拆分為多個獨立自治的微服務進行獨立建設和管控，而對于平臺層則進一步融入云平臺建設思路，包括最近1到2年我們談的最多的面向云原生的解決方案。

這個云原生已經從傳統的IaaS云平臺過渡到了完整的PaaS云平臺和技術服務能力提供。

基于以上分析，可以看到傳統企業架構優化點主要體現在

從縱向到橫向：架構規劃分析需要從縱向過渡到橫向分層規劃設計
數據庫拆分：業務架構和數據架構結合分析，在規劃階段形成數據庫拆分
業務和應用架構融合：在剝離了平臺后，進一步融合業務和應用架構
基于業務組件規劃設計微服務
技術架構規劃新增加PaaS和技術中臺服務內容

以上即是我們考慮需要進行優化的一些關鍵點。基于上面的思路，我們可以看到中臺規劃和建設的方法論可以進一步簡化為下圖。

從上面圖可以看到，對于流程分析和數據架構分析仍然無大變化，核心都是為了劃分業務組件和微服務模塊。但是對原來的業務架構和應用架構可以合并，原因就是傳統應用架構的平臺層已經將其移到技術架構規劃中。其次就是技術架構不再是單純的IT基礎設施架構，而且需要包括我們當前說的PaaS云平臺和面向云原生的整體解決方案。

在整個中臺建設規劃中可以看到業務中臺規劃簡單的重點仍然體現在兩方面：

其一是業務中臺中的微服務如何拆分
其二就是微服務究竟應該暴露哪些獨立的可復用API接口

對于中臺微服務粒度究竟應該如何拆分才合適，參考我前面的文章：

中臺規劃中微服務粒度究竟應該如何劃分？你可以從以下幾點考慮

而對于技術中臺可以看到，實際上包括了多個方面的內容，這個在我們前面的文章也有提到，即微服務開發框架和環境，DevOps支撐平臺，容器云平臺，共性技術服務能力，API網關和能力開放平臺，運維監控平臺。這些才構成一個完整的技術中臺，如下圖：

中臺構建思路-橫向分層和縱向拆分

大家都比較清楚，中臺架構咨詢和建設來源于互聯網企業，然后逐步轉入到傳統企業內部，對于互聯網企業基本也給出了中臺建設的初步思路和方法論，但是如果簡單的照搬這些思路到傳統企業內部，往往行不通。那么我就需要首先分析互聯網企業和傳統制造類企業在業務和IT建設中的一些差異。

初步比較關鍵點如下：

1. IT系統受眾：互聯網后臺管理用戶少，而外部用戶多；而傳統企業大部分為內部用戶。
2. 前臺應用的敏捷性：互聯網對前臺敏捷度要求高，而傳統企業前臺應用敏捷度要求并不高
3. 業務邏輯復雜度和強事務要求：互聯網相對低，而對于傳統企業IT系統業務邏輯更復雜

當我把上面幾點想清楚后，實際上對于傳統企業中臺構建的差異點或思路基本就想清楚。對于第1和2兩點剛好對應到我們在進行橫向分層構建上的差異，第3點對應到縱向拆分上的差異。具體為：

1. 橫向分層上：不是所有傳統IT都要轉為中臺+前臺模式，而是需要考慮受眾和敏捷性要求
2. 縱向上：不是微服務拆分的越細越好，而是要考慮業務邏輯和事務處理需求

如果企業內部中臺構建不考慮上面兩點，而是完全照搬互聯網企業的中臺多個中心+前臺應用的構建模式，那么就是走極端，為了中臺而中臺。因此在企業中臺構建時候一個關鍵點即：企業中臺的構建不能脫離實際業務需求和場景，所有技術選擇一定要追溯業務需求和目標。

1. 橫向分層：中臺和前臺分層構建思路上的思考

首先我們來看下橫向分層上面的思考，即中臺+前臺構建思路上的差異思考。

前面已經談到過了企業內的IT系統建設更多的是面向企業內部員工或業務部門，其受眾相對來說比互聯網應用小很多。那么在這種情況下如何來構建中臺，或者說中臺+前臺分層構建的思路從哪里入手呢？

1.1 企業業務需求從內朝外擴展和延申的時候

第一個思考點就是企業內部業務從內到外延申的時候，比如企業需要自建電商平臺直接服務于外部的C端客戶，比如企業需要和外部的上下游，合作伙伴對接的時候。當出現這種延申的時候，我們就可以理解為可以參考中臺+前臺構建思路來進行。

其核心原因就是，延申業務本身業務敏捷性述求高，而且延申業務不會產生企業需要的核心業務對象和數據，僅僅是產生中間過程對象。在這種場景下最合適進行中臺+前臺模式進行構建。

即當企業構建自建電商平臺的時候，你完全可以參考互聯網電商平臺中臺+前臺的構建方式來構建。其次企業內部的圍繞ERP為核心的IT系統需要開放能力給業務系統用，而這個時候你可以將企業內部的業務能力整合后形成一個能力中臺再開放給電商平臺使用。

這個能力中臺可以理解為企業內部IT系統能力服務的代理和整合。

1.2 對應企業內部面向全體員工的業務系統建設

企業內部有很多IT系統，其中類似采購，財務等核心系統往往只面向供應鏈，財務部門。而對于人力資源，辦公，報賬平臺等業務系統往往則是面對全體員工。正是由于人力資源管理，報銷平臺這些系統受眾廣，我們才看到企業內部業務架構和IT架構優化轉型的時候會提出共享的概念。即經常看到的企業財務共享中心，企業人力服務共享中心。

面向全員的系統受眾廣，往往導致了業務敏捷訴求高，再業務敏捷述求高的情況下我們就可以考慮優先采用中臺+前臺的建設模式進行構建。提升前臺應用的敏捷響應度。

1.3 企業新構建的核心業務系統的外圍系統，本身無核心業務對象數據產生

最后一種常見就是企業新構建的核心業務系統的外圍系統，這類系統的特點就是本身無核心業務對象數據產生，更多是產生輸入到企業內部核心業務系統的正式數據。

比如我們常見的企業招投標管理系統，這個系統存在的價值就在于產生招標評審通過的供應商信息導入到供應商或采購系統中，其他都是招投標過程業務數據。還有類似的就是我們常見的員工報銷系統，員工報銷系統同樣不產生核心數據，更多是生成中間過程的報銷單據，形成最終的應付憑證信息導入到企業內部的財務系統。這類系統本身往往就適合采用中臺+前臺模式構建。

2. 縱向切分：從單體應用到微服務化的思考

首先我想說明下，在中臺和微服務的概念還沒有提出的時候，我在企業私有云PaaS平臺構建中就在談企業內部信息系統建設的組件化拆分，提出了平臺+應用構建，業務能力組件化，組件能力服務化。

在拆分后不再強調業務系統的概念，因為業務系統的概念和邊界已經模糊了，業務系統已經被打散為多個微服務模塊。對于這種思路我們再來回顧下更多的是縱向的思路。即：原有業務系統拆分為多個業務組件，每個業務組件從數據庫+中間件+業務邏輯和前臺完全獨立并松耦合。

也就是說原來的一個采購系統可能拆分為了招投標，供應商物料管理，采購訂單，采購執行監控，配額管理6個微服務組件。這6個組件都對應獨立拆分后的數據庫。這個和我們現在的微服務架構完全縱向拆分獨立的思路完全是一致的。

但是我們仍然發現了一些問題，即業務組件間耦合性很強，導致后續應用開發，團隊協同困難。其次，拆微服務必須是橫向和縱向兩個維度結合共同來拆，而不是監控的模塊劃分，這個我在后面幾篇文章還要詳細談。

那么對應縱向拆分，從單體應用到微服務化，我們實際需要考慮的關鍵點有哪些？

2.1 以是否拆分數據庫的粒度來考慮業務組件粒度

在這里我提出以是否拆分數據庫的粒度來考慮業務組件的粒度。比如供應商和物料兩個核心對象的管理，我們發現兩者耦合性相當強，因此我劃分為一個大的業務組件為采購基礎數據中心組件。

對應采購基礎數據中心組件里面，我們的思考如下：

a. 只存在一個獨立數據庫，不再根據對象繼續拆分
b. 只存在一個中臺邏輯層提供服務，不再拆分
c. 可以構建多個前端或前臺應用，這個粒度可以靈活拆分

即我們打破原來我們經常談到的前端前臺，中臺，數據庫必須1對1的模式。這樣既兼顧了底層的數據庫邏輯處理和事務管理要求。同時又滿足了前端的細粒度構建。

2.2 對外服務提供和上層應用支持邏輯層組件拆分

這個也是我這次提出的一個觀點，即在構建中臺的時候，我們將對外服務能力提供作為中臺層的核心模式，而對應上層應用支持的邏輯層不再納入到中臺層，這個邏輯層可以和上層應用緊綁定，可以走類似RPC或直接的jdbc模式進行數據庫訪問協同。

這種拆分的好處是我們真正將應用功能的邏輯層，和中臺服務邏輯層關系和邊界劃分清楚。在這樣劃分后我們更加清楚后續中臺的范圍，包括在性能出現瓶頸后組件的彈性擴展范圍。

中臺構建方法論整體說明

在前面我們已經給出了中臺建設方法論對傳統企業架構規劃方法的優化和改進關鍵點，在這里我們進一步做詳細的描述說明。

1. 業務流程分析，通過業務流程分析識別業務功能和業務對象

這個點和傳統企業架構規劃思路基本一致，從業務流程分析入手，從最頂層的業務流程和業務價值鏈模型，逐層分解到三到四級流程，找到關鍵的業務活動單元和業務對象，然后從下朝上構建業務架構。

在整個流程建模和分解過程中，我們找到兩個關鍵內容

其一：業務活動或業務功能點
其二：業務對象或數據對象

注意，在傳統業務架構建模方法上，我們務必要分析到最底層，最底層的意思可以理解到了最下面的一個業務功能點的業務操作過程說明。為什么要分析業務操作說明？因為通過業務操作分析，實際上你會發現關聯或依賴的數據對象才能夠識別出來。只有這樣業務對象或數據對象才能夠識別完整。

2. 基于高內聚，松耦合原則來拆分業務域或業務模塊

在業務功能和業務對象都識別出來后，接著重要的一個步驟就是業務域的劃分，你也可以理解為中臺規劃中的一個關鍵，就是業務組件或微服務模塊的劃分。劃分的原則是高內聚和松耦合，但是核心的方法仍然業務和數據各種交互矩陣分析。其中包括

業務組件交互矩陣：橫向和豎向都是業務組件，內容單元格里是具體的業務交互接口點，通過此矩陣可以看出業務組件的劃分是否會導致大量的業務接口存在，分析每個業務接口產生的原因，以進行組件的合并、業務功能轉移等。

業務對象和業務交互矩陣：橫向是業務組件和業務功能，縱向是具體的業務對象，內容單元格是具體的CRUD信息（即傳統的CRUD矩陣分析）。對于同一個業務對象，CUD操作盡量減少分離，而讀操作則可以共享，以減少業務對象的多頭管理和維護，將業務表單和數據的維護盡量控制在同一個業務大組件中完成，減少數據間的交互和傳遞。

流程交互分析矩陣：橫向是具體的流程信息，縱向是具體的流程活動信息，在這個矩陣圖上可以看到同一個流程活動或流程片段往往存在于多個不同的流程。該分析的重要作用是對流程建模中可復用的流程片段或流程活動進行抽象和分析。

功能業務組件分析矩陣：橫向是具體的業務組件，縱向是業務功能，在該交互分析上重點是分析具體的可復用的業務功能，以對可復用的業務功能進一步進行抽取，形成可復用的服務。

注：對于具體的企業架構規劃咨詢方法，可參考我近期會出版的《SOA與 大數據-企業私有云平臺規劃和建設》一書。在京東和當當書店均能購買。

當我今天重新回顧這個矩陣分析方法的時候，我發現了一些變化點。

比如我們原來談到的CUD操作盡量減少分離，而讀操作則可以共享，這個并不絕對。即我們的矩陣分析方法優先要解決的不是業務功能模塊然后拆分的問題，而是要優先思考數據庫拆分問題，即哪些數據對象應該聚合在一起。

簡單來說在業務對象和業務功能的矩陣分析圖中，我們需要進行一些特殊標志。

對應業務功能需要同時操作多個數據對象并同時入庫的進行紅色標注。
對于業務功能需要同時查詢多個數據對象并返回結果的進行綠色標注。

這個分析的核心目的就是通過業務功能的分析來評估業務和數據對象之間本身的耦合性。對于耦合性高的實際上在進行數據庫拆分的時候并不建議拆分開。

在前面一篇文章我就談到拆庫是基礎，以拆分完的數據庫粒度來作為實際的業務組件或模塊的粒度。但是單個業務組件本身仍然還可以在前臺或前端構建多個微服務模塊。這個也是我近期思考提出的一個重要觀點。

因此我們看到業務數據的交互矩陣分析重點是數據拆分，而不是哪些業務功能要聚在一起。

上層的業務功能，比如有10個業務功能，你可以打包為5個微服務，也可以打包為10個，這個不是關鍵。在這個思考清楚后，我們再來看上層的業務模塊如何劃分，即哪些業務功能點應該打包在一個也業務模塊里面。那么這里的分析方法又該是如何的呢？

在講解這個前，我們首先將CUD操作拆分為四個操作，即增加一個Import操作，變化為ICUD操作。對于Import操作理解為業務功能在完成后形成正式的業務對象，作為流程末端的輸出寫入，即Import操作。比如招投標管理里面有一個功能供應商認證，該功能在認證和審批通過后會形成一個合格供應商數據，寫入到供應商管理模塊。那么這個供應商認證功能對于供應商對象即是Import操作。

因此，我們可以將對數據對象的CRUD操作全部打包在一起形成一個完整的業務模塊。對于R我們理解為基礎查詢功能，而非其他業務功能實現中的類似Reference的引用查詢功能。

3. 數據架構分析-逐步弱化并和業務分析融合

對于數據架構分析，我們可以看到進一步和業務流程和業務架構分析方法融合。即數據架構的作用首先是找到所有的業務對象和數據對象。而對于數據域的劃分本身意義不大，因為我們在前面業務模塊分析中已經看到通過業務交互分析本身就已經在做數據庫拆分和拆庫的事情。

數據架構一個重點變成識別出所有的數據對象和業務對象，然后補充進矩陣交互分析中。因為我們常規的業務流程分析可能會持續識別遺漏的情況。

要注意到對于業務架構我們只分析到業務對象模型，沒有進入到邏輯模型和物理模型階段，因此在后續數據庫拆分清楚后具體的數據模型設計，仍然是傳統的數據架構分析方法進行。

在數據對象分析里面有一個重點就是主數據識別和分析。

這個仍然保留，因為前面業務分析方法有可能出現主數據或基礎數據識別不全的情況。其次將所有的數據對象仍然納入到業務數據交互矩陣分析中。對于基本上大部分跨域業務功能都需要使用到的數據納入到主數據或共享數據的范疇，并將這部分數據拿出來單獨拆庫進行處理。企業內部信息化建設模式，主數據就一個大數據庫，而新的架構模式下我們可以看到主數據也可以拆分為多個基礎數據庫。

注：今天講的分析方法里面我們可以核心是業務流程驅動，通過業務流程分析業務功能和業務數據，因此在整個分析和規劃過程是弱化了數據架構的。

4. 應用架構規劃

應用架構規劃會出現大變化，基于前面分析完成后構建的應用架構重點需要體現兩點，第一是橫向分層，第二是縱向的微服務劃分。

我們可以參考下當前企業中臺架構圖可以看到，實際上前面分析的業務模塊基本都屬于中臺的概念，雖然這些業務模塊本身也帶了前臺功能界面操作。而實際上互聯網中臺架構里面談到的前臺更多是面向C端用戶的，對于企業中臺可以理解為三個方面的可能，這個我前面也解釋過。

a. 面向對外的C端用戶的，比如企業自建電商平臺或APP應用
b. 面向企業內部所有員工自服務的，例如自服務報賬應用
c. 面向產業互聯和上下游協同的，類似和供應商，合作伙伴的一個協同平臺等

因此當前的應用架構規劃需要體現出橫向分層。前臺和中臺之間通過能力開放平臺進行協同，實現前臺和中臺能力的進一步松耦合。

對于應用架構中的中臺各個業務模塊，需要進一步拆分，包括體現出中臺微服務的三種不同呈現方式，這個我原來講到過。需要區別出一個中臺模塊是否有前端，是否對應有自己Owner的數據庫等。

a. 只有業務邏輯層并暴露服務接口
b. 業務邏輯層+Owner數據庫+服務接口暴露
c. 業務邏輯層+Owner數據庫+前端
d. 業務邏輯層+Owner數據庫+前端+服務接口暴露

在前面談到過，對應d這種模式是否拆分為b和c兩種模式需要進一步考慮。

同時我們談到，在新的中臺架構規劃中，我們完全可以將業務架構規劃和應用架構規劃進一步融合為一個規劃，要明白在融合統一后，業務架構規劃中的業務組件規劃即是中臺架構中的微服務模塊。唯一的差異點，即在于應用架構規劃中有前端應用層的概念。

阿里巴巴架構師：十問業務中臺和我的答案

一切業務數據化，一切數據業務化。

“中臺”概念這幾年非常火，特別是阿里、騰訊、百度、京東等互聯網公司最近頻繁的基于中臺調整組織架構，把“中臺”的熱度又上升到另一個高度，甚至有這樣的聲音， 90 年代不做 ERP 會死，現在不做中臺也會定企業生死。中臺的概念起源于阿里，也發展于阿里。筆者有幸參與阿里業務中臺方法體系建設，也主導參與一些阿里云新零售業務中臺項目，經常被問到如下問題。本文作為“阿里巴巴業務中臺”專題的第一篇，和大家分享一些思考（本文內容僅代表作者個人觀點，歡迎交流）。

什么是業務中臺？

中臺起源于阿里，2015年，阿里提出了 “大中臺，小前臺”戰略，靈感來源于芬蘭的一家游戲公司Supercell，僅300名員工，卻在短時間推出多個爆款游戲，成為全球最會賺錢的游戲公司。其實，阿里早在 2009 年建設“共享事業部”開始，就已經開始了中臺的探索，并通過十年上百個客戶的實踐，阿里也將自己的技術和業務能力沉淀成為一整套解決方案和方法論體系。

中臺是什么？不同的人有不同解讀。我認為，中臺是一套結合互聯網技術和行業特性，將企業核心能力以共享服務形式沉淀，形成“大中臺、小前臺“的組織和業務機制，供企業快速低成本的進行業務創新的企業架構。中臺又可以進一步細分，比如業務中臺，數據中臺，xx中臺。本質上，都是對企業通用能力在不同層面的沉淀，并對外能力開放。

業務中臺將企業的核心能力以數字化形式沉淀為各種服務中心。業務中臺的目的是“提供企業能夠快速，低成本創新的能力”。業務中臺的核心是“構建企業共享服務中心”。業務中臺的過程是通過業務板塊之間的鏈接和協同，持續提升業務創新效率，確保關鍵業務鏈路的穩定高效和經濟性兼顧的思想體系，并突出組織和業務機制。業務中臺也包含技術和組織兩大部分，通過“方法+工具+業務理解”加以實現。

數據中臺通過數據技術，對海量數據進行采集、計算、存儲、加工，同時統一標準和口徑。數據中臺把數據統一之后，會形成標準數據，再進行存儲，形成大數據資產層，進而為客戶提供高效服務。數據中臺建設的基礎還是數據倉庫和數據中心。

那業務中臺和技術中臺的關系是什么呢？阿里有句話非常形象，“一切業務數據化，一切數據業務化”。業務中臺源源不斷地從業務造數據，把業務實時在線的交易數據進行統一記錄和沉淀，這就是“業務數據化”；而數據中臺對沉淀的數據進行二次加工，通過數據標準及算法，產生進一步的分析型數據服務，這些數據服務反向又服務于業務，將業務固化，形成業務閉環，也就是“數據業務化”。比如天貓淘寶的用戶實時在線的交易信息，存放在業務共享中心的交易中心當中；而數據中臺基于這些用戶歷史信息，并通過數據分析后的用戶畫像和標簽屬性，提供服務給到前端，形成千人千面。這就是我們一直講的數據驅動、數據閉環、數據價值。

阿里業務中臺核心架構是什么？

阿里巴巴超過數十個業務單元（如淘寶、天貓、聚劃算、阿里巴巴）均不是獨立構建在阿里云之上，在后端阿里云技術平臺和前端業務之間有“共享業務事業部“（也就是這里講的“業務中臺”），將業務當中公共、通用的業務沉淀下來，包括用戶中心、商品中心、交易中心、評價中心等十幾個共享單元，是“厚平臺的真正實現“。而后端的阿里云提供計算資源和中間件PaaS云服務能力做載體。同時，使用集團近十年的雙11、雙12的高可靠、可穩定的運維保障能力，對整個系統進行支撐。中臺的使命是從下到上逐步完善阿里的整個體系，從阿里云、數據、中間件、算法，到上面支撐的各種業務解決方案，構建阿里自己核心的能力。

談到中臺，不得不提阿里共享服務事業部的由來，在淘寶初期，主要面向C2C的電商領域，整個系統都是圍繞一套“煙囪式”的淘寶技術框架進行。隨著業務的不斷擴張，集團成立出天貓事業部主抓B2C電商領域，又形成了一套煙囪式發展。這種煙囪式的架構體系帶來了諸多不足，比如成本的重復投入和維護、數據之間打通復用的難度、幾年之后推倒重建的風險。為了解決這些問題，集團已經開始構建共享服務體系，來沉淀和復用業務能力，但是由于沒有過多的業務話語權，共享服務體系的建設一開始并不順利。之后，隨著“聚劃算”團購項目的啟動，各種系統的流量都需要通過聚劃算，這時，共享服務中心得以大展手腳，逐步將集團核心的業務能力構建成用戶中心、商品中心、交易中心、評價中心、店鋪中心等等數十個共享服務。可以說整個阿里中臺的革命也是共享服務中心的革命，各共享服務中心聚焦核心業務單元能力的構建，協助目前集團上百個前臺業務的快速創新。

我的企業需要業務中臺嗎？

阿里業務中臺如此強大，那對于傳統企業，在做數字化轉型的過程中，是否需要業務中臺呢？我認為，如果你的企業有以下問題的任何一個，有必要考慮建設業務中臺：

業務具有不確定性：創新困難，無法支撐市場高速變化。如渠道扁平化管理，統一會員營銷，全渠道等。
業務不在線：企業信息化程度不足，大量人工統計，核心業務沒有做到實時、在線、統一。比如會員訂單不完整，經銷商進銷存數據不在線等。
煙囪式系統多：系統割裂，數據孤島，端到端無法實時協同，更無法基于現有系統進一步構建數據中臺。
系統重復建設：內部大量重復建設，缺乏業務核心的固化沉淀，系統服役到期只能推倒重建。
業務與互聯網緊密：業務與互聯網緊密相關，特別是面向市場消費者，系統的彈性不足，需要支撐不確定的用戶數量。

有些同學認為業務中臺是大公司要考慮的，而對于業務不復雜、人員也不太多的中小公司不適合。我有不同的觀點，其實，無論業務復雜與否、人員龐大與否，只要你的業務與互聯網相關，需要快速應對消費者帶來的不確定需求，需要打通煙囪林立的系統，需要業務在線來提高企業創新和協同，都應該考慮建設業務中臺；同時，業務中臺也不一定徹底推到整個系統，首先要改變意識，分步實施、小步快跑，有很多可落地的途徑和方法。

那業務中臺對企業有什么價值呢？這里我們先簡單羅列一下。

1、激發創新：讓企業通過核心能力的沉淀，給予快速創新機會，拉通業務整體的點線，降低了試錯成本；
2、高效協同：中臺側重的是跨部門跨團隊的深入合作，激活了組織創新；
3、業務在線：服務中心化的構建打破了煙囪式的IT架構，提高核心數據實時/在線/統一；
4、人員提升：業務沉淀中臺提升了IT人員能力，提高業務運營以及全局意識，成為既懂業務又懂技術的核心戰略人才；
5、變現營銷：會員資產化，全渠道下沉，補全客戶畫像，提升精準營銷；
6、智能商業：業務數據化+數據業務化的閉環模式，構建了商業智能的基礎；
可以看出，業務中臺無論對企業戰略發展、商業模式創新，還是內部高效協同、人員培養提升等都會帶來很多好處。

如何規劃和建設業務中臺？

很多人認為業務中臺落地難，其實難在具體的規劃和落地實施上，我們對業務中臺的建設路徑有這樣的一些看法：

1、決心變革：企業內達成戰略共識，一把手牽頭，業務/技術等團隊全局共識。做總體戰略規劃、分步實施，找準切入點，解決具體業務問題。比如會員營銷、經銷商門店、全渠道、采購供應鏈，不同的切入點策略不同。
2、成功試點：通過業務和系統分析調研，明確業務目標和范圍，完成技術平臺引入、中臺建設方法論宣導，并選擇驗證過的技術平臺和實施團隊。進行試點，梳理標桿，積累經驗。比如從新的業務系統嘗試，或者改造現有系統，步步為營。
3、持續融合：總結出適合企業自身的理念和規范，優化組織、提升中臺效率。并全面迭代和構建企業業務能力生態。

現有系統如何改造？

前文講到業務中臺在分步實施中，講究總體規劃、分步實施。面對現有系統，并不一定都要進行中臺改造，我們建議“外松內緊”：

外松：面向市場和客戶方面，以精細化運營為驅動，這些系統更適合建設業務中臺。對外市場，快速應變，敏捷創新。比如電商、客戶管理、全渠道、營銷、創新業務。

內緊：面向內部和員工，以標準化流程為驅動，這些系統更適合保持不變，與業務中臺進行對接。對內管理，流程嚴謹，標準規范。比如PLM、MES、HR、OA、財務。

共享中心如何建設？

在企業的中臺能力中心建設中，核心是共享服務中心的建設，不同行業的業務中心有所不同，比如新零售領域，一些參考可以有用戶中心、會員中心、營銷中心、商品中心、庫存中心、交易中心、結算中心、渠道中心。中心設計需要關注如下幾點：
1、共享中心是核心業務通用能力沉淀，需要考慮能力地圖，產品整體規劃，以及協議標準、業務需求構建標準等；
2、共享中心目的是復用和協同，需要通過領域模型，對業務場景流程進行有效建模；
3、共享中心要考慮能力開放，通過API接口、配置管理、或者low-code的高可配置運行機制；
4、共享中心實現前端應用和后臺的解耦，需要一定組織機制和考核傾斜，制定溝通機制和沖突升級機制。

業務中臺與前臺/后臺/平臺的關系？

業務中臺與前臺和后臺，我認為，主要是這樣的配合關系：

前臺：敏捷創新，面向不同用戶的觸點，“點”狀繁花似錦。比如2C的電商應用、2B的門店管理等，使用中臺開放能力快速變化滿足市場的不同業務場景。

中臺：核心能力共享沉淀， “面”狀協同復用。比如交易中心，正常的交易下單、雙十一的預復購、團購秒殺的拼團場景，都可以通過公用的交易中心統一配置。

后臺：強大的支撐能力，比如支撐系統穩定高效運行的各種后端系統，以及前文提到的面相內部標準化管理的系統，由中臺統一協同和對接。

比較晚前中后臺，我們來比較一下中臺、平臺和中心化。

中心化類似煙囪式架構，一個中心解決整個技術堆棧，而平臺和中臺都是為了去中心化而生，具體的區別如下：

1、中臺是面向業務的能力組合和復用，提供集成化的解決方案：中臺的目的是提高研發效率、降低創新的成本。中臺包括人，組織，平臺，數據，標準，規范，是人和系統的一整套體系。
2、中臺是平臺的自然演進：平臺是單一團隊、部門、系統的效率提升，而中臺是多領域、多BU、多系統的負責協同。如果說平臺的目標為高內聚、低耦合、職責邊界清晰；中臺是平臺化的自然演進，這種演進帶來“去中心化“的組織模式，突出復用、協調、業務創新差異化構建。
3、中臺不是系統，中臺是一種體系/生態/方法論：中臺有標準和機制，解決頂層領域下各業務子域的高效協同和資源復用問題。各部門、業務域共同建設，是中臺能力的使用方也是提供方。同時，中臺提供整個業務快速響應的一種理念和方法，對上層業務支撐。

業務中臺建設的關鍵要素

我們認為，企業在業務中臺建設當中要關注4個升級：

1、戰略升級。通過中臺建設，落地企業數字化戰略。中臺一定是“一把手工程”，整體規劃分步實施。
2、組織升級。組織架構需要與中臺架構相匹配，根據企業實際情況優化組織效率，提升效能，數據化運營，更好支持業務發展和創新
3、流程升級。將企業現有流程進行梳理，優化及固化企業流程，提高企業共享復用能力，提升企業運作效率。
4、技術升級。通過互聯網技術，對企業基礎技術設施進行升級，降本增效，達到企業IT部門整體技術升級。

業務中臺需要哪些核心技術來支撐？

業務中臺落地中需要一些核心技術，我們也叫“技術中臺”，有一些通用的建議：

1、盡可能拆分，共享中心建設：企業應該盡可能地拆分自己的應用，進行共享服務中心的建設，將核心的業務能力復用和沉淀。共享中心的拆分也可以有層次，可從從基礎主數據、核心業務、流程規則等角度來進行拆分。
2、去中心化，線性擴展：企業需要采用去中心化架構，沒有核心流量匯入點，服務中心盡量無狀態，便于水平擴展。這樣平均分擔壓力，負載均衡，對單個中心帶來的負載更小，故障影響的范圍也更小。
3、數據化運營：去中心化也會面對系統運維和管理成本上升的問題。企業需要對自身的運維運營過程進行積累和沉淀，整理出數據化、自動化運維的經驗，同時增強監控告警、限流降級、性能分析診斷等方面的能力，精準定位目前系統中存在的問題，并提出相應的改善方案。
4、異步化，最終一致：在大量的實踐中，大部分業務流程不需要強一致性，而使用最終一致來平衡。我們需要使用異步解耦，如使用消息隊列來完成業務邏輯，縮短相應周期。
5、盡可能自動化：企業進行中臺改造，要求企業盡可能提高自動化能力，比如自動部署、自動彈性擴容、自動升降級、自動限流降級，降低運營成本，也提高系統的穩定性和業務連續性。
6、盡可能使用成熟組件：中臺的建設要求企業將重心放在服務中心上，對于底層組件，尤其是中間件層面，盡量使用成熟的云原生組件來提高系統穩定性和性能。目前，阿里巴巴中間件已經將多年經雙十一購物狂歡節的嚴苛考驗的技術沉淀，以阿里云標準云服務的方式輸出給外部客戶，其中包括多款阿里云云原生中間件產品（比如K8S/EDAS/MQ/DRDS/ARMS/PTS/CSB/GTS/MSE/ACM），阿里與流行的云原生技術完整融合（比如Dubbo/SpringCloud/K8S/RocketMQ/Nacos）。

阿里在業務中臺建設上能提供什么？

阿里是最早提出中臺概念，并成功實施落地，阿里中臺所配套的中間件是經過阿里多年雙十一洗禮的成熟產品。阿里內部幾百個業務應用，共享一個技術中臺底座，服務新的業務場景，帶來更好的用戶業務體驗。同時，阿里云通過為上百個外部客戶實施業務中臺，培養了一大批具備中臺實施交付能力的行業ISV，同時沉淀了大量行業最佳實踐。

阿里云提供一整套“業務中臺技術解決方案”可以解決的問題有：

將企業核心能力下沉共享，加速企業創新速度；
規范IT全生命周期管理，提升研發效率與質量；
提供行業最佳實踐，助力企業快速落地中臺戰略。

架構優勢

云原生：支持彈性調度、微服務化解耦，自動化運維；
高可靠：阿里中間件產品支持，歷經多年雙11考驗；
高并發：支持按流量線性擴展，支撐海量用戶。

更為重要的，阿里基于近十年的最佳實踐，沉淀了一整套業務中臺實施的方法論，包括中臺架構設計、微服務架構設計、中臺開發規范、全鏈路壓測等方面的最佳實踐。這些全方位的中臺建設方法論、阿里商業能力、阿里云技術支撐，不僅僅是技術紅利的分享，更重要的是整個阿里中臺戰略思想的傳播。

更多可以參考“阿里云業務中臺技術解決方案官網”。

小結

本文希望通過筆者在阿里業務中臺方法體系建設及項目中的一些經驗，為企業在業務中臺建設過程提供一些幫助。同時本文是“阿里巴巴業務中臺”專題的第一篇，后續我們還會有中臺方法、中心設計、典型場景、最佳實踐等更多精彩內容，敬請期待，歡迎與我交流。

參考資料：

阿里云業務中臺技術解決方案官網
https://www.aliyun.com/solution/bme/index
阿里架構總監一次講透中臺架構，13頁PPT精華詳解
https://yq.aliyun.com/articles/717505
互聯網時代的企業必定都要實現中臺
https://yq.aliyun.com/articles/717505

作者信息：王思軒，花名宇升，阿里云業務中臺&云原生架構師，博士留學期間發表論文10余篇，多年大型分布式系統架構設計經驗，現主要參與阿里云業務中臺方法體系建設，以及新零售業務中臺和云原生技術咨詢工作。

本文作者：王思軒

原文鏈接

總結

以上是生活随笔為你收集整理的架构设计-业务中台的方法论的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。