單體聽上去就很神秘。在數(shù)千個(gè)全球組織中，單體應(yīng)用程序通常是獨(dú)立的，并排的，充滿神秘感而令人敬畏。單體應(yīng)用程序是現(xiàn)代商業(yè)的組成部分，也是每個(gè)關(guān)鍵業(yè)務(wù)流程的重要貢獻(xiàn)者，從后臺到供應(yīng)鏈，從客戶服務(wù)到商業(yè)參與等。

雖然這些單體繼續(xù)為業(yè)務(wù)做出巨大貢獻(xiàn)，但這些應(yīng)用程序的現(xiàn)代化是一個(gè)令人沮喪和痛苦的話題。許多組織放棄了，而其他組織則通過重新定位或重新構(gòu)建，將整個(gè)單體遷移到云上作為權(quán)宜之計(jì)——這是舊的“l(fā)ift and shift”。2022年，新希望、新技術(shù)和新方法正在打破圍繞單體應(yīng)用程序的神秘。

誤解#1：單體現(xiàn)代化是一項(xiàng)失敗的事業(yè)

每個(gè)云提供商、云原生平臺和系統(tǒng)集成商都有一個(gè)模型，該模型幾乎包含現(xiàn)代化詞典中的所有“R”。最初，這個(gè)行業(yè)的現(xiàn)代化只有五個(gè)R：重托管、重構(gòu)、重新架構(gòu)、重建或替換。隨著現(xiàn)代化的成熟和更多顧問的參與，R的數(shù)量也隨之增加，包括重新平臺化、重寫、保留和退役。這令人困惑。幾乎沒有數(shù)據(jù)、數(shù)學(xué)和自動化應(yīng)用于單體的現(xiàn)代化過程。有書籍和最佳實(shí)踐，還有許多顧問和解決方案架構(gòu)師愿意提供建議和交付。這些都是很好的開端，但通常要么專注于DIY方法，要么專注于昂貴、高風(fēng)險(xiǎn)的外包。

新一波的工具、應(yīng)用人工智能和自動化正在應(yīng)用，以彌合所有DIY或所有外包選項(xiàng)之間的差距。這些方法的基礎(chǔ)是基于對單體的實(shí)際架構(gòu)分析，不僅是需要遷移到新版本的底層平臺組件，而且是實(shí)際的業(yè)務(wù)邏輯本身。業(yè)務(wù)邏輯是應(yīng)用程序的核心，架構(gòu)師可以在其中開始識別可以導(dǎo)致更清晰的微服務(wù)領(lǐng)域驅(qū)動設(shè)計(jì)的領(lǐng)域。至少，這些服務(wù)代表的是更獨(dú)立的迷你服務(wù)，或者只是具有更高排他性的普通服務(wù)。缺乏基本的數(shù)據(jù)驅(qū)動方法導(dǎo)致應(yīng)用程序團(tuán)隊(duì)脫離現(xiàn)代化，選擇遷移策略作為權(quán)宜之計(jì)，這導(dǎo)致我們陷入誤區(qū)2。

誤解#2：將單體遷移到云=現(xiàn)代化

將應(yīng)用程序遷移到云是一個(gè)引人注目的目標(biāo)，也是一個(gè)“登月計(jì)劃”愿景，它將IT和應(yīng)用程序團(tuán)隊(duì)凝聚到一個(gè)更大的目標(biāo)上。但要明確的是，遷移并不等于現(xiàn)代化。單體遷移到云，可以獲得巨大的DevOps和數(shù)據(jù)中心縮減好處。幾乎所有組織都實(shí)現(xiàn)了這些短期收益，反過來又為希望加速和簡化企業(yè)工作負(fù)載向云移動的云提供商帶來了意外之財(cái)。許多技術(shù)領(lǐng)導(dǎo)者犯的錯(cuò)誤是認(rèn)為他們的工作已經(jīng)完成了——我們現(xiàn)在已經(jīng)現(xiàn)代化了!

這個(gè)誤解很快就破滅了：現(xiàn)在大多數(shù)組織都清楚，云中的單體存在著與內(nèi)部部署相同的棘手問題——工程速度慢、缺乏可擴(kuò)展性、難以維護(hù)和低可持續(xù)性。隨著成本開始上升，云效益仍然遙不可及，許多人稱這一階段為“l(fā)ift-and-shift后悔”或“遷移后悔”。

要打破這一誤解，必須在更大、更具戰(zhàn)略性的現(xiàn)代化戰(zhàn)略的背景下看待和規(guī)劃遷移問題——只要是邁向全面現(xiàn)代化的基石，遷移就沒問題。單體的現(xiàn)代化使其能夠充分利用云原生架構(gòu)的價(jià)值，從容器和微服務(wù)到Kubernetes和無服務(wù)器。再加上利用常見CI/CD、安全性和DevSecOps策略和平臺的好處，你的業(yè)務(wù)案例就會很快到位，這讓我們陷入誤解3。

