對(duì)于傳統(tǒng)企業(yè)IT架構(gòu)轉(zhuǎn)型，中臺(tái)和微服務(wù)架構(gòu)規(guī)劃在我頭條前面的文章里面都有比較系統(tǒng)的整理和闡述，雖然云原生概念在2013年就提出，但是2020年可以算作是云原生的元年，同時(shí)企業(yè)IT架構(gòu)轉(zhuǎn)型，微服務(wù)化和逐步遷移上公有云也將是未來(lái)多年的一個(gè)技術(shù)發(fā)展趨勢(shì)。最近結(jié)合和合作伙伴，客戶的溝通交流，對(duì)一些常用的問(wèn)題進(jìn)行整理和說(shuō)明。

中臺(tái)和微服務(wù)規(guī)劃 

對(duì)于中臺(tái)規(guī)劃實(shí)際上可以理解為傳統(tǒng)企業(yè)架構(gòu)和信息化規(guī)劃，傳統(tǒng)SOA架構(gòu)規(guī)劃的一個(gè)子集。其核心還是業(yè)務(wù)驅(qū)動(dòng)IT，基于業(yè)務(wù)流程和業(yè)務(wù)對(duì)象梳理分析，識(shí)別核心可復(fù)用的業(yè)務(wù)組件和能力。共性業(yè)務(wù)能力下沉，提供粗粒度接口給上層使用。

中臺(tái)本身是一個(gè)業(yè)務(wù)概念，而非技術(shù)概念。

能做中臺(tái)規(guī)劃的不是技術(shù)很牛的新興咨詢公司或軟件服務(wù)商，而是傳統(tǒng)的扎根在某個(gè)垂直業(yè)務(wù)領(lǐng)域的傳統(tǒng)咨詢公司或軟件服務(wù)商。即對(duì)垂直行業(yè)業(yè)務(wù)理解的深度，傳統(tǒng)的咨詢規(guī)劃能力，遠(yuǎn)遠(yuǎn)超過(guò)技術(shù)能力。

一個(gè)新興的企業(yè)到處去給客戶做中臺(tái)規(guī)劃，這個(gè)是不合適的，沒(méi)有業(yè)務(wù)領(lǐng)域的沉淀你如何給別人規(guī)劃中臺(tái)，如何識(shí)別可重用的業(yè)務(wù)能力。你沒(méi)有業(yè)務(wù)積累和沉淀，再好的方法論也無(wú)法指導(dǎo)你實(shí)踐。雖然我文章里面整理中臺(tái)規(guī)劃方法論，同樣我不熟悉的業(yè)務(wù)領(lǐng)域我實(shí)際也無(wú)法給別人做規(guī)劃。

熟悉一個(gè)技術(shù)架構(gòu)思想可能需要1周時(shí)間，但是熟悉一個(gè)垂直行業(yè)至少需要1年甚至更久。所以做技術(shù)規(guī)劃相對(duì)容易，但是做業(yè)務(wù)和中臺(tái)規(guī)劃難，其難點(diǎn)不在于方法論，而在于業(yè)務(wù)積累和沉淀。

微服務(wù)-不要將標(biāo)準(zhǔn)僵化 

實(shí)際上我們?cè)谶M(jìn)行微服務(wù)架構(gòu)轉(zhuǎn)型，包括和客戶討論微服務(wù)化的過(guò)程中往往出現(xiàn)兩個(gè)極端。一種情況是大應(yīng)用應(yīng)用層拆分了，但是數(shù)據(jù)庫(kù)還是一個(gè);還有一種情況是嚴(yán)格地去做到拆分的微服務(wù)和數(shù)據(jù)庫(kù)1對(duì)1。

