在前面我已經分享了些關于中臺，微服務，傳統企業IT架構轉型方面的文章。今天準備展開談下互聯網企業建設中臺和傳統企業建設中臺的一些差異點，以及互聯網中臺建設方法論和架構設計轉到企業后為何出現水土不服的問題。

最近這幾年，在SOA和微服務后，中臺這個詞相當熱，企業往往也出現兩種明顯分歧。一種就是中臺和技術狂熱型，恨不得企業的IT明天就能變成中臺和微服務架構；還有一種企業就認為中臺就是互聯網企業概念炒作，用互聯網概念來收割傳統企業。因此今天準備對互聯網中臺到傳統企業中臺做下對比分析。

首先再次重申，中臺本身是一個業務概念，其次才是技術實現。中臺的出現一定是業務目標和需求驅動的，總結來說就是如下：

在前端的業務需求和模式快速變化的情況下，我們需要快速響應。

如何做到快速響應？

即從對業務能力的從頭開發，變化為對已有業務能力的組合。因此我們需要將共性業務能力進行整合，將這些業務能力以可共享的API服務方式提供給前臺使用。

所以你再回顧互聯網企業業務組織和架構，你會發現一個關鍵點，即你看到的類似庫存中心，訂單中心，結算中心等本身就是業務組織部門或業務單元。而這些業務組織部門本身又對應到業務模塊的微服務實現。即：

業務組織部門或單元=》微服務模塊實現之間是完全對應和映射的。

簡單來說，互聯網企業在運營的過程中，業務組織架構本身就已經是共性業務能力下沉，業務組織單元微服務化的了，其次才是技術實現的微服務化。

業務或運營模式變化快才需要快速響應

對于互聯網企業我們一定要比較和傳統企業關于用戶群的一個區別。互聯網企業是直接面對最終的B端或C端用戶，而傳統企業IT系統是面對內部的業務人員和管理人員。互聯網企業本身的產品化運營往往就需要配合用戶個性化多變需求快速靈活響應，否則就失去機會。

類似互聯網的電商平臺，你可以看到類似團購，秒殺，企業福利，支付理財，自營，toB或toC等各種運營模式不斷在變化以滿足業務需求。而這些前臺應用的構建都需要用到采購，物流庫存，財務結算，用戶，產品管理等共性能力。

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

正是由于這種原因，我們需要將共性能力下沉，形成中臺各業務單元。如果從業務上來說就是中臺里面的各個業務組織部門，能力都相對穩定，不會經常變化。但是前臺出現新商業模式后，任何一個新前臺應用構建都可以單獨組建一個新的業務團隊，這個業務團隊再對應到前臺應用這個微服務模塊技術實現。

傳統企業和互聯網企業中臺差異化分析

在了解互聯網中臺建設背景后，我們再來回顧傳統企業是否需要一個完整中臺就更加容易點。即我們基于互聯網企業出現中臺的幾個背景要素進行分析來說明。

其一：傳統企業業務是否需要像互聯網應用一樣足夠敏捷？

對于企業的完整價值鏈來講，我們可以將其分為兩個關鍵階段。其一就是圍繞產品從無到有的核心研發，供應鏈和生產制造價值鏈。其二是生產出來的產品如何賣出來并交付到最終消費者手里面的銷售運營價值鏈。

對于大部分企業來說，更加重要的是供應鏈核心流程，而對于銷售這塊往往本身就是依托于已有的各大電商平臺，或別人的分銷體系。除非你自己去構建了一個完整的分銷線下網絡，類似格力這種自己分銷網絡體系。

對于企業的供應鏈核心價值鏈，企業本身的計劃，生產運營模式不可能隨時都在變化，同時面對的又是內部用戶需求本身時間容忍度也大。

因此IT系統完全不需要類似互聯網應用一樣的敏捷程度。

其二：傳統企業的業務架構和組織模式是否先進行了重構

