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

中臺和微服務規劃 

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

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

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

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

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

微服務-不要將標準僵化 

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

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

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

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

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

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

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

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

大數據平臺到數據中臺 

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

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

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

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

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

從云原生到企業上云遷移 

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

特別是企業已有內部私有云或數據中心，已經有大量遺留IT系統的情況下，在業務連續性保障，如何確保平滑遷移難度極大。

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

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

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

服務治理和管控能力 

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

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

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

中臺和微服務 

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

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

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

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

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

不要神化低代碼開發平臺 

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

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

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

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

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

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