在前面我已經(jīng)分享了些關(guān)于中臺(tái)，微服務(wù)，傳統(tǒng)企業(yè)IT架構(gòu)轉(zhuǎn)型方面的文章。今天準(zhǔn)備展開(kāi)談下互聯(lián)網(wǎng)企業(yè)建設(shè)中臺(tái)和傳統(tǒng)企業(yè)建設(shè)中臺(tái)的一些差異點(diǎn)，以及互聯(lián)網(wǎng)中臺(tái)建設(shè)方法論和架構(gòu)設(shè)計(jì)轉(zhuǎn)到企業(yè)后為何出現(xiàn)水土不服的問(wèn)題。

最近這幾年，在SOA和微服務(wù)后，中臺(tái)這個(gè)詞相當(dāng)熱，企業(yè)往往也出現(xiàn)兩種明顯分歧。一種就是中臺(tái)和技術(shù)狂熱型，恨不得企業(yè)的IT明天就能變成中臺(tái)和微服務(wù)架構(gòu)；還有一種企業(yè)就認(rèn)為中臺(tái)就是互聯(lián)網(wǎng)企業(yè)概念炒作，用互聯(lián)網(wǎng)概念來(lái)收割傳統(tǒng)企業(yè)。因此今天準(zhǔn)備對(duì)互聯(lián)網(wǎng)中臺(tái)到傳統(tǒng)企業(yè)中臺(tái)做下對(duì)比分析。

首先再次重申，中臺(tái)本身是一個(gè)業(yè)務(wù)概念，其次才是技術(shù)實(shí)現(xiàn)。中臺(tái)的出現(xiàn)一定是業(yè)務(wù)目標(biāo)和需求驅(qū)動(dòng)的，總結(jié)來(lái)說(shuō)就是如下：

在前端的業(yè)務(wù)需求和模式快速變化的情況下，我們需要快速響應(yīng)。

如何做到快速響應(yīng)？

即從對(duì)業(yè)務(wù)能力的從頭開(kāi)發(fā)，變化為對(duì)已有業(yè)務(wù)能力的組合。因此我們需要將共性業(yè)務(wù)能力進(jìn)行整合，將這些業(yè)務(wù)能力以可共享的API服務(wù)方式提供給前臺(tái)使用。

所以你再回顧互聯(lián)網(wǎng)企業(yè)業(yè)務(wù)組織和架構(gòu)，你會(huì)發(fā)現(xiàn)一個(gè)關(guān)鍵點(diǎn)，即你看到的類似庫(kù)存中心，訂單中心，結(jié)算中心等本身就是業(yè)務(wù)組織部門(mén)或業(yè)務(wù)單元。而這些業(yè)務(wù)組織部門(mén)本身又對(duì)應(yīng)到業(yè)務(wù)模塊的微服務(wù)實(shí)現(xiàn)。即：

業(yè)務(wù)組織部門(mén)或單元=》微服務(wù)模塊實(shí)現(xiàn)之間是完全對(duì)應(yīng)和映射的。

簡(jiǎn)單來(lái)說(shuō)，互聯(lián)網(wǎng)企業(yè)在運(yùn)營(yíng)的過(guò)程中，業(yè)務(wù)組織架構(gòu)本身就已經(jīng)是共性業(yè)務(wù)能力下沉，業(yè)務(wù)組織單元微服務(wù)化的了，其次才是技術(shù)實(shí)現(xiàn)的微服務(wù)化。

業(yè)務(wù)或運(yùn)營(yíng)模式變化快才需要快速響應(yīng)

對(duì)于互聯(lián)網(wǎng)企業(yè)我們一定要比較和傳統(tǒng)企業(yè)關(guān)于用戶群的一個(gè)區(qū)別。互聯(lián)網(wǎng)企業(yè)是直接面對(duì)最終的B端或C端用戶，而傳統(tǒng)企業(yè)IT系統(tǒng)是面對(duì)內(nèi)部的業(yè)務(wù)人員和管理人員。互聯(lián)網(wǎng)企業(yè)本身的產(chǎn)品化運(yùn)營(yíng)往往就需要配合用戶個(gè)性化多變需求快速靈活響應(yīng)，否則就失去機(jī)會(huì)。

類似互聯(lián)網(wǎng)的電商平臺(tái)，你可以看到類似團(tuán)購(gòu)，秒殺，企業(yè)福利，支付理財(cái)，自營(yíng)，toB或toC等各種運(yùn)營(yíng)模式不斷在變化以滿足業(yè)務(wù)需求。而這些前臺(tái)應(yīng)用的構(gòu)建都需要用到采購(gòu)，物流庫(kù)存，財(cái)務(wù)結(jié)算，用戶，產(chǎn)品管理等共性能力。