對(duì)于第一種情況由于DB沒(méi)有拆分，實(shí)際上仍然是一個(gè)緊耦合的系統(tǒng)。而第二種情況微服務(wù)拆分后導(dǎo)致大量獨(dú)立細(xì)粒度的數(shù)據(jù)庫(kù)實(shí)例，進(jìn)而帶來(lái)大量的分布式事務(wù)問(wèn)題。而實(shí)際上更好的做法應(yīng)該是根據(jù)企業(yè)業(yè)務(wù)域的情況進(jìn)行折中，按業(yè)務(wù)子域來(lái)進(jìn)行數(shù)據(jù)庫(kù)拆分，而業(yè)務(wù)子域內(nèi)部的應(yīng)用層，還可以拆分為多個(gè)微服務(wù)。

包括在微服務(wù)實(shí)施中，經(jīng)常有人會(huì)說(shuō)你的架構(gòu)前后端沒(méi)有分離，不是微服務(wù)。而實(shí)際上前后端分離同樣不是微服務(wù)的必要條件。

比如有些客戶在實(shí)施微服務(wù)的時(shí)候，雖然前后端分離，但是后端提供的API接口服務(wù)全部都是細(xì)粒度的，同時(shí)和前端方法1對(duì)1，這樣的前后端分離拆分并沒(méi)有體現(xiàn)領(lǐng)域能力，服務(wù)可復(fù)用等關(guān)鍵特性，反而是增加了前后端協(xié)同和聯(lián)調(diào)的復(fù)雜度，這樣的分離沒(méi)有意義。

DevOps首先是過(guò)程，其次才是工具集成 

對(duì)于DevOps，雖然在我前面文章也詳細(xì)說(shuō)明了當(dāng)前的我們規(guī)劃和研發(fā)的DevOps支撐平臺(tái)。但是所有人還是要意識(shí)到DevOps首先是過(guò)程改進(jìn)和優(yōu)化，其次才是工具集成和自動(dòng)化。

比如我們看到一些企業(yè)實(shí)施了CI/CD集成，過(guò)程自動(dòng)化等，但是你會(huì)發(fā)現(xiàn)從用戶需求收集到版本規(guī)劃，到最終的開發(fā)實(shí)現(xiàn)和上線，整個(gè)過(guò)程管理還是很混亂，有了工具仍然出現(xiàn)需求，研發(fā)，測(cè)試人員大量的人工溝通和協(xié)同。那么DevOps實(shí)施的意義何在?

因此，對(duì)于DevOps首先是一種敏捷和持續(xù)集成和交付過(guò)程的改進(jìn)，其次才是使用什么樣的工具和技術(shù)。技術(shù)往往很難反推過(guò)程優(yōu)化和改進(jìn)，過(guò)程改進(jìn)需要的是組織，團(tuán)隊(duì)和文化的改進(jìn)。

大數(shù)據(jù)平臺(tái)到數(shù)據(jù)中臺(tái) 

可以看到，當(dāng)前很多做數(shù)據(jù)中臺(tái)的服務(wù)商實(shí)際就是原來(lái)做大數(shù)據(jù)平臺(tái)的服務(wù)商。那么大數(shù)據(jù)平臺(tái)和數(shù)據(jù)中臺(tái)究竟有什么樣的區(qū)別?

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

而對(duì)于數(shù)據(jù)中臺(tái)則是基于一個(gè)大數(shù)據(jù)平臺(tái)的技術(shù)底座填充了具體的數(shù)據(jù)資產(chǎn)，這個(gè)數(shù)據(jù)資產(chǎn)需要進(jìn)行分層，需要進(jìn)行抽象建模，需要對(duì)外提供可復(fù)用數(shù)據(jù)服務(wù)能力。

因此數(shù)據(jù)中臺(tái)建設(shè)難點(diǎn)從來(lái)不在大數(shù)據(jù)技術(shù)平臺(tái)，而在于里面的數(shù)據(jù)建設(shè)，如何對(duì)數(shù)據(jù)進(jìn)行建模，如何采集數(shù)據(jù)，如何清洗數(shù)據(jù)，如何抽象聚合等。而這個(gè)同樣又回到了中臺(tái)規(guī)劃的關(guān)鍵，即需要業(yè)務(wù)域業(yè)務(wù)能力和經(jīng)驗(yàn)沉淀，你才能夠做這個(gè)事情。

