SOA架構(gòu)思想

我們可以來看下SOA本身的定義，即：

SOA是一種架構(gòu)方法，將傳統(tǒng)的單片式應(yīng)用打破，分解為離散的、自治的業(yè)務(wù)服務(wù)，利用標(biāo)準(zhǔn)提升他們的互操作性，從而可以更好地共享、重用和組裝，快速構(gòu)建復(fù)合的應(yīng)用從而滿足業(yè)務(wù)需求的變化。

在面對企業(yè)遺留IT系統(tǒng)架構(gòu)的時候，SOA本身實際也是做兩個重要的事情，其一是找到各個遺留系統(tǒng)共性的可復(fù)用的業(yè)務(wù)能力；其次就是在構(gòu)建上層業(yè)務(wù)流程的時候通過服務(wù)組裝和編排來完成。這個思想和中臺思想完全一致。

我們來舉個例子詳細(xì)說明SOA架構(gòu)思想：

我們以注冊一家新公司來舉例，可以看到如果我們要注冊一家新的公司，我們需要和銀行，政府部門中的工商，稅務(wù)，質(zhì)量監(jiān)督等多個業(yè)務(wù)部門到交道，最終完成新公司注冊的完整過程。

其一：找到可復(fù)用服務(wù)

而對于各個業(yè)務(wù)部門就是我們說的業(yè)務(wù)組件，我們首先就是要看業(yè)務(wù)組件本身對外提供了什么標(biāo)準(zhǔn)的服務(wù)能力出來，即先把各個組件可共享，能夠復(fù)用的能力識別出來。這些業(yè)務(wù)組件本身提供很多業(yè)務(wù)服務(wù)能力，在這里我們只列舉一些和公司注冊相關(guān)的能力，如下：

其二：組合和編排服務(wù)完成業(yè)務(wù)

在進(jìn)行一個新企業(yè)的注冊流程中，涉及到核名，辦理驗資報告，領(lǐng)取組織機(jī)構(gòu)代碼證等諸多的業(yè)務(wù)活動，這些業(yè)務(wù)活動都需要和上面說的業(yè)務(wù)部門(業(yè)務(wù)組件)打交道才能夠完成。

而要完成整個業(yè)務(wù)流程，就是將上面業(yè)務(wù)部門暴露的服務(wù)能力基于業(yè)務(wù)活動的流轉(zhuǎn)進(jìn)行組裝起來，這樣就完成了一個完整的業(yè)務(wù)，如下：

可以看到完成整個企業(yè)注冊業(yè)務(wù)流程，本身就是底層的接口服務(wù)能力的組合和組裝。

如果注冊流程中增加了一個驗證企業(yè)信用要求，那么我們也很容易在原來的業(yè)務(wù)流程中增加一個活動節(jié)點，該活動節(jié)點調(diào)用銀行的信用驗證服務(wù)能力接口即可。即通過接口服務(wù)的靈活組合，組裝，能夠很容易的響應(yīng)業(yè)務(wù)流程的變化。

SOA和ESB總線的關(guān)系

簡單來說，SOA是一種架構(gòu)思想，這種架構(gòu)思想核心是找到服務(wù)，組裝編排服務(wù)。對于找到的服務(wù)我們希望統(tǒng)一進(jìn)行管理，那么ESB就是實現(xiàn)服務(wù)管理和治理的一個技術(shù)平臺。

也就是ESB企業(yè)服務(wù)總線是實現(xiàn)SOA架構(gòu)思想的一個關(guān)鍵平臺。

如上圖，找到和管理服務(wù)你可以借助ESB服務(wù)總線能力來完成，而組裝和編排服務(wù)你可以借助BPM管理軟件來完成。而ESB BPM也是我們常說的實現(xiàn)SOA架構(gòu)思想的關(guān)鍵平臺。

沒有使用ESB能否叫實現(xiàn)SOA架構(gòu)？

當(dāng)然可以，只是遺留系統(tǒng)暴露的接口服務(wù)沒有進(jìn)行統(tǒng)一的管控和治理，也就是說對于接口服務(wù)的治理水平會比較弱，但是只要你暴露的接口服務(wù)是粗粒度和可復(fù)用的。同樣可以共享給上層業(yè)務(wù)系統(tǒng)或應(yīng)用使用。正如沒有使用BPM，同樣也可以實踐SOA編排思想，只是你需要通過自己寫代碼去編排服務(wù)，而不是通過BPM軟件去可視化編排服務(wù)。

反之同樣的道理，不用簡單理解使用了ESB就是SOA架構(gòu)。

比如你使用了ESB，接入了一堆沒有經(jīng)過標(biāo)準(zhǔn)化，不符合粗粒度特點的接口，這些接口本身混亂也沒有任何服務(wù)價值。上層新業(yè)務(wù)開發(fā)也不能使用這些接口服務(wù)，那么這個時候你的ESB就僅僅是一個接口平臺，也沒有實現(xiàn)任何的SOA架構(gòu)思想。