那么我們期望自然是能夠復(fù)用和組裝這些能力，而不是再去重新開(kāi)發(fā)。

正是由于這種原因，我們需要將共性能力下沉，形成中臺(tái)各業(yè)務(wù)單元。如果從業(yè)務(wù)上來(lái)說(shuō)就是中臺(tái)里面的各個(gè)業(yè)務(wù)組織部門(mén)，能力都相對(duì)穩(wěn)定，不會(huì)經(jīng)常變化。但是前臺(tái)出現(xiàn)新商業(yè)模式后，任何一個(gè)新前臺(tái)應(yīng)用構(gòu)建都可以單獨(dú)組建一個(gè)新的業(yè)務(wù)團(tuán)隊(duì)，這個(gè)業(yè)務(wù)團(tuán)隊(duì)再對(duì)應(yīng)到前臺(tái)應(yīng)用這個(gè)微服務(wù)模塊技術(shù)實(shí)現(xiàn)。

傳統(tǒng)企業(yè)和互聯(lián)網(wǎng)企業(yè)中臺(tái)差異化分析

在了解互聯(lián)網(wǎng)中臺(tái)建設(shè)背景后，我們?cè)賮?lái)回顧傳統(tǒng)企業(yè)是否需要一個(gè)完整中臺(tái)就更加容易點(diǎn)。即我們基于互聯(lián)網(wǎng)企業(yè)出現(xiàn)中臺(tái)的幾個(gè)背景要素進(jìn)行分析來(lái)說(shuō)明。

其一：傳統(tǒng)企業(yè)業(yè)務(wù)是否需要像互聯(lián)網(wǎng)應(yīng)用一樣足夠敏捷？

對(duì)于企業(yè)的完整價(jià)值鏈來(lái)講，我們可以將其分為兩個(gè)關(guān)鍵階段。其一就是圍繞產(chǎn)品從無(wú)到有的核心研發(fā)，供應(yīng)鏈和生產(chǎn)制造價(jià)值鏈。其二是生產(chǎn)出來(lái)的產(chǎn)品如何賣(mài)出來(lái)并交付到最終消費(fèi)者手里面的銷(xiāo)售運(yùn)營(yíng)價(jià)值鏈。

對(duì)于大部分企業(yè)來(lái)說(shuō)，更加重要的是供應(yīng)鏈核心流程，而對(duì)于銷(xiāo)售這塊往往本身就是依托于已有的各大電商平臺(tái)，或別人的分銷(xiāo)體系。除非你自己去構(gòu)建了一個(gè)完整的分銷(xiāo)線下網(wǎng)絡(luò)，類似格力這種自己分銷(xiāo)網(wǎng)絡(luò)體系。

對(duì)于企業(yè)的供應(yīng)鏈核心價(jià)值鏈，企業(yè)本身的計(jì)劃，生產(chǎn)運(yùn)營(yíng)模式不可能隨時(shí)都在變化，同時(shí)面對(duì)的又是內(nèi)部用戶需求本身時(shí)間容忍度也大。

因此IT系統(tǒng)完全不需要類似互聯(lián)網(wǎng)應(yīng)用一樣的敏捷程度。

其二：傳統(tǒng)企業(yè)的業(yè)務(wù)架構(gòu)和組織模式是否先進(jìn)行了重構(gòu)

對(duì)于大部分傳統(tǒng)企業(yè)來(lái)說(shuō)，真正困難和難以推行的都是業(yè)務(wù)組織架構(gòu)的重組，其次才是IT系統(tǒng)的建設(shè)。很多CIO希望通過(guò)IT系統(tǒng)建設(shè)或者說(shuō)當(dāng)前的中臺(tái)，微服務(wù)來(lái)倒逼業(yè)務(wù)架構(gòu)重構(gòu)，往往都是一廂情愿，到最后往往根本推行不下去。

當(dāng)我們觀察大部分企業(yè)的時(shí)候，你會(huì)看到企業(yè)本身的業(yè)務(wù)架構(gòu)往往就沒(méi)有中臺(tái)化。

我們可以舉些常見(jiàn)的例子，比如一個(gè)制造企業(yè)有多個(gè)子公司，你會(huì)看到各個(gè)子公司本身的財(cái)務(wù)，供應(yīng)鏈，售后這些本該業(yè)務(wù)下沉和集中化的本身就沒(méi)有統(tǒng)一。在企業(yè)內(nèi)部業(yè)務(wù)上就沒(méi)有我們經(jīng)常談到的共享中心的概念。