對于大部分傳統企業來說，真正困難和難以推行的都是業務組織架構的重組，其次才是IT系統的建設。很多CIO希望通過IT系統建設或者說當前的中臺，微服務來倒逼業務架構重構，往往都是一廂情愿，到最后往往根本推行不下去。

當我們觀察大部分企業的時候，你會看到企業本身的業務架構往往就沒有中臺化。

我們可以舉些常見的例子，比如一個制造企業有多個子公司，你會看到各個子公司本身的財務，供應鏈，售后這些本該業務下沉和集中化的本身就沒有統一。在企業內部業務上就沒有我們經常談到的共享中心的概念。

在業務組織本身就沒有共享化，拆分化的情況下推進中臺往往就是難上加難。

其三：前端應用是否不斷推陳出新

在前面我已經強調了，傳統企業的內部IT往往就是支撐企業核心價值鏈一套業務，最多也就是PC端BS應用和手機端兩種展現模式，但是本質還是一套應用系統。

對于供應鏈核心價值鏈來說根本就不存在要不斷推出新應用的可能。只存在會出現業務流程的情況，而對于新業務流程的出現往往基于傳統SOA架構思路完全可以解決。即將遺留系統接入和適配，將服務能力共享開放即可。

傳統企業什么時候需要一個中臺？

經過上面分析我們可以看到，大部分企業并不需要一個類似互聯網企業一樣的中臺。那么什么時候需要這個中臺呢？

也就是什么時候會出現類似互聯網企業一樣的背景需求。

還是會到前面的分析，簡單來講就是：對于本身就是做C端消費類產品的企業，本身又希望實現對終端用戶的端到端觸達能力，同時營銷價值鏈本身又是完全自建的情況。這種企業往往中臺規劃建設的需求最強烈。

我們也看到當前很多上中臺的企業更多就是屬于上面場景的企業，而且中臺的構建更多的是面向自己的電商平臺，CRM營銷網絡，面向C端的前臺應用需求。

在這種情況下，企業需要去構建一個中臺來滿足前臺應用敏捷化的需求。

也就是說這個企業中臺已經不再是簡單的滿足內部業務系統，內部用戶的使用，而是更多的打破了企業邊界，面向外部的消費者用戶，或者產業鏈上的生態合作伙伴的需求。

在這種場景下，我們就需要對企業內部已有的業務能力進一步包裝和抽取共性，然后將共性能力以API接口服務的方式提供給前臺應用。

其次，就是一個大的集團性企業，本身在進行業務重組，將共性業務能力形成共享中心的方式進行統一的情況下，需要去構建一個中臺。這個也和我們中臺產生背景思路一致。

比如前面談到的，一個生產制造企業，本身有很多子公司或工廠，但是你可以看到企業的供應鏈能力，營銷服務能力，售后服務能力完全是可以共享和復用的，這些業務能力應該進行整合和統一。真正差異化的僅僅是制造各類產品不同的制造單元。

在這種明確的業務驅動和業務整合背景下，往往也是最佳的構建中臺場景。

傳統企業更多的是轉型到平臺+應用構建模式

這里的平臺我們指技術平臺，或者對應到中臺概念里面的技術中臺。這個平臺即我經常說到的私有云PaaS平臺。而私有云PaaS平臺的重點就是將企業內部業務系統構建需要的共性技術服務能力下沉并統一建設。這些共性技術能力包括了中間件，數據庫資源池，也包括了類似4A，流程引擎，消息，緩存，文件，任務調度等共性技術服務能力。

為何平臺建設如此重要？

我們要意識到只有原業務系統中的技術平臺完全下沉并移出，上次的業務系統模塊才能夠實現徹底的組件和微服務化架構。

這個我在前面一篇文章專門談到過，可以參考：

SOA和云計算-企業私有云PaaS平臺建設實踐

同時對應平臺層規劃建設，我們理解重點應該包括：

步驟1:4A和流程平臺的下沉和能力開放