類似的道理還有我們做微服務(wù)也一樣，不要簡單的認(rèn)為使用了SpringCloud框架就是微服務(wù)了，必須要考慮微服務(wù)類似輕量交互，松耦合等關(guān)鍵思想是否實現(xiàn)。

ESB總線需要同時考慮解決集成和解耦兩類問題

由于當(dāng)前ESB總線產(chǎn)品很多是由原有的EAI和消息中間件產(chǎn)品發(fā)展而來，因此更多的強(qiáng)調(diào)的是服務(wù)或消息集成，而弱化了SOA更加重要的一個能力即服務(wù)共享。

而實際上SOA需要解決服務(wù) 集成兩方面的問題。

• 集成：解決的是業(yè)務(wù)和流程上的協(xié)同問題，服務(wù)不一定就能復(fù)用

• 復(fù)用：解決的是底層共有組件模塊提取后能力開放問題，重點是可復(fù)用

從上面圖可以看到，對于橫向交互協(xié)同的接口，更多的是解決跨系統(tǒng)的集成問題，而對于系統(tǒng)中縱向使用的共享能力接口，在共享能力平臺化后，則接口服務(wù)可重用，更多的解決就是服務(wù)層面的問題。

舉例來說，一個采購系統(tǒng)導(dǎo)采購訂單給ERP系統(tǒng)，這個接口往往并不能復(fù)用，但是解決了跨系統(tǒng)集成問題；另外對于MDM主數(shù)據(jù)提供的供應(yīng)商查詢接口服務(wù)，這個接口服務(wù)本身就是數(shù)據(jù)能力平臺化后提供出的共享數(shù)據(jù)服務(wù)能力，這個服務(wù)可以被外圍的SCM，ERP，CMS多個業(yè)務(wù)系統(tǒng)使用，既解決了系統(tǒng)間集成，更重要的解決了服務(wù)重用問題。

你也可以理解，對于服務(wù)重用問題的解決，更多都是伴隨著共性能力下沉產(chǎn)生的。然而當(dāng)前大部分企業(yè)將SOA簡單理解為了ESB和集成平臺，更多用SOA去解決集成的問題，而忘記了SOA架構(gòu)思想的本質(zhì)仍然是共性業(yè)務(wù)能力下降，上層應(yīng)用靈活編排。

企業(yè)中臺和中臺思想

對于中臺概念，大家都比較清楚是阿里最早提出了大中臺，小前臺的說法。阿里巴巴 “大中臺、小前臺”機(jī)制的提出，某種程度上是從傳統(tǒng)的事業(yè)部制向準(zhǔn)事業(yè)部制的轉(zhuǎn)換。

對于中臺核心價值可以總結(jié)為關(guān)鍵的兩點，第一點就是靈活敏捷支撐業(yè)務(wù)。

就阿里巴巴而言，“前臺”就是貼近最終用戶/商家的業(yè)務(wù)部門，包括零售電商、廣告業(yè)務(wù)、云計算、物流以及其它創(chuàng)新業(yè)務(wù)等；而“中臺”則是強(qiáng)調(diào)資源整合、能力沉淀的平臺體系，為“前臺”的業(yè)務(wù)開展提供底層的技術(shù)、數(shù)據(jù)等資源和能力的支持，中臺將集合整個集團(tuán)的運(yùn)營數(shù)據(jù)能力、產(chǎn)品技術(shù)能力，對各前臺業(yè)務(wù)形成強(qiáng)力支撐。

前臺和中臺本質(zhì)上是工作分工的問題。比如，某部門要開發(fā)一款A(yù)pp，是部門內(nèi)部(大前臺)自己組織一套技術(shù)、產(chǎn)品、設(shè)計、運(yùn)營的團(tuán)隊，還是集團(tuán)為其提供資源(大中臺)，由專門的技術(shù)團(tuán)隊來幫助其開發(fā)、設(shè)計產(chǎn)品等等。

所以說， “小前臺 大中臺”的運(yùn)營模式，就是美軍的“特種部隊(小前臺) 航母艦群(大中臺)”的組織結(jié)構(gòu)方式，以促進(jìn)管理更加扁平化。十幾人甚至幾人組成的特種部隊在戰(zhàn)場一線，可以根據(jù)實際情況迅速決策，并引導(dǎo)精準(zhǔn)打擊。而精準(zhǔn)打擊的導(dǎo)彈往往是從航母艦群上發(fā)射而出，后方會提供強(qiáng)大的偵察火力后勤支援。所以如果中臺沒有辦法承接前線的需求，前線就會不認(rèn)可它服務(wù)的價值。

第二點就是通過中臺來實現(xiàn)進(jìn)一步的資源整合復(fù)用，降低成本