簡(jiǎn)單來(lái)說(shuō)如果企業(yè)要做數(shù)據(jù)中臺(tái)，新興的很多大數(shù)據(jù)平臺(tái)或數(shù)據(jù)中臺(tái)廠商不一定靠譜，反而是哪些傳統(tǒng)的垂直領(lǐng)域長(zhǎng)期做BI規(guī)劃實(shí)施的廠商更值得托付。

從云原生到企業(yè)上云遷移 

我在前面談到過(guò)，對(duì)于阿里，華為和騰訊等公有云廠商，2020年在云原生解決方案，協(xié)助傳統(tǒng)企業(yè)上云上宣傳得很猛，雖然整個(gè)云原生是技術(shù)大趨勢(shì)，但是企業(yè)一定要意識(shí)到從傳統(tǒng)的企業(yè)內(nèi)部IT架構(gòu)遷移上云仍然是一個(gè)相對(duì)漫長(zhǎng)的過(guò)程。

特別是企業(yè)已有內(nèi)部私有云或數(shù)據(jù)中心，已經(jīng)有大量遺留IT系統(tǒng)的情況下，在業(yè)務(wù)連續(xù)性保障，如何確保平滑遷移難度極大。

各個(gè)公有云廠商都推出自己的遷移方案和計(jì)劃，包括自己的DevOps研發(fā)一體化平臺(tái)延伸到企業(yè)內(nèi)部，雖然易用性和方便性在增強(qiáng)，但是對(duì)企業(yè)的強(qiáng)綁定也在增強(qiáng)。簡(jiǎn)單來(lái)說(shuō)你采用了某個(gè)公有云服務(wù)商的方案和服務(wù)，實(shí)際后面你要脫離是相對(duì)困難的事情。

其次，前段時(shí)間做了下簡(jiǎn)單的比較，即不直接購(gòu)買虛擬機(jī)而是直接購(gòu)買數(shù)據(jù)庫(kù)服務(wù)，發(fā)現(xiàn)整體每年的成本相對(duì)高。有時(shí)候考慮直接購(gòu)買云服務(wù)廠商的技術(shù)服務(wù)能力，但是實(shí)際上很多時(shí)候你仍然需要有運(yùn)維工程人員，這個(gè)成本并沒(méi)有省略掉。

同時(shí)由于企業(yè)IT系統(tǒng)是逐步遷移的，企業(yè)內(nèi)部私有云和公有云將并存相對(duì)長(zhǎng)一段時(shí)間，包括有些傳統(tǒng)的內(nèi)部IT系統(tǒng)在性能需求，安全性等方面往往并不適合上云，這些都必須考慮清楚。

服務(wù)治理和管控能力 

有些企業(yè)盲目地崇拜新技術(shù)，總希望自己在新系統(tǒng)的開發(fā)中采用最新的技術(shù)，最高性能的技術(shù)。但是實(shí)際上在后期管控運(yùn)維上都出現(xiàn)了問(wèn)題。

對(duì)于微服務(wù)而言也一樣，剛開發(fā)的微服務(wù)拆分，接口定義并沒(méi)有馬上發(fā)現(xiàn)問(wèn)題，但是最終到了開發(fā)后期乃至上線的時(shí)候才發(fā)現(xiàn)微服務(wù)拆分的太細(xì)，微服務(wù)間的接口交互太多。也就是說(shuō)微服務(wù)拆分后，各個(gè)微服務(wù)間仍然是緊耦合狀態(tài)。

系統(tǒng)一上線，發(fā)現(xiàn)整個(gè)微服務(wù)環(huán)境完全不在自己的掌控范圍，運(yùn)行故障問(wèn)題難解決，日志難以排查，接口變更大量依賴導(dǎo)致上線故障等。這些都是典型的整個(gè)IT組織的架構(gòu)能力，服務(wù)管控治理能力跟不上導(dǎo)致的，剛開始用新技術(shù)很爽結(jié)果到后面留一個(gè)無(wú)法管控的爛攤子下來(lái)。

中臺(tái)和微服務(wù) 