這個是我談的最多的問題，即在實施微服務架構轉型的時候必須將4A（也可先狹義理解為原業務系統的系統管理模塊）和流程引擎下沉到平臺層共性建設，或者說優先要將這兩個模塊作為微服務模塊剝離出來，同時給上層的業務組件模塊提供API服務接口能力。

對于4A模塊剝離后，我們希望的是涉及到人員，組織，用戶，權限等能力的獲取都是通過服務接口實時查詢獲取，這些基礎主數據信息也不要落地。在進行這樣實施的時候確實會增加上層業務系統的改造工作量。對于流程平臺的簽出相對來說比較容易，最主要的還是給業務模塊提供流程啟動，暫停，獲取待辦已辦列表等關系服務接口信息為主。

進行4A和流程平臺的剝離核心目的仍然是是的后續需要進行拆分的業務模塊只包含業務功能，而不再包含共性的技術能力功能。

步驟2：基礎主數據模塊能力獨立建設

這是我們談的第二個重點，即希望將提供共享基礎主數據的功能單獨剝離出來進行獨立建設，比如建設獨立的主數據平臺或叫提供基礎主數據的各個數據中心模塊。然后數據能力以數據服務的方式暴露出去供上層業務系統使用，同樣我們希望上層業務模塊在使用這些基礎主數據的時候最好主數據不落地，實時用實時查。

在傳統PaaS平臺建設中會涉及到MDM主數據平臺的建設，到了徹底的微服務架構可能并不存在主數據平臺的概念，而是各個類似產品中心，供應商中心，客戶中心的各個微主數據中心模塊，這些微服務模塊也是我們常說的中臺的核心數據能力提供中心。

要規劃和建設中臺，首先要考慮的就是這種基礎數據中心，其次才是提供業務支撐和業務邏輯處理的中心。

步驟3：及早進行統一門戶的建設

要注意，在各個微服務模塊建設完成后，單個微服務模塊本身是不能提供支撐完整業務流程的能力。對于用戶來說并不關心是否進行了微服務架構化，而是關心涉及到業務流程處理的功能和操作是否能夠很方便的在一個業務應用里面操作和完成。

而這些業務模塊基于業務流程，基于業務場景和使用部門的組裝和展現，就需要在門戶層完成。對于統一門戶不僅僅是提供統一認證和單點登錄，也還包括了統一的待辦集成和任務處理，統一的消息通知等共性功能能力。也就是說，只要是各個微服務模塊共性的一些需要展現的能力，都可以集中化到統一門戶層去集中處理和展現。

門戶層還有一個重要的功能就是進行微服務模塊的組裝，這些模塊組裝后可以為業務用戶提供完整的端到端業務流程功能支持，讓最終用戶的感覺就是在使用一個系統，沒有系統不停切換的感覺。因此實際上在門戶層不僅僅是簡單的模塊選擇，也還可以做一些展現層的編排和組合工作。

對于微服務模塊的靈活組裝也是相當困難的，因為很多模塊組裝最終都是體現到模塊提供的南北向接口的自動對接，這往往是比對服務組合和服務編排進行定制更加困難，對于這個問題后續單獨進行討論。

已有的IT架構和遺留系統如何構建中臺？

這個估計是大部分企業都會遇到的問題。也是我們經常說的，傳統企業中臺的構建不能完全照搬互聯網企業中臺構建思路，而是需要考慮如何最大化的保護遺留IT資產。

即使企業是需要對外構建完整生態鏈的情況下，也不可能將企業內部已有的IT系統全部完整中臺和微服務的架構思路完全推倒重新建設。

正是這個原因，我們提出一個重點，即：

傳統企業在最大化保留遺留資產情況下，更多應該是適配方式構建一個能力中臺。

在這里我將其稱呼為能力中臺意思就是，這個中臺的服務能力不是全新產生的，而是對遺留IT系統能力的一種適配和聚合形成的。