阿里巴巴近年來迅速擴(kuò)張、員工眾多，所以可能會存在管理不善、效率低下、各事業(yè)部各自為政等問題。為了解決以上問題，阿里提出了“大中臺，小前臺”機(jī)制?！靶∏芭_ 大中臺”的運(yùn)營模式促使組織管理更加扁平化，使得管理更加高效，組織運(yùn)作效率提高，業(yè)務(wù)更加敏捷靈活。

其“中臺”的設(shè)置就是為了提煉各個業(yè)務(wù)條線的共性需求，并將這些打造成組件化的資源包，然后以接口的形式提供給前臺各業(yè)務(wù)部門使用，可以使產(chǎn)品在更新迭代、創(chuàng)新拓展的過程中研發(fā)更靈活、業(yè)務(wù)更敏捷，最大限度地減少“重復(fù)造輪子”的KPI項目。前臺要做什么業(yè)務(wù)，需要什么資源可以直接同公共服務(wù)部要。

大家看到這兩點，是否覺得跟傳統(tǒng)企業(yè)內(nèi)部信息化建設(shè)經(jīng)常說到的SOA架構(gòu)思想很類似。

微服務(wù)本質(zhì)是單體大拆小

接著再來看下微服務(wù)，談微服務(wù)一定是和單體應(yīng)用對比。

微服務(wù)架構(gòu)強(qiáng)調(diào)的第一個重點就是業(yè)務(wù)系統(tǒng)需要徹底的組件化和服務(wù)化，原有的單個業(yè)務(wù)系統(tǒng)會拆分為多個可以獨立開發(fā)，設(shè)計，運(yùn)行和運(yùn)維的小應(yīng)用。這些小應(yīng)用之間通過服務(wù)完成交互和集成。每個小應(yīng)用從前端web ui，到控制層，邏輯層，數(shù)據(jù)庫訪問，數(shù)據(jù)庫都完全是獨立的一套。

在這里我們不用組件而用小應(yīng)用這個詞更加合適，每個小應(yīng)用除了完成自身本身的業(yè)務(wù)功能外，重點就是還需要消費(fèi)外部其它應(yīng)用暴露的服務(wù)，同時自身也將自身的能力朝外部發(fā)布為服務(wù)。

如果一句話來談SOA和微服務(wù)的區(qū)別，即微服務(wù)不再強(qiáng)調(diào)傳統(tǒng)SOA架構(gòu)里面比較重的ESB企業(yè)服務(wù)總線，同時SOA的思想進(jìn)入到單個業(yè)務(wù)系統(tǒng)內(nèi)部實現(xiàn)真正的組件化。

我們可以先看下從單體應(yīng)用到微服務(wù)架構(gòu)的變化圖。

從上面圖里面我們可以清楚的看到單體轉(zhuǎn)到微服務(wù)后帶來的兩個核心差異。

• 一個單體變多個微服務(wù)模塊，而且從數(shù)據(jù)庫到邏輯層到前端完全獨立

• 微服務(wù)模塊間通過Http Rest接口高效集成協(xié)同

談到這里，我需要糾正下我原來的一個看法。

即SOA和微服務(wù)本質(zhì)上不應(yīng)該放在一個層面去比較，因為SOA里面強(qiáng)調(diào)的橫向分層，可復(fù)用服務(wù)積累，上層服務(wù)靈活組裝形成應(yīng)用幾個關(guān)鍵點在微服務(wù)里面都沒有。微服務(wù)僅僅是模塊間接口交互走了輕量的Http Rest接口而已。

微服務(wù)簡單來說強(qiáng)調(diào)的是縱向大單體拆分小，因此更多應(yīng)該和單體應(yīng)用做對比。

題外話：經(jīng)常看到有人將業(yè)務(wù)邏輯層理解為中臺，這個也是錯誤對比，這兩個不是一個層面的概念。中臺模塊有業(yè)務(wù)邏輯層，前臺模塊也有。要明白不是所有業(yè)務(wù)邏輯都是共性和可復(fù)用的，對于不可復(fù)用的業(yè)務(wù)邏輯仍然是在前臺模塊中，而非中臺。

中臺=SOA思想 微服務(wù)

在了解了前面講解了概念后，我們看到中臺思想實際上SOA思想和微服務(wù)兩者的融合。為何這樣講，我們來講中臺思想和中臺實現(xiàn)兩個層面來說。

• 共性可復(fù)用業(yè)務(wù)能力下沉，并提供給前臺應(yīng)用使用=》SOA思想

• 共性能力構(gòu)建時候盡量大拆小，可擴(kuò)展，松耦合=》微服務(wù)思想

當(dāng)前互聯(lián)網(wǎng)企業(yè)談的中臺基本就是SOA架構(gòu)思想和微服務(wù)兩者的一個融合，既體現(xiàn)了共性業(yè)務(wù)能力下沉，又體現(xiàn)了共性能力要大拆小的微服務(wù)方式構(gòu)建。如下圖：

