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

中臺和微服務規(guī)劃 

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

中臺本身是一個業(yè)務概念，而非技術概念。

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

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

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

微服務-不要將標準僵化 

實際上我們在進行微服務架構轉(zhuǎn)型，包括和客戶討論微服務化的過程中往往出現(xiàn)兩個極端。一種情況是大應用應用層拆分了，但是數(shù)據(jù)庫還是一個;還有一種情況是嚴格地去做到拆分的微服務和數(shù)據(jù)庫1對1。

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

包括在微服務實施中，經(jīng)常有人會說你的架構前后端沒有分離，不是微服務。而實際上前后端分離同樣不是微服務的必要條件。

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

DevOps首先是過程，其次才是工具集成 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

服務治理和管控能力 

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

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

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

中臺和微服務 

對于中臺構建一定要采用微服務架構嗎?

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

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

因此中臺和微服務雖然緊密結(jié)合，但是實際上沒有必然關系。

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

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

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

沒有銀彈說了這么多年，這個短期不會有大改觀。

那么低代碼平臺本身的尷尬點在哪里?

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

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

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