即能力中臺有點類似于我們傳統在SOA架構下的ESB總線和服務共享平臺建設。

那么這個能力中臺和單純的ESB總線區別在哪里呢？

其中最大的區別就在于這個能力中臺，本身不是簡單的接口服務接入和集成，而是對已有的遺留IT資產，數據庫，接口API等進行了重構，適配，整合和重組，構建了一個滿足新業務構建的完整領域服務能力層提供。

也就是說這個能力中臺本身是可能存在業務代碼和業務邏輯的。

如上面圖所示，在構建新的中臺能力服務層的時候，為了對已有的業務系統影響最小，我們需要重新構建中臺能力接口，這個接口涉及到一定的適配和定制開發工作量。

具體接口的實現本身又包括了三種方式，即：

直接連接遺留系統的數據庫，來重新開發接口服務。

通過遺留系統已有的JAR包引入，來重新開發接口服務。

通過遺留系統已有的WS或Rest等接口服務適配，來重新開發接口服務。

可以看到三種模式中對于數據庫這種模式是對業務系統依賴最小的模式，但是這個模式本身也是需要我們重新進行完整性校驗，業務規則的模式。這種模式本身就可以看到對遺留業務系統的部分業務規則和能力進行了重寫，即這部分業務邏輯規則已經在朝中臺能力層逐步遷移。

這種遷移形成的接口服務能力，一方面是構建全新的業務應用可以使用。而同時，我們建議是及時對于PMS或SCM等業務系統，如果有全新的業務模塊需要開發，也完全可以基于中臺已有的接口服務能力進行，只有這樣才容易實現后續的業務系統逐步遷移到中臺架構上。

數據重構和服務組合是中臺另外一個關鍵能力

在中臺能力構建的時候，一定要考慮數據重構和能力組合。

即中臺的能力接口不是簡單的數據庫CRUD能力暴露，也不是已有的遺留接口的簡單適配和接入。而是真正根據業務流程和業務需求驅動，實現關鍵的業務能力，將業務能力轉變為服務。這種服務本身是粗粒度的，有明確的業務含義，有點類似我們在領域架構設計里面經常談到的領域服務能力。

中臺構建不要盲目的微服務架構化

最后再次強調下，企業中臺的構建不一定要全面微服務化。比如我們前面說的能力中臺建設，更多的是適配已有的資產能力進行重構形成能力開放平臺。

我始終認為：企業業務共性能力下沉，并形成統一服務對前臺提供。

這樣滿足這個目標要求，構建的就是企業中臺，這個中臺是否一定微服務化反而不是重點，只是說微服務化后，整體的解耦，擴展性更強而已。

但是一定要注意到，引入微服務本身對企業IT治理管控水平要求相對高。如果企業本身的IT成熟度沒有達到一定階段，顯然是不可能推行實施微服務架構的。這個道理前面已經談到過，在企業IT建設中，如果連粗粒度的業務系統以及它們之間的集成都管理不好，那么更沒有能力管理細粒度的微服務模塊。

那么如果企業IT成熟度達到一定水平，在推廣微服務架構還存在的難點如下：

首先是架構設計能力的顯性化，即架構設計這個工作的輸入，輸出和過程需要更加的顯性化出來形成團隊都認同的標準工件。一個業務系統沒有拆分開時候，雖然有架構設計和組件劃分，但是這個工作是屬于團隊內部的事情，即使架構設計不合理，在后期集成也可以通過諸多變通方式解決掉。而現在是不同的微服務模塊可能分派到兩個獨立的團隊開發，原來屬于自己內部黑盒的問題變為團隊間問題。

簡單來說你原來藏著或沒做規范的東西太多，而現在這些不能再藏著掖著了，當真要把這些東西拿出來的時候，你才會發現你原來架構能力是有欠缺的。正如我們理解了一個東西，那么要讓我們清楚的講出來困難，那么我們的理解有欠缺。對于我們能講清楚的東西，要系統寫下來有困難，那么說明我們講的結構和條理有欠缺。