當(dāng)我們理解了這個核心概念后，我們才能夠認(rèn)識到如下幾點關(guān)鍵認(rèn)識。

中臺是一個業(yè)務(wù)層面概念，微服務(wù)是一個技術(shù)層面概念。中臺核心仍然是共性業(yè)務(wù)能力下沉和復(fù)用，只是互聯(lián)網(wǎng)企業(yè)在實現(xiàn)中臺架構(gòu)的時候，將中臺技術(shù)實現(xiàn)和微服務(wù)做了融合。

因此企業(yè)內(nèi)業(yè)務(wù)中臺實現(xiàn)，只要滿足共性業(yè)務(wù)能力統(tǒng)一提供給上層使用，即使底層提供能力的仍然是傳統(tǒng)遺留業(yè)務(wù)系統(tǒng)，那么也可以將構(gòu)建了一個業(yè)務(wù)服務(wù)能力中臺。

同時也可以看到微服務(wù)僅僅是中臺中應(yīng)用到的一個技術(shù)實現(xiàn)，你可以在很多非中臺場景下采用微服務(wù)，小到原來一個業(yè)務(wù)系統(tǒng)拆分后全新構(gòu)建這種場景。因此采用了微服務(wù)架構(gòu)離中臺實現(xiàn)十萬八千里。同時不采用微服務(wù)也可以實現(xiàn)中臺。

從傳統(tǒng)架構(gòu)ESB到中臺架構(gòu)里面的API網(wǎng)關(guān)

對于中臺里面下沉的共性業(yè)務(wù)服務(wù)能力也需要統(tǒng)一向外暴露，這個時候就涉及到OpenAPI能力開放平臺或API網(wǎng)關(guān)，那么首先來解釋下API網(wǎng)關(guān)。

如何給API網(wǎng)關(guān)一個定義？

簡單來說API網(wǎng)關(guān)就是將所有的微服務(wù)提供的API接口服務(wù)能力全部匯聚進(jìn)來，統(tǒng)一接入進(jìn)行管理，也正是通過統(tǒng)一攔截，就可以通過網(wǎng)關(guān)實現(xiàn)對API接口的安全，日志，限流熔斷等共性需求。如果再簡單說下，通過網(wǎng)關(guān)實現(xiàn)了幾個關(guān)鍵能力。

• 內(nèi)部的微服務(wù)對外部訪問來說位置透明，外部應(yīng)用只需和網(wǎng)關(guān)交互

• 統(tǒng)一攔截接口服務(wù)，實現(xiàn)安全，日志，限流熔斷等需求

從這里，我們就可以看到API網(wǎng)關(guān)和傳統(tǒng)架構(gòu)里面的ESB總線是類似的，這些關(guān)鍵能力本身也是ESB服務(wù)總線的能力，但是ESB服務(wù)總線由于要考慮遺留系統(tǒng)的接入，因此增加了：

• 大量適配器實現(xiàn)對遺留系統(tǒng)的遺留接口適配，多協(xié)議轉(zhuǎn)換能力

• 進(jìn)行數(shù)據(jù)的復(fù)制映射，路由等能力

對于兩者，我原來做過一個簡單的對比，大家可以參考。

這個概念理解后，我們再回到微服務(wù)架構(gòu)里面。

對于微服務(wù)架構(gòu)大家經(jīng)常說的最多的就是去中心化的架構(gòu)，認(rèn)為ESB中心化架構(gòu)模式已經(jīng)過時。而實際上經(jīng)過上面分析你可以看到。在微服務(wù)架構(gòu)里面的API網(wǎng)關(guān)仍然是中心化的架構(gòu)模式，所有的API接口都要經(jīng)過網(wǎng)關(guān)這個點。

• 非中心化架構(gòu)-》走微服務(wù)里面的服務(wù)注冊中心進(jìn)行接口交互

• 中心化架構(gòu)-》走網(wǎng)關(guān)進(jìn)行接口服務(wù)暴露和共享交互

對于微服務(wù)架構(gòu)里面有無去中心化的架構(gòu)？當(dāng)然是有的，即我們常說的微服務(wù)模塊之間可以通過服務(wù)注冊中心來實現(xiàn)服務(wù)發(fā)現(xiàn)查找，服務(wù)間的點對點調(diào)用即使去中心化的。

如果一個單體拆分為微服務(wù)后，完全不需要和外部應(yīng)用打交道，也不需要共享自己的接口能力，那么這個微服務(wù)體系里面就不需要用API網(wǎng)關(guān)，僅僅使用服務(wù)注冊中心即可。通過服務(wù)注冊中心實現(xiàn)完全的去中心化和接口調(diào)用更高的性能。

