SOA架構(gòu)思想

我們可以來(lái)看下SOA本身的定義，即：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

企業(yè)中臺(tái)和中臺(tái)思想

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

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

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

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

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

第二點(diǎn)就是通過(guò)中臺(tái)來(lái)實(shí)現(xiàn)進(jìn)一步的資源整合復(fù)用，降低成本

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

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

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

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

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

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

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

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

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

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

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

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

談到這里，我需要糾正下我原來(lái)的一個(gè)看法。

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

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

題外話：經(jīng)?？吹接腥藢I(yè)務(wù)邏輯層理解為中臺(tái)，這個(gè)也是錯(cuò)誤對(duì)比，這兩個(gè)不是一個(gè)層面的概念。中臺(tái)模塊有業(yè)務(wù)邏輯層，前臺(tái)模塊也有。要明白不是所有業(yè)務(wù)邏輯都是共性和可復(fù)用的，對(duì)于不可復(fù)用的業(yè)務(wù)邏輯仍然是在前臺(tái)模塊中，而非中臺(tái)。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

對(duì)于兩者，我原來(lái)做過(guò)一個(gè)簡(jiǎn)單的對(duì)比，大家可以參考。

這個(gè)概念理解后，我們?cè)倩氐轿⒎?wù)架構(gòu)里面。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

以下我們?cè)倏偨Y(jié)下兩者區(qū)別的一些關(guān)鍵點(diǎn)說(shuō)明

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

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

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

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

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

實(shí)際上對(duì)于數(shù)據(jù)中臺(tái)，我們不僅僅要比較和業(yè)務(wù)中臺(tái)的區(qū)別，還需要比較和傳統(tǒng)BI的區(qū)別。因?yàn)閺纳蠄D我們可以看到數(shù)據(jù)中臺(tái)和傳統(tǒng)的BI系統(tǒng)架構(gòu)還是很類似。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

對(duì)于數(shù)據(jù)中臺(tái)前面已經(jīng)講過(guò)了，我們?cè)賮?lái)看下主數(shù)據(jù)定義。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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