在業(yè)務(wù)組織本身就沒(méi)有共享化，拆分化的情況下推進(jìn)中臺(tái)往往就是難上加難。

其三：前端應(yīng)用是否不斷推陳出新

在前面我已經(jīng)強(qiáng)調(diào)了，傳統(tǒng)企業(yè)的內(nèi)部IT往往就是支撐企業(yè)核心價(jià)值鏈一套業(yè)務(wù)，最多也就是PC端BS應(yīng)用和手機(jī)端兩種展現(xiàn)模式，但是本質(zhì)還是一套應(yīng)用系統(tǒng)。

對(duì)于供應(yīng)鏈核心價(jià)值鏈來(lái)說(shuō)根本就不存在要不斷推出新應(yīng)用的可能。只存在會(huì)出現(xiàn)業(yè)務(wù)流程的情況，而對(duì)于新業(yè)務(wù)流程的出現(xiàn)往往基于傳統(tǒng)SOA架構(gòu)思路完全可以解決。即將遺留系統(tǒng)接入和適配，將服務(wù)能力共享開(kāi)放即可。

傳統(tǒng)企業(yè)什么時(shí)候需要一個(gè)中臺(tái)？

經(jīng)過(guò)上面分析我們可以看到，大部分企業(yè)并不需要一個(gè)類似互聯(lián)網(wǎng)企業(yè)一樣的中臺(tái)。那么什么時(shí)候需要這個(gè)中臺(tái)呢？

也就是什么時(shí)候會(huì)出現(xiàn)類似互聯(lián)網(wǎng)企業(yè)一樣的背景需求。

還是會(huì)到前面的分析，簡(jiǎn)單來(lái)講就是：對(duì)于本身就是做C端消費(fèi)類產(chǎn)品的企業(yè)，本身又希望實(shí)現(xiàn)對(duì)終端用戶的端到端觸達(dá)能力，同時(shí)營(yíng)銷(xiāo)價(jià)值鏈本身又是完全自建的情況。這種企業(yè)往往中臺(tái)規(guī)劃建設(shè)的需求最強(qiáng)烈。

我們也看到當(dāng)前很多上中臺(tái)的企業(yè)更多就是屬于上面場(chǎng)景的企業(yè)，而且中臺(tái)的構(gòu)建更多的是面向自己的電商平臺(tái)，CRM營(yíng)銷(xiāo)網(wǎng)絡(luò)，面向C端的前臺(tái)應(yīng)用需求。

在這種情況下，企業(yè)需要去構(gòu)建一個(gè)中臺(tái)來(lái)滿足前臺(tái)應(yīng)用敏捷化的需求。

也就是說(shuō)這個(gè)企業(yè)中臺(tái)已經(jīng)不再是簡(jiǎn)單的滿足內(nèi)部業(yè)務(wù)系統(tǒng)，內(nèi)部用戶的使用，而是更多的打破了企業(yè)邊界，面向外部的消費(fèi)者用戶，或者產(chǎn)業(yè)鏈上的生態(tài)合作伙伴的需求。

在這種場(chǎng)景下，我們就需要對(duì)企業(yè)內(nèi)部已有的業(yè)務(wù)能力進(jìn)一步包裝和抽取共性，然后將共性能力以API接口服務(wù)的方式提供給前臺(tái)應(yīng)用。

其次，就是一個(gè)大的集團(tuán)性企業(yè)，本身在進(jìn)行業(yè)務(wù)重組，將共性業(yè)務(wù)能力形成共享中心的方式進(jìn)行統(tǒng)一的情況下，需要去構(gòu)建一個(gè)中臺(tái)。這個(gè)也和我們中臺(tái)產(chǎn)生背景思路一致。

比如前面談到的，一個(gè)生產(chǎn)制造企業(yè)，本身有很多子公司或工廠，但是你可以看到企業(yè)的供應(yīng)鏈能力，營(yíng)銷(xiāo)服務(wù)能力，售后服務(wù)能力完全是可以共享和復(fù)用的，這些業(yè)務(wù)能力應(yīng)該進(jìn)行整合和統(tǒng)一。真正差異化的僅僅是制造各類產(chǎn)品不同的制造單元。

在這種明確的業(yè)務(wù)驅(qū)動(dòng)和業(yè)務(wù)整合背景下，往往也是最佳的構(gòu)建中臺(tái)場(chǎng)景。

傳統(tǒng)企業(yè)更多的是轉(zhuǎn)型到平臺(tái)+應(yīng)用構(gòu)建模式