再回到我講ESB的時候談到解決兩個層面的問題，一個是集成，一個是共享。那么轉(zhuǎn)移到微服務(wù)架構(gòu)體系后，即集成的問題通過非中心化架構(gòu)完全可以解決，而對于共享問題仍然需要輕量的ESB總線或API網(wǎng)關(guān)來解決。

業(yè)務(wù)中臺，數(shù)據(jù)中臺，技術(shù)中臺

現(xiàn)在中臺的概念太多，導(dǎo)致大家在理解中臺的時候很容易出現(xiàn)偏差。

技術(shù)中臺建議叫技術(shù)平臺

首先說明下我個人認(rèn)為中臺更加偏向于業(yè)務(wù)概念，可以說包括了業(yè)務(wù)中臺和數(shù)據(jù)中臺，但是盡量不要說技術(shù)中臺。技術(shù)中臺更多的應(yīng)該理解為技術(shù)平臺更加合適。

技術(shù)平臺理解也很簡單，當(dāng)你在開發(fā)中臺各個微服務(wù)的時候，你涉及到各種共性技術(shù)能力的需求，這里面既包括了類似消息，緩存等技術(shù)服務(wù)能力，也包括了微服務(wù)開發(fā)框架和運(yùn)行環(huán)境，還包括了類似DevOps的持續(xù)集成和交付能力。

這些能力是你進(jìn)行中臺微服務(wù)開發(fā)的基礎(chǔ)，讓你開發(fā)更加高效。

在我最早開始做企業(yè)私有云PaaS平臺規(guī)劃建設(shè)的時候，就提出了業(yè)務(wù)能力組件化，組件能力服務(wù)化的平臺 應(yīng)用的構(gòu)建模式。而這也是現(xiàn)在我們談到的中臺 微服務(wù)思想是完全一致的。當(dāng)時我們在我們整體規(guī)劃里面的PaaS平臺就可以看作是技術(shù)中臺的內(nèi)容，如下圖：

該書近期也將由清華大學(xué)出版社出版，也是我們多年大型集團(tuán)企業(yè)SOA和PaaS平臺建設(shè)實施經(jīng)驗的積累，歡迎大家閱讀和指正。

而對于當(dāng)前的技術(shù)中臺，其核心實際上就是我們最近幾年談的比較多的云原生解決方案，因為云原生解決方案剛好覆蓋了微服務(wù) DevOps 容器云幾個關(guān)鍵內(nèi)容。

云原生=微服務(wù) DevOps 容器云

對于Cloud Native翻譯為云原生，是Matt Stine提出的一個概念，它是一個思想的集合，包括DevOps、持續(xù)交付(Continuous Delivery)、微服務(wù)(MicroServices)、敏捷基礎(chǔ)設(shè)施(Agile Infrastructure)、康威定律(Conways Law)等，以及根據(jù)商業(yè)能力對公司進(jìn)行重組。

云原生應(yīng)用程序開發(fā)通常包括DevOps，敏捷方法，微服務(wù)，云平臺，Kubernetes和Docker等容器，以及持續(xù)交付，簡而言之，每種新的和現(xiàn)代的應(yīng)用程序部署方法。

微服務(wù)架構(gòu) 容器化 DevOps 將成為后續(xù)企業(yè)信息化轉(zhuǎn)型的主流趨勢。在構(gòu)建企業(yè)的技術(shù)中臺的時候完全可以參考云原生解決方案來進(jìn)行構(gòu)建。

從傳統(tǒng)架構(gòu)到中臺架構(gòu)

我們可以簡單做下對比映射，即傳統(tǒng)架構(gòu)中的業(yè)務(wù)系統(tǒng)對應(yīng)到新架構(gòu)里面的業(yè)務(wù)中臺，傳統(tǒng)架構(gòu)里面的BI系統(tǒng)對應(yīng)到新架構(gòu)里面的數(shù)據(jù)中臺。這個對應(yīng)當(dāng)然不準(zhǔn)確，里面存在差異和區(qū)別，也是我們要重點說明的地方。

業(yè)務(wù)中臺和數(shù)據(jù)中臺的區(qū)別

對于業(yè)務(wù)中臺相對來說比較好理解，簡單一句話就是共性業(yè)務(wù)能力下沉形成的多個微服務(wù)化的業(yè)務(wù)能力提供中心供上層應(yīng)用使用。而對于數(shù)據(jù)中臺，我們也可以總結(jié)為一句話就是，把數(shù)據(jù)變成資產(chǎn)并服務(wù)于業(yè)務(wù)的機(jī)制。數(shù)據(jù)來源于業(yè)務(wù)并反哺業(yè)務(wù)，不斷的迭代循環(huán)。