對(duì)于中臺(tái)構(gòu)建一定要采用微服務(wù)架構(gòu)嗎?

在前面文章也談到過(guò)，理想化的中臺(tái)構(gòu)建采用微服務(wù)架構(gòu)是最佳的方式。但是中臺(tái)的核心是共性業(yè)務(wù)能力下沉并對(duì)外提供，能夠支撐上層應(yīng)用快速構(gòu)建。

那么企業(yè)存在大量遺留IT系統(tǒng)的時(shí)候，全部推翻原來(lái)的微服務(wù)化就不是最佳的方法。更好的方法是圍繞你構(gòu)建的中臺(tái)是否提供可復(fù)用的共性業(yè)務(wù)能力為最終衡量標(biāo)準(zhǔn)。如果做到了，企業(yè)就構(gòu)建了很好的中臺(tái)。底層是否使用微服務(wù)反而不是關(guān)鍵點(diǎn)。

因此中臺(tái)和微服務(wù)雖然緊密結(jié)合，但是實(shí)際上沒(méi)有必然關(guān)系。

中臺(tái)的構(gòu)建可以不采用微服務(wù)，可以采用傳統(tǒng)架構(gòu)，也可以通過(guò)對(duì)遺留IT系統(tǒng)接口適配的方式來(lái)構(gòu)建。而對(duì)于微服務(wù)同樣不一定體現(xiàn)中臺(tái)特征，微服務(wù)核心仍然是在于傳統(tǒng)大單體的拆分，拆分后的接口服務(wù)可重用性是充分條件而非必要條件。

不要神化低代碼開發(fā)平臺(tái) 

重新回歸下在2020年技術(shù)發(fā)展，發(fā)現(xiàn)低代碼開發(fā)平臺(tái)反而是一個(gè)熱點(diǎn)中的熱點(diǎn)，出現(xiàn)了大量的低代碼開發(fā)平臺(tái)的廠家和云服務(wù)商。有些是傳統(tǒng)的做BPM類的廠家，也有些是本身就是做快速開發(fā)平臺(tái)的廠家，當(dāng)然還有些完全提供零代碼組裝的平臺(tái)。

沒(méi)有銀彈說(shuō)了這么多年，這個(gè)短期不會(huì)有大改觀。

那么低代碼平臺(tái)本身的尷尬點(diǎn)在哪里?

對(duì)于中小型企業(yè)來(lái)說(shuō)，需要的并不是低代碼開發(fā)，而是直接的SaaS服務(wù)，對(duì)于SaaS服務(wù)產(chǎn)品能夠提供一些靈活的流程，權(quán)限，數(shù)據(jù)項(xiàng)的配置能力足夠。而對(duì)于大型的企業(yè)來(lái)講，很多業(yè)務(wù)流程和業(yè)務(wù)場(chǎng)景，特別是復(fù)雜的業(yè)務(wù)規(guī)則，低代碼平臺(tái)并不能解決。即使解決仍然存在大量的復(fù)雜腳本代碼。

低代碼平臺(tái)假設(shè)了每個(gè)對(duì)象，每個(gè)功能相對(duì)來(lái)說(shuō)都盡量獨(dú)立，但是實(shí)際上對(duì)于復(fù)雜的業(yè)務(wù)來(lái)說(shuō)對(duì)象之間有關(guān)聯(lián)，功能之間有協(xié)同和集成，業(yè)務(wù)邏輯難配置等。這些不是低代碼平臺(tái)能夠解決的問(wèn)題。

如果真要做低代碼開發(fā)平臺(tái)，你會(huì)看到唯一好的方向是垂直業(yè)務(wù)行業(yè)+業(yè)務(wù)系統(tǒng)。越做到垂直，越容易將可復(fù)用的東西抽象出來(lái)提供。也就是說(shuō)實(shí)際是提供了一個(gè)垂直行業(yè)+垂直業(yè)務(wù)下的一個(gè)業(yè)務(wù)平臺(tái)能力，這個(gè)才是最有價(jià)值的。