誤解#3：構(gòu)建準(zhǔn)確的應(yīng)用程序現(xiàn)代化業(yè)務(wù)用例是不可能的

對于大多數(shù)組織來說，應(yīng)用程序現(xiàn)代化最困難的部分是為現(xiàn)代化項(xiàng)目構(gòu)建準(zhǔn)確的業(yè)務(wù)用例。我們探討了誤解#1中解決此問題所缺少的元素之一：預(yù)測時(shí)間和精力的架構(gòu)師與批準(zhǔn)預(yù)算和資源的業(yè)務(wù)領(lǐng)導(dǎo)之間缺乏數(shù)據(jù)驅(qū)動的討論基礎(chǔ)。由于缺乏共同的語言和衡量基礎(chǔ)，領(lǐng)導(dǎo)層和管理層之間的信任出現(xiàn)了雙向破裂。打破這種循環(huán)需要數(shù)據(jù)和測量才能開始。

從分析測量單體的復(fù)雜性和改變整體所涉及的風(fēng)險(xiǎn)開始。要理解復(fù)雜性，首先需要識別社區(qū)或依賴關(guān)系集群，這表明哪些領(lǐng)域是明顯的，因此可以提取微服務(wù)。然后，可以通過類依賴關(guān)系在它們之間糾纏的程度來計(jì)算復(fù)雜性，從而降低代碼的模塊化水平。風(fēng)險(xiǎn)可以通過依賴關(guān)系鏈的長度來衡量，依賴關(guān)系鏈的長度決定了應(yīng)用程序某個(gè)部分的更改對應(yīng)用程序下游不相關(guān)部分的影響程度。所有這些都可以匯總成一個(gè)總體技術(shù)債務(wù)分?jǐn)?shù)，該分?jǐn)?shù)可以顯示當(dāng)前在債務(wù)與創(chuàng)新方面的支出，從而顯示現(xiàn)代化項(xiàng)目的ROI和TCO業(yè)務(wù)用例效益。從這一強(qiáng)有力的量化立場來看，業(yè)務(wù)優(yōu)先級更容易達(dá)成一致，這導(dǎo)致我們打破了誤解#4。

誤解#4：所有的單體都是平等的

單體有各種形狀和大小，具有不同的商業(yè)價(jià)值和截然不同的復(fù)雜性。事實(shí)上，單體架構(gòu)可以是各種用例的相關(guān)現(xiàn)代設(shè)計(jì)模型。簡單的第一步是根據(jù)今天的業(yè)務(wù)價(jià)值對單體進(jìn)行堆疊排序。評估它們的業(yè)務(wù)實(shí)用性和工程負(fù)載、功能積壓和維護(hù)成本。通常，這些應(yīng)該是一致的，因?yàn)閳F(tuán)隊(duì)的規(guī)模、待辦事項(xiàng)功能的數(shù)量和維護(hù)成本應(yīng)該與企業(yè)單體的業(yè)務(wù)價(jià)值一致。事實(shí)上，這些單體抵制“傳統(tǒng)”標(biāo)簽，因?yàn)樗鼈內(nèi)匀皇瞧髽I(yè)和支持它們的工程團(tuán)隊(duì)的一等公民。一個(gè)不斷老化、業(yè)務(wù)價(jià)值不斷下降的單體，是簡單重組或最終退休的絕佳選擇。

如果應(yīng)用程序仍然是可行的業(yè)務(wù)貢獻(xiàn)者，那么就必須全面評估其復(fù)雜性以及與現(xiàn)代化相關(guān)的風(fēng)險(xiǎn)(參見誤解#3)，以制定最佳計(jì)劃，從而制定更準(zhǔn)確的業(yè)務(wù)用例。通過計(jì)算這些關(guān)鍵業(yè)務(wù)單元的復(fù)雜性、風(fēng)險(xiǎn)和由此產(chǎn)生的技術(shù)債務(wù)，你可以使用基于AI的自動化工具將較不復(fù)雜的部分轉(zhuǎn)移到更快的應(yīng)用程序現(xiàn)代化項(xiàng)目中，以加速該過程。更復(fù)雜的單體(通常稱為“megaliths”)將需要更多的時(shí)間，應(yīng)該遵循更迭代的重構(gòu)方法，使用扼殺模式將控制從單體切換到新服務(wù)，一次有選擇地提取一個(gè)或兩個(gè)微服務(wù)。這些單片應(yīng)用程序可以存在于任何地方，甚至在云中。

誤解#5：單體是一個(gè)內(nèi)部問題

誠然，今天的大部分單體仍然存在于內(nèi)部，牢固地固定在其原有的基礎(chǔ)設(shè)施上。但越來越多的單體已成功遷移到云，在云提供商的IaaS基礎(chǔ)設(shè)施中運(yùn)行，使用提供商的電源、CPU和內(nèi)存，但不幸的是，它們?nèi)匀蛔鳛閱误w運(yùn)行。云中的這些單體可能會成功運(yùn)行一段時(shí)間，但當(dāng)出現(xiàn)可伸縮性問題時(shí)，唯一的解決方案是以越來越多的費(fèi)用購買越來越大的鏡像——更多的CPU和更多的內(nèi)存。這些可能需要更昂貴的保留實(shí)例，云工程師必須始終在紅線級別上運(yùn)行這些實(shí)例——沒有彈性，沒有橫向可擴(kuò)展性。