這里的平臺(tái)我們指技術(shù)平臺(tái)，或者對(duì)應(yīng)到中臺(tái)概念里面的技術(shù)中臺(tái)。這個(gè)平臺(tái)即我經(jīng)常說(shuō)到的私有云PaaS平臺(tái)。而私有云PaaS平臺(tái)的重點(diǎn)就是將企業(yè)內(nèi)部業(yè)務(wù)系統(tǒng)構(gòu)建需要的共性技術(shù)服務(wù)能力下沉并統(tǒng)一建設(shè)。這些共性技術(shù)能力包括了中間件，數(shù)據(jù)庫(kù)資源池，也包括了類似4A，流程引擎，消息，緩存，文件，任務(wù)調(diào)度等共性技術(shù)服務(wù)能力。

為何平臺(tái)建設(shè)如此重要？

我們要意識(shí)到只有原業(yè)務(wù)系統(tǒng)中的技術(shù)平臺(tái)完全下沉并移出，上次的業(yè)務(wù)系統(tǒng)模塊才能夠?qū)崿F(xiàn)徹底的組件和微服務(wù)化架構(gòu)。

這個(gè)我在前面一篇文章專門(mén)談到過(guò)，可以參考：

SOA和云計(jì)算-企業(yè)私有云PaaS平臺(tái)建設(shè)實(shí)踐

同時(shí)對(duì)應(yīng)平臺(tái)層規(guī)劃建設(shè)，我們理解重點(diǎn)應(yīng)該包括：

步驟1:4A和流程平臺(tái)的下沉和能力開(kāi)放

這個(gè)是我談的最多的問(wèn)題，即在實(shí)施微服務(wù)架構(gòu)轉(zhuǎn)型的時(shí)候必須將4A（也可先狹義理解為原業(yè)務(wù)系統(tǒng)的系統(tǒng)管理模塊）和流程引擎下沉到平臺(tái)層共性建設(shè)，或者說(shuō)優(yōu)先要將這兩個(gè)模塊作為微服務(wù)模塊剝離出來(lái)，同時(shí)給上層的業(yè)務(wù)組件模塊提供API服務(wù)接口能力。

對(duì)于4A模塊剝離后，我們希望的是涉及到人員，組織，用戶，權(quán)限等能力的獲取都是通過(guò)服務(wù)接口實(shí)時(shí)查詢獲取，這些基礎(chǔ)主數(shù)據(jù)信息也不要落地。在進(jìn)行這樣實(shí)施的時(shí)候確實(shí)會(huì)增加上層業(yè)務(wù)系統(tǒng)的改造工作量。對(duì)于流程平臺(tái)的簽出相對(duì)來(lái)說(shuō)比較容易，最主要的還是給業(yè)務(wù)模塊提供流程啟動(dòng)，暫停，獲取待辦已辦列表等關(guān)系服務(wù)接口信息為主。

進(jìn)行4A和流程平臺(tái)的剝離核心目的仍然是是的后續(xù)需要進(jìn)行拆分的業(yè)務(wù)模塊只包含業(yè)務(wù)功能，而不再包含共性的技術(shù)能力功能。

步驟2：基礎(chǔ)主數(shù)據(jù)模塊能力獨(dú)立建設(shè)

這是我們談的第二個(gè)重點(diǎn)，即希望將提供共享基礎(chǔ)主數(shù)據(jù)的功能單獨(dú)剝離出來(lái)進(jìn)行獨(dú)立建設(shè)，比如建設(shè)獨(dú)立的主數(shù)據(jù)平臺(tái)或叫提供基礎(chǔ)主數(shù)據(jù)的各個(gè)數(shù)據(jù)中心模塊。然后數(shù)據(jù)能力以數(shù)據(jù)服務(wù)的方式暴露出去供上層業(yè)務(wù)系統(tǒng)使用，同樣我們希望上層業(yè)務(wù)模塊在使用這些基礎(chǔ)主數(shù)據(jù)的時(shí)候最好主數(shù)據(jù)不落地，實(shí)時(shí)用實(shí)時(shí)查。

在傳統(tǒng)PaaS平臺(tái)建設(shè)中會(huì)涉及到MDM主數(shù)據(jù)平臺(tái)的建設(shè)，到了徹底的微服務(wù)架構(gòu)可能并不存在主數(shù)據(jù)平臺(tái)的概念，而是各個(gè)類似產(chǎn)品中心，供應(yīng)商中心，客戶中心的各個(gè)微主數(shù)據(jù)中心模塊，這些微服務(wù)模塊也是我們常說(shuō)的中臺(tái)的核心數(shù)據(jù)能力提供中心。