其次管控要求和規范體系的建立，對于管控要求可以看到如果兩個微服務模塊分給同一個團隊開發，如何才能保證開發的團隊保持兩個模塊的完全獨立和解耦，兩個模塊間不會出現相互交叉的數據庫直接調用，也不會存在直接繞開Service接口的其它耦合調用？這些如果沒有完整的管控和檢查體系我們很難約束。

微服務架構下導致的開發復雜度增加

只談微服務架構的松耦合和高擴展性，而不談開發和集成復雜度的都是耍流氓。

實際上當前很多企業對微服務架構并沒有如此迫切，互聯網很多企業推行微服務架構更多的還是考慮到巨大的業務并發量下的系統彈性擴展能力，而實際大多數企業內應用往往并沒有如此海量并發。

其次，即使在并發量增加的情況下通過進行代碼本身的優化，數據庫調優或者升級硬件服務器資源都可以較好解決性能問題。而做這些事情投入的成本遠遠小于微服務架構帶來的開發復雜度增加成本，后期的運維管控成本。

要做到完全微服務模塊獨立，微服務架構下最大的一個變化就是數據庫也拆分開了，原來的一個業務系統如果分為5個微服務模塊，那理論上就是5個獨立的后臺數據庫，而且數據庫間還不能隨便相互連接和訪問。只有這樣微服務模塊才能做到獨立部署和管理。

由于數據庫拆分帶來兩個問題，其一是我們原來很簡單的一個跨表查詢操作現在無法做了，我們必須調用兩個微服務模塊提供的服務，查詢到數據后再到邏輯層進行組合。其次最大的問題就是如果一個業務操作需要同時更新兩個微服務模塊的數據，由于服務本身無狀態，導致了這種分布式事務問題很難解決。

企業內業務系統很大一個特點就是業務邏輯和規則相對互聯網更加復雜，而且有更高的事務一致性要求。正是由于這個原因，無法解決好分布式事務的問題都將直接導致后續數據不一致和業務錯誤。

微服務架構下導致的集成復雜度增加

任何一個微服務模塊在外部協同上都存在兩個點，一個是模塊本身要消費和調用其它微服務模塊提供的服務接口，另外一個是模塊本身又需要將其業務能力暴露為服務接口給其它微服務模塊使用。

如果一個微服務模塊要同時支撐PC端和APP端，可以看到微服務模塊暴露的服務還需要統一提供給前端的展示用。那么可以看到一個微服務模塊需要完成自身組件層和展現層間的集成，同時又需要完成多個微服務模塊組件間的橫向服務集成。

如果我們將消息，日志，流程，4A等能力下沉到平臺層微服務模塊，那么一個組件要跑起來還涉及到和平臺層的多個技術類微服務模塊集成。在如此復雜的集成場景下，要將復雜的跨多個微服務模塊的橫向端到端業務跑通，其涉及到的模塊數，接口數都遠超原有單一系統的模式。

一個業務系統如果沒有拆分為微服務模塊，那么其它內的模塊間集成和集成測試是系統內部的事情，但是一旦拆分為多個微服務模塊，那么這種集成就變成外部第三方的事情，或者必須要顯性的事情。集成復雜度會大增，同時系統健壯性和穩定性下降。

微服務架構下的運維問題

在實施了微服務架構后，運維的復雜度也是成倍增加，任何一個微服務模塊出問題都可能影響到整個業務應用的功能使用。我們在運維時候不僅僅要健康單個微服務模塊，還需要健康所有的接口服務監控狀態。

如果跟Docker集成了，我們看到整個性能監控和問題分析都會變麻煩了，沒有實施微服務架構前發現問題，我們直接可以看應用服務器上類似tomcat或jboss日志，而實施了微服務架構后，應用容器已經是自動部署和動態分配的，原有的故障診斷模式行不通，而需要PaaS平臺本身提供完整的預警和日志分析能力。