SOA架構(gòu)思想

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

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

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

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

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

其一：找到可復用服務

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

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

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

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

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

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

SOA和ESB總線的關系

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

接著再來看下微服務，談微服務一定是和單體應用對比。

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

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

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

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

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

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

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

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

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

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

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

中臺=SOA思想 微服務

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

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

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

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

當我們理解了這個核心概念后，我們才能夠認識到如下幾點關鍵認識。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

技術中臺建議叫技術平臺

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

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

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

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

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

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

云原生=微服務 DevOps 容器云

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

為了做到實時或準實時，一方面你會看到數(shù)據(jù)中臺架構(gòu)上實際上是包括了大數(shù)據(jù)平臺的核心架構(gòu)和分布式存儲內(nèi)容，同時還包括了大數(shù)據(jù)平臺中的實時計算和流處理能力。其次，為了將能力提供給業(yè)務系統(tǒng)，往往數(shù)據(jù)中臺整體架構(gòu)上一定會體現(xiàn)一個統(tǒng)一的數(shù)據(jù)服務能力開放層，這個在傳統(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ù)服務能力開放層，提供給業(yè)務使用，而弱化了傳統(tǒng)BI里面的數(shù)據(jù)分析和報表展現(xiàn)層。

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

圖片來源網(wǎng)絡

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

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

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

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

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

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

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

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

• 一套數(shù)據(jù)管控和治理標準規(guī)范體系

因此可以看到對于數(shù)據(jù)中臺核心重要的反而是數(shù)據(jù)資產(chǎn) 數(shù)據(jù)服務能力共享這兩點。如果整個數(shù)據(jù)中臺建設有大數(shù)據(jù)平臺，那么大數(shù)據(jù)平臺也僅僅是一個底層技術平臺和技術實現(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è)務實體(如客戶、供應商、地點、產(chǎn)品和庫存)的一個或多個屬性。所以主數(shù)據(jù)即是在進行企業(yè)業(yè)務架構(gòu)分析中發(fā)現(xiàn)的核心業(yè)務對象?；蛘咧v主數(shù)據(jù)是企業(yè)已經(jīng)存在的涉及到價值鏈核心業(yè)務流程的各個IT系統(tǒng)的基礎數(shù)據(jù)。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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