要規(guī)劃和建設(shè)中臺(tái)，首先要考慮的就是這種基礎(chǔ)數(shù)據(jù)中心，其次才是提供業(yè)務(wù)支撐和業(yè)務(wù)邏輯處理的中心。

步驟3：及早進(jìn)行統(tǒng)一門(mén)戶的建設(shè)

要注意，在各個(gè)微服務(wù)模塊建設(shè)完成后，單個(gè)微服務(wù)模塊本身是不能提供支撐完整業(yè)務(wù)流程的能力。對(duì)于用戶來(lái)說(shuō)并不關(guān)心是否進(jìn)行了微服務(wù)架構(gòu)化，而是關(guān)心涉及到業(yè)務(wù)流程處理的功能和操作是否能夠很方便的在一個(gè)業(yè)務(wù)應(yīng)用里面操作和完成。

而這些業(yè)務(wù)模塊基于業(yè)務(wù)流程，基于業(yè)務(wù)場(chǎng)景和使用部門(mén)的組裝和展現(xiàn)，就需要在門(mén)戶層完成。對(duì)于統(tǒng)一門(mén)戶不僅僅是提供統(tǒng)一認(rèn)證和單點(diǎn)登錄，也還包括了統(tǒng)一的待辦集成和任務(wù)處理，統(tǒng)一的消息通知等共性功能能力。也就是說(shuō)，只要是各個(gè)微服務(wù)模塊共性的一些需要展現(xiàn)的能力，都可以集中化到統(tǒng)一門(mén)戶層去集中處理和展現(xiàn)。

門(mén)戶層還有一個(gè)重要的功能就是進(jìn)行微服務(wù)模塊的組裝，這些模塊組裝后可以為業(yè)務(wù)用戶提供完整的端到端業(yè)務(wù)流程功能支持，讓最終用戶的感覺(jué)就是在使用一個(gè)系統(tǒng)，沒(méi)有系統(tǒng)不停切換的感覺(jué)。因此實(shí)際上在門(mén)戶層不僅僅是簡(jiǎn)單的模塊選擇，也還可以做一些展現(xiàn)層的編排和組合工作。

對(duì)于微服務(wù)模塊的靈活組裝也是相當(dāng)困難的，因?yàn)楹芏嗄K組裝最終都是體現(xiàn)到模塊提供的南北向接口的自動(dòng)對(duì)接，這往往是比對(duì)服務(wù)組合和服務(wù)編排進(jìn)行定制更加困難，對(duì)于這個(gè)問(wèn)題后續(xù)單獨(dú)進(jìn)行討論。

已有的IT架構(gòu)和遺留系統(tǒng)如何構(gòu)建中臺(tái)？

這個(gè)估計(jì)是大部分企業(yè)都會(huì)遇到的問(wèn)題。也是我們經(jīng)常說(shuō)的，傳統(tǒng)企業(yè)中臺(tái)的構(gòu)建不能完全照搬互聯(lián)網(wǎng)企業(yè)中臺(tái)構(gòu)建思路，而是需要考慮如何最大化的保護(hù)遺留IT資產(chǎn)。

即使企業(yè)是需要對(duì)外構(gòu)建完整生態(tài)鏈的情況下，也不可能將企業(yè)內(nèi)部已有的IT系統(tǒng)全部完整中臺(tái)和微服務(wù)的架構(gòu)思路完全推倒重新建設(shè)。

正是這個(gè)原因，我們提出一個(gè)重點(diǎn)，即：

傳統(tǒng)企業(yè)在最大化保留遺留資產(chǎn)情況下，更多應(yīng)該是適配方式構(gòu)建一個(gè)能力中臺(tái)。

在這里我將其稱呼為能力中臺(tái)意思就是，這個(gè)中臺(tái)的服務(wù)能力不是全新產(chǎn)生的，而是對(duì)遺留IT系統(tǒng)能力的一種適配和聚合形成的。

即能力中臺(tái)有點(diǎn)類似于我們傳統(tǒng)在SOA架構(gòu)下的ESB總線和服務(wù)共享平臺(tái)建設(shè)。

那么這個(gè)能力中臺(tái)和單純的ESB總線區(qū)別在哪里呢？

其中最大的區(qū)別就在于這個(gè)能力中臺(tái)，本身不是簡(jiǎn)單的接口服務(wù)接入和集成，而是對(duì)已有的遺留IT資產(chǎn)，數(shù)據(jù)庫(kù)，接口API等進(jìn)行了重構(gòu)，適配，整合和重組，構(gòu)建了一個(gè)滿足新業(yè)務(wù)構(gòu)建的完整領(lǐng)域服務(wù)能力層提供。