數(shù)據(jù)中臺，類似業(yè)務(wù)中臺定義，如果也一句話定義的話就是共性數(shù)據(jù)能力下沉和整合，并以數(shù)據(jù)服務(wù)訪問對外提供可復(fù)用的能力。數(shù)據(jù)中臺是實現(xiàn)業(yè)務(wù)中臺核心共享數(shù)據(jù)的跨域整合，再通過加工后提供整合后的數(shù)據(jù)服務(wù)能力。這里面有兩個重點。

• 第一數(shù)據(jù)要跨域整合

• 第二數(shù)據(jù)要加工處理后再提供增值服務(wù)能力

這個加工可能簡單的匯總表，也可能是復(fù)制的底層數(shù)據(jù)模型和智能分析算法。

業(yè)務(wù)中臺重點是業(yè)務(wù)數(shù)據(jù)化，而數(shù)據(jù)中臺重點是數(shù)據(jù)業(yè)務(wù)化，數(shù)據(jù)來源于業(yè)務(wù)又反哺業(yè)務(wù)。就建設(shè)和支撐層面來說我原來也總結(jié)過，即業(yè)務(wù)中臺是基礎(chǔ)業(yè)務(wù)能力支撐，必須要有，數(shù)據(jù)中臺是增值能力支撐，剛開始沒有也不會影響到業(yè)務(wù)本身的運(yùn)作。

以下我們再總結(jié)下兩者區(qū)別的一些關(guān)鍵點說明

• 業(yè)務(wù)中臺必須有是核心業(yè)務(wù)支撐，數(shù)據(jù)中臺可以無，是增值能力提供。

• 業(yè)務(wù)中臺是自己產(chǎn)生業(yè)務(wù)數(shù)據(jù)，數(shù)據(jù)中臺是采集業(yè)務(wù)數(shù)據(jù)再加工。

• 業(yè)務(wù)中臺不再做底層數(shù)據(jù)交換和集成，這部分能力全部轉(zhuǎn)到數(shù)據(jù)中臺。

我們可以簡單的理解為業(yè)務(wù)中臺對應(yīng)傳統(tǒng)架構(gòu)里面的業(yè)務(wù)系統(tǒng)，但是業(yè)務(wù)系統(tǒng)進(jìn)一步微服務(wù)化了。而數(shù)據(jù)中臺對應(yīng)傳統(tǒng)架構(gòu)里面的BI系統(tǒng)，只是數(shù)據(jù)不再封閉而需要進(jìn)一步開放了。

傳統(tǒng)BI系統(tǒng)是不是就是數(shù)據(jù)中臺？

實際上對于數(shù)據(jù)中臺，我們不僅僅要比較和業(yè)務(wù)中臺的區(qū)別，還需要比較和傳統(tǒng)BI的區(qū)別。因為從上圖我們可以看到數(shù)據(jù)中臺和傳統(tǒng)的BI系統(tǒng)架構(gòu)還是很類似。

簡單來說傳統(tǒng)BI和數(shù)據(jù)倉庫的主要場景是支持管理決策和業(yè)務(wù)分析，而數(shù)據(jù)中臺則是將數(shù)據(jù)服務(wù)化之后提供給業(yè)務(wù)系統(tǒng)，目標(biāo)是數(shù)據(jù)能力滲透到各個業(yè)務(wù)環(huán)節(jié)，不限于決策分析類應(yīng)用場景。數(shù)據(jù)中臺持續(xù)不斷的將數(shù)據(jù)進(jìn)行資產(chǎn)化，價值化并應(yīng)用到業(yè)務(wù)，而且關(guān)注數(shù)據(jù)價值的運(yùn)營。

注意上面構(gòu)圖里面的紅線部分，數(shù)據(jù)中臺必須要有數(shù)據(jù)服務(wù)開放層，同時要有紅線的接口服務(wù)直接被業(yè)務(wù)系統(tǒng)使用。這兩點相當(dāng)重要。否則就容易把數(shù)據(jù)中臺建成傳統(tǒng)BI。

即數(shù)據(jù)中臺能力要服務(wù)于業(yè)務(wù)系統(tǒng)準(zhǔn)實時協(xié)同需要。數(shù)據(jù)中臺形成的能力，不論是ODS層能力還是DW層能力，都可能通過能力開放方式暴露接口給業(yè)務(wù)應(yīng)用使用，為業(yè)務(wù)提供實時或準(zhǔn)實時的增值服務(wù)能力。

為了做到實時或準(zhǔn)實時，一方面你會看到數(shù)據(jù)中臺架構(gòu)上實際上是包括了大數(shù)據(jù)平臺的核心架構(gòu)和分布式存儲內(nèi)容，同時還包括了大數(shù)據(jù)平臺中的實時計算和流處理能力。其次，為了將能力提供給業(yè)務(wù)系統(tǒng)，往往數(shù)據(jù)中臺整體架構(gòu)上一定會體現(xiàn)一個統(tǒng)一的數(shù)據(jù)服務(wù)能力開放層，這個在傳統(tǒng)的數(shù)據(jù)倉庫或大數(shù)據(jù)平臺上是沒有的。

