建站
咨詢
售后
建站咨詢
新聞中心
對于傳統(tǒng)企業(yè)IT架構(gòu)轉(zhuǎn)型，中臺和微服務(wù)架構(gòu)規(guī)劃在我頭條前面的文章里面都有比較系統(tǒng)的整理和闡述，雖然云原生概念在2013年就提出，但是2020年可以算作是云原生的元年，同時企業(yè)IT架構(gòu)轉(zhuǎn)型，微服務(wù)化和逐步遷移上公有云也將是未來多年的一個技術(shù)發(fā)展趨勢。最近結(jié)合和合作伙伴，客戶的溝通交流，對一些常用的問題進行整理和說明。
中臺和微服務(wù)規(guī)劃
對于中臺規(guī)劃實際上可以理解為傳統(tǒng)企業(yè)架構(gòu)和信息化規(guī)劃，傳統(tǒng)SOA架構(gòu)規(guī)劃的一個子集。其核心還是業(yè)務(wù)驅(qū)動IT，基于業(yè)務(wù)流程和業(yè)務(wù)對象梳理分析，識別核心可復(fù)用的業(yè)務(wù)組件和能力。共性業(yè)務(wù)能力下沉，提供粗粒度接口給上層使用。
中臺本身是一個業(yè)務(wù)概念，而非技術(shù)概念。
能做中臺規(guī)劃的不是技術(shù)很牛的新興咨詢公司或軟件服務(wù)商，而是傳統(tǒng)的扎根在某個垂直業(yè)務(wù)領(lǐng)域的傳統(tǒng)咨詢公司或軟件服務(wù)商。即對垂直行業(yè)業(yè)務(wù)理解的深度，傳統(tǒng)的咨詢規(guī)劃能力，遠遠超過技術(shù)能力。
一個新興的企業(yè)到處去給客戶做中臺規(guī)劃，這個是不合適的，沒有業(yè)務(wù)領(lǐng)域的沉淀你如何給別人規(guī)劃中臺，如何識別可重用的業(yè)務(wù)能力。你沒有業(yè)務(wù)積累和沉淀，再好的方法論也無法指導(dǎo)你實踐。雖然我文章里面整理中臺規(guī)劃方法論，同樣我不熟悉的業(yè)務(wù)領(lǐng)域我實際也無法給別人做規(guī)劃。
熟悉一個技術(shù)架構(gòu)思想可能需要1周時間，但是熟悉一個垂直行業(yè)至少需要1年甚至更久。所以做技術(shù)規(guī)劃相對容易，但是做業(yè)務(wù)和中臺規(guī)劃難，其難點不在于方法論，而在于業(yè)務(wù)積累和沉淀。
微服務(wù)-不要將標準僵化
實際上我們在進行微服務(wù)架構(gòu)轉(zhuǎn)型，包括和客戶討論微服務(wù)化的過程中往往出現(xiàn)兩個極端。一種情況是大應(yīng)用應(yīng)用層拆分了，但是數(shù)據(jù)庫還是一個;還有一種情況是嚴格地去做到拆分的微服務(wù)和數(shù)據(jù)庫1對1。
對于第一種情況由于DB沒有拆分，實際上仍然是一個緊耦合的系統(tǒng)。而第二種情況微服務(wù)拆分后導(dǎo)致大量獨立細粒度的數(shù)據(jù)庫實例，進而帶來大量的分布式事務(wù)問題。而實際上更好的做法應(yīng)該是根據(jù)企業(yè)業(yè)務(wù)域的情況進行折中，按業(yè)務(wù)子域來進行數(shù)據(jù)庫拆分，而業(yè)務(wù)子域內(nèi)部的應(yīng)用層，還可以拆分為多個微服務(wù)。
包括在微服務(wù)實施中，經(jīng)常有人會說你的架構(gòu)前后端沒有分離，不是微服務(wù)。而實際上前后端分離同樣不是微服務(wù)的必要條件。
比如有些客戶在實施微服務(wù)的時候，雖然前后端分離，但是后端提供的API接口服務(wù)全部都是細粒度的，同時和前端方法1對1，這樣的前后端分離拆分并沒有體現(xiàn)領(lǐng)域能力，服務(wù)可復(fù)用等關(guān)鍵特性，反而是增加了前后端協(xié)同和聯(lián)調(diào)的復(fù)雜度，這樣的分離沒有意義。
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ù)集成和交付過程的改進，其次才是使用什么樣的工具和技術(shù)。技術(shù)往往很難反推過程優(yōu)化和改進，過程改進需要的是組織，團隊和文化的改進。
大數(shù)據(jù)平臺到數(shù)據(jù)中臺
可以看到，當前很多做數(shù)據(jù)中臺的服務(wù)商實際就是原來做大數(shù)據(jù)平臺的服務(wù)商。那么大數(shù)據(jù)平臺和數(shù)據(jù)中臺究竟有什么樣的區(qū)別?
對于大數(shù)據(jù)平臺你可以理解為一個純粹的數(shù)據(jù)技術(shù)能力平臺，里面本身是空的。就像我們理解ESB總線一樣，本身是一個技術(shù)平臺，一開始沒有接口服務(wù)注冊在上面，需要你自己不斷地接入新的服務(wù)，才能夠形成服務(wù)目錄體系。
而對于數(shù)據(jù)中臺則是基于一個大數(shù)據(jù)平臺的技術(shù)底座填充了具體的數(shù)據(jù)資產(chǎn)，這個數(shù)據(jù)資產(chǎn)需要進行分層，需要進行抽象建模，需要對外提供可復(fù)用數(shù)據(jù)服務(wù)能力。
因此數(shù)據(jù)中臺建設(shè)難點從來不在大數(shù)據(jù)技術(shù)平臺，而在于里面的數(shù)據(jù)建設(shè)，如何對數(shù)據(jù)進行建模，如何采集數(shù)據(jù)，如何清洗數(shù)據(jù)，如何抽象聚合等。而這個同樣又回到了中臺規(guī)劃的關(guān)鍵，即需要業(yè)務(wù)域業(yè)務(wù)能力和經(jīng)驗沉淀，你才能夠做這個事情。
簡單來說如果企業(yè)要做數(shù)據(jù)中臺，新興的很多大數(shù)據(jù)平臺或數(shù)據(jù)中臺廠商不一定靠譜，反而是哪些傳統(tǒng)的垂直領(lǐng)域長期做BI規(guī)劃實施的廠商更值得托付。
從云原生到企業(yè)上云遷移
我在前面談到過，對于阿里，華為和騰訊等公有云廠商，2020年在云原生解決方案，協(xié)助傳統(tǒng)企業(yè)上云上宣傳得很猛，雖然整個云原生是技術(shù)大趨勢，但是企業(yè)一定要意識到從傳統(tǒng)的企業(yè)內(nèi)部IT架構(gòu)遷移上云仍然是一個相對漫長的過程。
特別是企業(yè)已有內(nèi)部私有云或數(shù)據(jù)中心，已經(jīng)有大量遺留IT系統(tǒng)的情況下，在業(yè)務(wù)連續(xù)性保障，如何確保平滑遷移難度極大。
各個公有云廠商都推出自己的遷移方案和計劃，包括自己的DevOps研發(fā)一體化平臺延伸到企業(yè)內(nèi)部，雖然易用性和方便性在增強，但是對企業(yè)的強綁定也在增強。簡單來說你采用了某個公有云服務(wù)商的方案和服務(wù)，實際后面你要脫離是相對困難的事情。
其次，前段時間做了下簡單的比較，即不直接購買虛擬機而是直接購買數(shù)據(jù)庫服務(wù)，發(fā)現(xiàn)整體每年的成本相對高。有時候考慮直接購買云服務(wù)廠商的技術(shù)服務(wù)能力，但是實際上很多時候你仍然需要有運維工程人員，這個成本并沒有省略掉。
同時由于企業(yè)IT系統(tǒng)是逐步遷移的，企業(yè)內(nèi)部私有云和公有云將并存相對長一段時間，包括有些傳統(tǒng)的內(nèi)部IT系統(tǒng)在性能需求，安全性等方面往往并不適合上云，這些都必須考慮清楚。
服務(wù)治理和管控能力
有些企業(yè)盲目地崇拜新技術(shù)，總希望自己在新系統(tǒng)的開發(fā)中采用最新的技術(shù)，最高性能的技術(shù)。但是實際上在后期管控運維上都出現(xiàn)了問題。
對于微服務(wù)而言也一樣，剛開發(fā)的微服務(wù)拆分，接口定義并沒有馬上發(fā)現(xiàn)問題，但是最終到了開發(fā)后期乃至上線的時候才發(fā)現(xiàn)微服務(wù)拆分的太細，微服務(wù)間的接口交互太多。也就是說微服務(wù)拆分后，各個微服務(wù)間仍然是緊耦合狀態(tài)。
系統(tǒng)一上線，發(fā)現(xiàn)整個微服務(wù)環(huán)境完全不在自己的掌控范圍，運行故障問題難解決，日志難以排查，接口變更大量依賴導(dǎo)致上線故障等。這些都是典型的整個IT組織的架構(gòu)能力，服務(wù)管控治理能力跟不上導(dǎo)致的，剛開始用新技術(shù)很爽結(jié)果到后面留一個無法管控的爛攤子下來。
中臺和微服務(wù)
對于中臺構(gòu)建一定要采用微服務(wù)架構(gòu)嗎?
在前面文章也談到過，理想化的中臺構(gòu)建采用微服務(wù)架構(gòu)是最佳的方式。但是中臺的核心是共性業(yè)務(wù)能力下沉并對外提供，能夠支撐上層應(yīng)用快速構(gòu)建。
那么企業(yè)存在大量遺留IT系統(tǒng)的時候，全部推翻原來的微服務(wù)化就不是最佳的方法。更好的方法是圍繞你構(gòu)建的中臺是否提供可復(fù)用的共性業(yè)務(wù)能力為最終衡量標準。如果做到了，企業(yè)就構(gòu)建了很好的中臺。底層是否使用微服務(wù)反而不是關(guān)鍵點。
因此中臺和微服務(wù)雖然緊密結(jié)合，但是實際上沒有必然關(guān)系。
中臺的構(gòu)建可以不采用微服務(wù)，可以采用傳統(tǒng)架構(gòu)，也可以通過對遺留IT系統(tǒng)接口適配的方式來構(gòu)建。而對于微服務(wù)同樣不一定體現(xiàn)中臺特征，微服務(wù)核心仍然是在于傳統(tǒng)大單體的拆分，拆分后的接口服務(wù)可重用性是充分條件而非必要條件。
不要神化低代碼開發(fā)平臺
重新回歸下在2020年技術(shù)發(fā)展，發(fā)現(xiàn)低代碼開發(fā)平臺反而是一個熱點中的熱點，出現(xiàn)了大量的低代碼開發(fā)平臺的廠家和云服務(wù)商。有些是傳統(tǒng)的做BPM類的廠家，也有些是本身就是做快速開發(fā)平臺的廠家，當然還有些完全提供零代碼組裝的平臺。
沒有銀彈說了這么多年，這個短期不會有大改觀。
那么低代碼平臺本身的尷尬點在哪里?
對于中小型企業(yè)來說，需要的并不是低代碼開發(fā)，而是直接的SaaS服務(wù)，對于SaaS服務(wù)產(chǎn)品能夠提供一些靈活的流程，權(quán)限，數(shù)據(jù)項的配置能力足夠。而對于大型的企業(yè)來講，很多業(yè)務(wù)流程和業(yè)務(wù)場景，特別是復(fù)雜的業(yè)務(wù)規(guī)則，低代碼平臺并不能解決。即使解決仍然存在大量的復(fù)雜腳本代碼。
低代碼平臺假設(shè)了每個對象，每個功能相對來說都盡量獨立，但是實際上對于復(fù)雜的業(yè)務(wù)來說對象之間有關(guān)聯(lián)，功能之間有協(xié)同和集成，業(yè)務(wù)邏輯難配置等。這些不是低代碼平臺能夠解決的問題。
如果真要做低代碼開發(fā)平臺，你會看到唯一好的方向是垂直業(yè)務(wù)行業(yè)+業(yè)務(wù)系統(tǒng)。越做到垂直，越容易將可復(fù)用的東西抽象出來提供。也就是說實際是提供了一個垂直行業(yè)+垂直業(yè)務(wù)下的一個業(yè)務(wù)平臺能力，這個才是最有價值的。
分享題目：企業(yè)中臺規(guī)劃和IT架構(gòu)微服務(wù)轉(zhuǎn)型雜談
URL網(wǎng)址：http://m.5511xx.com/article/dpgdgdp.html