也就是說(shuō)這個(gè)能力中臺(tái)本身是可能存在業(yè)務(wù)代碼和業(yè)務(wù)邏輯的。

如上面圖所示，在構(gòu)建新的中臺(tái)能力服務(wù)層的時(shí)候，為了對(duì)已有的業(yè)務(wù)系統(tǒng)影響最小，我們需要重新構(gòu)建中臺(tái)能力接口，這個(gè)接口涉及到一定的適配和定制開(kāi)發(fā)工作量。

具體接口的實(shí)現(xiàn)本身又包括了三種方式，即：

直接連接遺留系統(tǒng)的數(shù)據(jù)庫(kù)，來(lái)重新開(kāi)發(fā)接口服務(wù)。

通過(guò)遺留系統(tǒng)已有的JAR包引入，來(lái)重新開(kāi)發(fā)接口服務(wù)。

通過(guò)遺留系統(tǒng)已有的WS或Rest等接口服務(wù)適配，來(lái)重新開(kāi)發(fā)接口服務(wù)。

可以看到三種模式中對(duì)于數(shù)據(jù)庫(kù)這種模式是對(duì)業(yè)務(wù)系統(tǒng)依賴最小的模式，但是這個(gè)模式本身也是需要我們重新進(jìn)行完整性校驗(yàn)，業(yè)務(wù)規(guī)則的模式。這種模式本身就可以看到對(duì)遺留業(yè)務(wù)系統(tǒng)的部分業(yè)務(wù)規(guī)則和能力進(jìn)行了重寫(xiě)，即這部分業(yè)務(wù)邏輯規(guī)則已經(jīng)在朝中臺(tái)能力層逐步遷移。

這種遷移形成的接口服務(wù)能力，一方面是構(gòu)建全新的業(yè)務(wù)應(yīng)用可以使用。而同時(shí)，我們建議是及時(shí)對(duì)于PMS或SCM等業(yè)務(wù)系統(tǒng)，如果有全新的業(yè)務(wù)模塊需要開(kāi)發(fā)，也完全可以基于中臺(tái)已有的接口服務(wù)能力進(jìn)行，只有這樣才容易實(shí)現(xiàn)后續(xù)的業(yè)務(wù)系統(tǒng)逐步遷移到中臺(tái)架構(gòu)上。

數(shù)據(jù)重構(gòu)和服務(wù)組合是中臺(tái)另外一個(gè)關(guān)鍵能力

在中臺(tái)能力構(gòu)建的時(shí)候，一定要考慮數(shù)據(jù)重構(gòu)和能力組合。

即中臺(tái)的能力接口不是簡(jiǎn)單的數(shù)據(jù)庫(kù)CRUD能力暴露，也不是已有的遺留接口的簡(jiǎn)單適配和接入。而是真正根據(jù)業(yè)務(wù)流程和業(yè)務(wù)需求驅(qū)動(dòng)，實(shí)現(xiàn)關(guān)鍵的業(yè)務(wù)能力，將業(yè)務(wù)能力轉(zhuǎn)變?yōu)榉?wù)。這種服務(wù)本身是粗粒度的，有明確的業(yè)務(wù)含義，有點(diǎn)類似我們?cè)陬I(lǐng)域架構(gòu)設(shè)計(jì)里面經(jīng)常談到的領(lǐng)域服務(wù)能力。

中臺(tái)構(gòu)建不要盲目的微服務(wù)架構(gòu)化

最后再次強(qiáng)調(diào)下，企業(yè)中臺(tái)的構(gòu)建不一定要全面微服務(wù)化。比如我們前面說(shuō)的能力中臺(tái)建設(shè)，更多的是適配已有的資產(chǎn)能力進(jìn)行重構(gòu)形成能力開(kāi)放平臺(tái)。

我始終認(rèn)為：企業(yè)業(yè)務(wù)共性能力下沉，并形成統(tǒng)一服務(wù)對(duì)前臺(tái)提供。

這樣滿足這個(gè)目標(biāo)要求，構(gòu)建的就是企業(yè)中臺(tái)，這個(gè)中臺(tái)是否一定微服務(wù)化反而不是重點(diǎn)，只是說(shuō)微服務(wù)化后，整體的解耦，擴(kuò)展性更強(qiáng)而已。

但是一定要注意到，引入微服務(wù)本身對(duì)企業(yè)IT治理管控水平要求相對(duì)高。如果企業(yè)本身的IT成熟度沒(méi)有達(dá)到一定階段，顯然是不可能推行實(shí)施微服務(wù)架構(gòu)的。這個(gè)道理前面已經(jīng)談到過(guò)，在企業(yè)IT建設(shè)中，如果連粗粒度的業(yè)務(wù)系統(tǒng)以及它們之間的集成都管理不好，那么更沒(méi)有能力管理細(xì)粒度的微服務(wù)模塊。