數(shù)據(jù)中臺和傳統(tǒng)BI架構(gòu)有重合，也有交集。相同的就是整個數(shù)據(jù)采集集成，數(shù)據(jù)存儲，數(shù)據(jù)模型構(gòu)建，數(shù)據(jù)開發(fā)和分析，這些都需要。差異點在于數(shù)據(jù)中臺需要有統(tǒng)一的數(shù)據(jù)服務(wù)能力開放層，提供給業(yè)務(wù)使用，而弱化了傳統(tǒng)BI里面的數(shù)據(jù)分析和報表展現(xiàn)層。

大數(shù)據(jù)平臺是不是就是數(shù)據(jù)中臺？

圖片來源網(wǎng)絡(luò)

首先我們來談大數(shù)據(jù)平臺是一個技術(shù)平臺。這個技術(shù)平臺提供了對于大數(shù)據(jù)的分布式采集，存儲，流處理和計算，實時分析等能力。在沒有大數(shù)據(jù)平臺前也有數(shù)據(jù)集成和管理的平臺，這種平臺可以實現(xiàn)對結(jié)構(gòu)化數(shù)據(jù)本身的采集，集成和管理。

因此我們常說的大數(shù)據(jù)平臺你可以理解為一個純粹的數(shù)據(jù)技術(shù)能力平臺，里面本身是空的。就像我們理解ESB總線一樣，本身是一個技術(shù)平臺，一開始沒有接口服務(wù)注冊在上面，需要你自己不斷的接入新的服務(wù)，才能夠形成服務(wù)目錄體系。

任何一個數(shù)據(jù)中臺，底層都需要一個提供數(shù)據(jù)存儲和處理能力支撐的技術(shù)平臺。

這個技術(shù)平臺如果你有大數(shù)據(jù)需求，構(gòu)建出來的就是大數(shù)據(jù)平臺。但是如果你沒有大數(shù)據(jù)需求，那么用傳統(tǒng)的數(shù)據(jù)集成和管理技術(shù)平臺即可。

其次，數(shù)據(jù)中臺的范疇包括了如下幾個方面

• 一套底層的數(shù)據(jù)技術(shù)平臺(可以是大數(shù)據(jù)平臺，也可以是數(shù)據(jù)集成平臺)

• 一套數(shù)據(jù)資產(chǎn)(業(yè)務(wù)層面的內(nèi)容，實際數(shù)據(jù)，數(shù)據(jù)模型，算法裝進(jìn)來了)

• 一套數(shù)據(jù)服務(wù)能力提供和共享

• 一套數(shù)據(jù)管控和治理標(biāo)準(zhǔn)規(guī)范體系

因此可以看到對于數(shù)據(jù)中臺核心重要的反而是數(shù)據(jù)資產(chǎn) 數(shù)據(jù)服務(wù)能力共享這兩點。如果整個數(shù)據(jù)中臺建設(shè)有大數(shù)據(jù)平臺，那么大數(shù)據(jù)平臺也僅僅是一個底層技術(shù)平臺和技術(shù)實現(xiàn)手段。

主數(shù)據(jù)平臺是不是數(shù)據(jù)中臺？

那么在傳統(tǒng)架構(gòu)里面的主數(shù)據(jù)平臺是否屬于數(shù)據(jù)中臺的一部分內(nèi)容呢？這個也是我們經(jīng)?？吹綍粏柶鸬膯栴}。包括在我原來的理解也是錯誤的，即把主數(shù)據(jù)平臺理解為了數(shù)據(jù)中臺的一部分。

對于數(shù)據(jù)中臺前面已經(jīng)講過了，我們再來看下主數(shù)據(jù)定義。

主數(shù)據(jù)是描述核心業(yè)務(wù)實體(如客戶、供應(yīng)商、地點、產(chǎn)品和庫存)的一個或多個屬性。所以主數(shù)據(jù)即是在進(jìn)行企業(yè)業(yè)務(wù)架構(gòu)分析中發(fā)現(xiàn)的核心業(yè)務(wù)對象?；蛘咧v主數(shù)據(jù)是企業(yè)已經(jīng)存在的涉及到價值鏈核心業(yè)務(wù)流程的各個IT系統(tǒng)的基礎(chǔ)數(shù)據(jù)。

對于ERP系統(tǒng)客戶，供應(yīng)商，物料，BOM，產(chǎn)品，合同，訂單等都應(yīng)該是最基礎(chǔ)的數(shù)據(jù)，對于項目管理系統(tǒng)而言項目信息，WBS信息則是最基本的基礎(chǔ)數(shù)據(jù)。而對于CRM系統(tǒng)則客戶，銷售項目是最基本的基礎(chǔ)數(shù)據(jù)?；A(chǔ)數(shù)據(jù)要上升到主數(shù)據(jù)的高度還有一個條件，即該數(shù)據(jù)產(chǎn)生在一個源IT系統(tǒng)中，但是會在多個其它的IT系統(tǒng)中使用到。