上述相同的數(shù)據(jù)驅(qū)動評估方法和優(yōu)先級劃分方法與云中的這些單體完全相關(guān)，甚至可能更相關(guān)。為什么?數(shù)據(jù)驅(qū)動的評估、支持人工智能的現(xiàn)代化和遷移后重構(gòu)是所有解決方案和軟件架構(gòu)師所需的關(guān)鍵能力。云中的單體離完全實(shí)現(xiàn)其現(xiàn)代化命運(yùn)如此之近。一旦單體重構(gòu)過程完成，容器、Kubernetes、DevOps、無服務(wù)器和服務(wù)網(wǎng)格服務(wù)就可以在云上啟動。

誤解#6：單體依賴關(guān)系無法解開

承擔(dān)維護(hù)任務(wù)的架構(gòu)師面臨著嚴(yán)峻的挑戰(zhàn)，更不用說在他們的責(zé)任下對單體進(jìn)行現(xiàn)代化改造了。大多數(shù)時(shí)候，他們不是最初的架構(gòu)師或開發(fā)人員，即使他們是，單體也會隨著時(shí)間的推移而發(fā)展，承擔(dān)越來越多的技術(shù)債務(wù)，這可能會埋葬大部分的原始意圖。這些錯(cuò)綜復(fù)雜的單體有很多相似之處。

AI可以提供幫助。當(dāng)一個(gè)系統(tǒng)可以將單體的深度依賴關(guān)系表示為一個(gè)圖形時(shí)，圖形機(jī)器學(xué)習(xí)可以檢測到形成潛在領(lǐng)域活動社區(qū)的集群和鏈接，這帶來了一系列好處，從了解復(fù)雜性和變化風(fēng)險(xiǎn)到實(shí)際檢測潛在的微服務(wù)和社區(qū)之間的邊界。構(gòu)建支持它的圖形和模型需要?jiǎng)討B(tài)和靜態(tài)分析的結(jié)合，但最終的結(jié)果是更加高效和有效的現(xiàn)代化工作。單體現(xiàn)代化成為可能，它們可以變得更加可預(yù)測和更快。

誤解#7：單體現(xiàn)代化永遠(yuǎn)做不完

在打破了上述六個(gè)誤解之后，應(yīng)該清楚的是，如果你遵循這些建議，時(shí)間和預(yù)算應(yīng)該不會成為現(xiàn)代化的一個(gè)因素?，F(xiàn)在，討論的應(yīng)該是實(shí)現(xiàn)哪些現(xiàn)代化，從而帶來業(yè)務(wù)效益和成果。清晰的評估和數(shù)據(jù)驅(qū)動的規(guī)劃也應(yīng)該塑造實(shí)現(xiàn)現(xiàn)代化的方式。復(fù)雜度較高的應(yīng)用程序應(yīng)該遵循迭代的、選擇性的重構(gòu)策略，在這種策略中，不太復(fù)雜的業(yè)務(wù)關(guān)鍵型整體可以更快地通過流程。

在過去十年中，應(yīng)用程序現(xiàn)代化一直是一種人力密集型最佳實(shí)踐，需要廣泛的培訓(xùn)和文化、組織變革。這些實(shí)踐都是關(guān)鍵技能，但由于缺乏自動化和支持工具，由于技能差距和故障疲勞，這一過程已放緩到停滯狀態(tài)。這里有一些新的工具，它們采用這些方法，并通過人工智能和自動化將它們提升到新的水平。下一步是部署一種持續(xù)現(xiàn)代化方法，該方法插入CI/CD管道，并在應(yīng)用程序的整個(gè)生命周期中檢測和修復(fù)技術(shù)債務(wù)。