那么如果企業(yè)IT成熟度達(dá)到一定水平，在推廣微服務(wù)架構(gòu)還存在的難點(diǎn)如下：

首先是架構(gòu)設(shè)計(jì)能力的顯性化，即架構(gòu)設(shè)計(jì)這個(gè)工作的輸入，輸出和過(guò)程需要更加的顯性化出來(lái)形成團(tuán)隊(duì)都認(rèn)同的標(biāo)準(zhǔn)工件。一個(gè)業(yè)務(wù)系統(tǒng)沒(méi)有拆分開(kāi)時(shí)候，雖然有架構(gòu)設(shè)計(jì)和組件劃分，但是這個(gè)工作是屬于團(tuán)隊(duì)內(nèi)部的事情，即使架構(gòu)設(shè)計(jì)不合理，在后期集成也可以通過(guò)諸多變通方式解決掉。而現(xiàn)在是不同的微服務(wù)模塊可能分派到兩個(gè)獨(dú)立的團(tuán)隊(duì)開(kāi)發(fā)，原來(lái)屬于自己內(nèi)部黑盒的問(wèn)題變?yōu)閳F(tuán)隊(duì)間問(wèn)題。

簡(jiǎn)單來(lái)說(shuō)你原來(lái)藏著或沒(méi)做規(guī)范的東西太多，而現(xiàn)在這些不能再藏著掖著了，當(dāng)真要把這些東西拿出來(lái)的時(shí)候，你才會(huì)發(fā)現(xiàn)你原來(lái)架構(gòu)能力是有欠缺的。正如我們理解了一個(gè)東西，那么要讓我們清楚的講出來(lái)困難，那么我們的理解有欠缺。對(duì)于我們能講清楚的東西，要系統(tǒng)寫(xiě)下來(lái)有困難，那么說(shuō)明我們講的結(jié)構(gòu)和條理有欠缺。

其次管控要求和規(guī)范體系的建立，對(duì)于管控要求可以看到如果兩個(gè)微服務(wù)模塊分給同一個(gè)團(tuán)隊(duì)開(kāi)發(fā)，如何才能保證開(kāi)發(fā)的團(tuán)隊(duì)保持兩個(gè)模塊的完全獨(dú)立和解耦，兩個(gè)模塊間不會(huì)出現(xiàn)相互交叉的數(shù)據(jù)庫(kù)直接調(diào)用，也不會(huì)存在直接繞開(kāi)Service接口的其它耦合調(diào)用？這些如果沒(méi)有完整的管控和檢查體系我們很難約束。

微服務(wù)架構(gòu)下導(dǎo)致的開(kāi)發(fā)復(fù)雜度增加

只談微服務(wù)架構(gòu)的松耦合和高擴(kuò)展性，而不談開(kāi)發(fā)和集成復(fù)雜度的都是耍流氓。

實(shí)際上當(dāng)前很多企業(yè)對(duì)微服務(wù)架構(gòu)并沒(méi)有如此迫切，互聯(lián)網(wǎng)很多企業(yè)推行微服務(wù)架構(gòu)更多的還是考慮到巨大的業(yè)務(wù)并發(fā)量下的系統(tǒng)彈性擴(kuò)展能力，而實(shí)際大多數(shù)企業(yè)內(nèi)應(yīng)用往往并沒(méi)有如此海量并發(fā)。

其次，即使在并發(fā)量增加的情況下通過(guò)進(jìn)行代碼本身的優(yōu)化，數(shù)據(jù)庫(kù)調(diào)優(yōu)或者升級(jí)硬件服務(wù)器資源都可以較好解決性能問(wèn)題。而做這些事情投入的成本遠(yuǎn)遠(yuǎn)小于微服務(wù)架構(gòu)帶來(lái)的開(kāi)發(fā)復(fù)雜度增加成本，后期的運(yùn)維管控成本。

要做到完全微服務(wù)模塊獨(dú)立，微服務(wù)架構(gòu)下最大的一個(gè)變化就是數(shù)據(jù)庫(kù)也拆分開(kāi)了，原來(lái)的一個(gè)業(yè)務(wù)系統(tǒng)如果分為5個(gè)微服務(wù)模塊，那理論上就是5個(gè)獨(dú)立的后臺(tái)數(shù)據(jù)庫(kù)，而且數(shù)據(jù)庫(kù)間還不能隨便相互連接和訪問(wèn)。只有這樣微服務(wù)模塊才能做到獨(dú)立部署和管理。