在了解清楚了兩者的基本定義后，再來看區(qū)別。如下圖：

對兩者的區(qū)別點進(jìn)一步說明如下：

• 主數(shù)據(jù)在傳統(tǒng)架構(gòu)里面屬于業(yè)務(wù)系統(tǒng)，在中臺和微服務(wù)架構(gòu)下可能會被拆分為多個微服務(wù)。即原來主數(shù)據(jù)管理的物料，供應(yīng)商，人員可能會拆分中臺架構(gòu)里面的物料中心，供應(yīng)商中心，人員中心。

• 主數(shù)據(jù)在整個架構(gòu)演進(jìn)后，會轉(zhuǎn)變?yōu)闃I(yè)務(wù)中臺各個中心。

• 主數(shù)據(jù)在傳統(tǒng)架構(gòu)里面由于存在數(shù)據(jù)共享模式，因此一般也包括ETL，數(shù)據(jù)集成等功能。但是轉(zhuǎn)到中臺架構(gòu)后，由于在業(yè)務(wù)中臺核心是數(shù)據(jù)不落地實時開放共享，因此已經(jīng)不存在這種集成點，即老架構(gòu)里面的【1】這個點在中臺架構(gòu)中已經(jīng)不存在。

• 原來主數(shù)據(jù)系統(tǒng)存在模型數(shù)據(jù)全域視圖查詢能力轉(zhuǎn)移到數(shù)據(jù)中臺實現(xiàn)。

以上就是關(guān)于主數(shù)據(jù)平臺和數(shù)據(jù)中臺的一些關(guān)鍵區(qū)別點。

業(yè)務(wù)中臺是不是就是原來的業(yè)務(wù)邏輯層？

最近經(jīng)常聽到有人把業(yè)務(wù)邏輯層等同于業(yè)務(wù)中臺，這個是極其嚴(yán)重的錯誤。

業(yè)務(wù)邏輯層是我們傳統(tǒng)軟件開放技術(shù)架構(gòu)中的內(nèi)部分層，而業(yè)務(wù)中臺則是業(yè)務(wù)層面的能力分層，本身就不應(yīng)該放在一個層面來進(jìn)行對比。

要意識到業(yè)務(wù)中臺只是共性業(yè)務(wù)能力下沉，非共性業(yè)務(wù)能力仍然是在前臺。

即對于前臺的各個應(yīng)用，仍然有業(yè)務(wù)邏輯層，只是這里的業(yè)務(wù)邏輯無法復(fù)用，因此在前臺各個模塊自己實現(xiàn)。包括各個前臺仍然也可以有自己的數(shù)據(jù)庫一樣，前臺也是一個獨立完整的微服務(wù)。

同樣對于中臺模塊，也不僅僅是邏輯層，同樣可以包含前端頁面和展現(xiàn)層。

那么業(yè)務(wù)中臺的各個微服務(wù)實際的展現(xiàn)形式有哪些？具體如下：

形式1和2：包括數(shù)據(jù)庫，邏輯層

這是中臺模塊比較典型的一個展現(xiàn)形式，比如類似供應(yīng)商中心，有獨立的Owner數(shù)據(jù)庫，本身的供應(yīng)商系統(tǒng)管理員維護(hù)的功能仍然在這個中心完成，但是供應(yīng)商能力本身又需要通過API接口發(fā)布給前臺共享使用。

當(dāng)然在也存在該微服務(wù)不提供前端界面的可能，即該中心全部是服務(wù)能力接口對外暴露，所有的對數(shù)據(jù)的操作功能全部在前端各個應(yīng)用模塊來完成，即使系統(tǒng)管理員維護(hù)功能也不提供。

形式3和4：不包括數(shù)據(jù)庫，含邏輯層和前端頁面

不Owner數(shù)據(jù)庫是什么意義？可以理解為該中臺模塊的業(yè)務(wù)規(guī)則和邏輯的實現(xiàn)全部是通過中臺其它模塊提供的API服務(wù)接口的組合和組裝來完成的。那么這種情況下中臺模塊就沒有Owner的數(shù)據(jù)庫。

比如供應(yīng)商績效評估微服務(wù)，這個微服務(wù)重點就是供應(yīng)商靜態(tài)數(shù)據(jù)，供應(yīng)商供貨的動態(tài)數(shù)據(jù)，基于某種規(guī)則進(jìn)行績效計算，最終返回績效評估結(jié)果。而供應(yīng)商靜態(tài)動態(tài)數(shù)據(jù)獲取需要訪問供應(yīng)商中心，采購中心，質(zhì)檢中心多個微服務(wù)來獲取數(shù)據(jù)。