由于數(shù)據(jù)庫(kù)拆分帶來(lái)兩個(gè)問(wèn)題，其一是我們?cè)瓉?lái)很簡(jiǎn)單的一個(gè)跨表查詢操作現(xiàn)在無(wú)法做了，我們必須調(diào)用兩個(gè)微服務(wù)模塊提供的服務(wù)，查詢到數(shù)據(jù)后再到邏輯層進(jìn)行組合。其次最大的問(wèn)題就是如果一個(gè)業(yè)務(wù)操作需要同時(shí)更新兩個(gè)微服務(wù)模塊的數(shù)據(jù)，由于服務(wù)本身無(wú)狀態(tài)，導(dǎo)致了這種分布式事務(wù)問(wèn)題很難解決。

企業(yè)內(nèi)業(yè)務(wù)系統(tǒng)很大一個(gè)特點(diǎn)就是業(yè)務(wù)邏輯和規(guī)則相對(duì)互聯(lián)網(wǎng)更加復(fù)雜，而且有更高的事務(wù)一致性要求。正是由于這個(gè)原因，無(wú)法解決好分布式事務(wù)的問(wèn)題都將直接導(dǎo)致后續(xù)數(shù)據(jù)不一致和業(yè)務(wù)錯(cuò)誤。

微服務(wù)架構(gòu)下導(dǎo)致的集成復(fù)雜度增加

任何一個(gè)微服務(wù)模塊在外部協(xié)同上都存在兩個(gè)點(diǎn)，一個(gè)是模塊本身要消費(fèi)和調(diào)用其它微服務(wù)模塊提供的服務(wù)接口，另外一個(gè)是模塊本身又需要將其業(yè)務(wù)能力暴露為服務(wù)接口給其它微服務(wù)模塊使用。

如果一個(gè)微服務(wù)模塊要同時(shí)支撐PC端和APP端，可以看到微服務(wù)模塊暴露的服務(wù)還需要統(tǒng)一提供給前端的展示用。那么可以看到一個(gè)微服務(wù)模塊需要完成自身組件層和展現(xiàn)層間的集成，同時(shí)又需要完成多個(gè)微服務(wù)模塊組件間的橫向服務(wù)集成。

如果我們將消息，日志，流程，4A等能力下沉到平臺(tái)層微服務(wù)模塊，那么一個(gè)組件要跑起來(lái)還涉及到和平臺(tái)層的多個(gè)技術(shù)類微服務(wù)模塊集成。在如此復(fù)雜的集成場(chǎng)景下，要將復(fù)雜的跨多個(gè)微服務(wù)模塊的橫向端到端業(yè)務(wù)跑通，其涉及到的模塊數(shù)，接口數(shù)都遠(yuǎn)超原有單一系統(tǒng)的模式。

一個(gè)業(yè)務(wù)系統(tǒng)如果沒(méi)有拆分為微服務(wù)模塊，那么其它內(nèi)的模塊間集成和集成測(cè)試是系統(tǒng)內(nèi)部的事情，但是一旦拆分為多個(gè)微服務(wù)模塊，那么這種集成就變成外部第三方的事情，或者必須要顯性的事情。集成復(fù)雜度會(huì)大增，同時(shí)系統(tǒng)健壯性和穩(wěn)定性下降。

微服務(wù)架構(gòu)下的運(yùn)維問(wèn)題

在實(shí)施了微服務(wù)架構(gòu)后，運(yùn)維的復(fù)雜度也是成倍增加，任何一個(gè)微服務(wù)模塊出問(wèn)題都可能影響到整個(gè)業(yè)務(wù)應(yīng)用的功能使用。我們?cè)谶\(yùn)維時(shí)候不僅僅要健康單個(gè)微服務(wù)模塊，還需要健康所有的接口服務(wù)監(jiān)控狀態(tài)。

如果跟Docker集成了，我們看到整個(gè)性能監(jiān)控和問(wèn)題分析都會(huì)變麻煩了，沒(méi)有實(shí)施微服務(wù)架構(gòu)前發(fā)現(xiàn)問(wèn)題，我們直接可以看應(yīng)用服務(wù)器上類似tomcat或jboss日志，而實(shí)施了微服務(wù)架構(gòu)后，應(yīng)用容器已經(jīng)是自動(dòng)部署和動(dòng)態(tài)分配的，原有的故障診斷模式行不通，而需要PaaS平臺(tái)本身提供完整的預(yù)警和日志分析能力。