當(dāng)單體系統(tǒng)越來越大，并難于維護(hù)時(shí)，很多企業(yè)開始有意把單體系統(tǒng)拆分為微服務(wù)風(fēng)格架構(gòu)。這么做很有意義，但不容易。要做好這件事情我們必須學(xué)習(xí)，我們從一個(gè)簡(jiǎn)單的服務(wù)開始，另一方面拉出以垂直功能為基礎(chǔ)的服務(wù)，這些功能對(duì)業(yè)務(wù)來說很重要并且經(jīng)常變更。這些服務(wù)首先要很大并且最好不要依賴剩余的單體系統(tǒng)。我們應(yīng)該確保每一步遷移對(duì)于整體架構(gòu)而已是一個(gè)原子改進(jìn)。

---

遷移巨型單體系統(tǒng)到微服務(wù)生態(tài)系統(tǒng)是一個(gè)史詩(shī)性任務(wù)。從事這項(xiàng)任務(wù)的人擁有增加經(jīng)營(yíng)規(guī)模、促進(jìn)變化、避免變更帶來的高開銷的意愿。他們想要增加他們的團(tuán)隊(duì)規(guī)模同時(shí)讓團(tuán)隊(duì)以并行的方式傳輸價(jià)值并彼此獨(dú)立。他們想要快速實(shí)驗(yàn)他們的業(yè)務(wù)核心功能并且更快的傳遞價(jià)值。他們同時(shí)要避免關(guān)于變更現(xiàn)存單體系統(tǒng)高昂的開銷。

決定解耦何種功能、何時(shí)、如何逐步遷移以分解單體系統(tǒng)到微服務(wù)生態(tài)是架構(gòu)的挑戰(zhàn)。在這篇文章里，我分享一些技術(shù)以引導(dǎo)交付團(tuán)隊(duì)（開發(fā)者、架構(gòu)師、技術(shù)經(jīng)理）使用這些技術(shù)在過程中做出拆分決定。

微服務(wù)生態(tài)系統(tǒng)目標(biāo)

在開始之前，大家對(duì)微服務(wù)生態(tài)系統(tǒng)達(dá)成共識(shí)是關(guān)鍵。微服務(wù)生態(tài)系統(tǒng)是一個(gè)服務(wù)平臺(tái)，每一個(gè)服務(wù)封裝一個(gè)業(yè)務(wù)功能。一個(gè)業(yè)務(wù)功能代表業(yè)務(wù)在特殊領(lǐng)域可以做什么（實(shí)現(xiàn)目標(biāo)和責(zé)任）。每個(gè)微服務(wù)暴露一個(gè) API，以便開發(fā)者發(fā)現(xiàn)并用于自托管模式。微服務(wù)擁有獨(dú)立的生命周期。開發(fā)者可以獨(dú)立開發(fā)、構(gòu)建、測(cè)試和發(fā)布。微服務(wù)生態(tài)系統(tǒng)實(shí)施長(zhǎng)期自治的團(tuán)隊(duì)組織架構(gòu)，每個(gè)團(tuán)隊(duì)負(fù)責(zé)一個(gè)或多個(gè)服務(wù)。與大多數(shù)看法相反，微服務(wù)中的“微”和服務(wù)大小幾乎沒有關(guān)系，而依賴于運(yùn)營(yíng)成熟的組織架構(gòu)而改變（運(yùn)營(yíng)成熟的組織架構(gòu)決定微服務(wù)）。

過程介紹

在深入介紹之前，了解分解現(xiàn)有系統(tǒng)到微服務(wù)會(huì)產(chǎn)生很高的總體成本（并且可能產(chǎn)生很多迭代）是很重要的。對(duì)于開發(fā)者和架構(gòu)師來說密切的評(píng)估是否分解現(xiàn)有系統(tǒng)是正確的道路、微服務(wù)是否是正確的目的地。

通過一個(gè)簡(jiǎn)單的解耦功能熱身

開始微服務(wù)需要一個(gè)最低層次的程序準(zhǔn)備。它需要訪問部署環(huán)境，構(gòu)建新的類型的 CD 管道以獨(dú)立構(gòu)建、測(cè)試、部署執(zhí)行服務(wù)，以及安全性能力，調(diào)試和監(jiān)控一個(gè)分布式架構(gòu)。準(zhǔn)備程序就緒成熟化是必須的，無論我們是否構(gòu)建綠地服務(wù)或者分解已有系統(tǒng)。

我的建議是開發(fā)和運(yùn)維團(tuán)隊(duì)構(gòu)建底層基礎(chǔ)設(shè)施、持續(xù)交付管道和 API 管理系統(tǒng)，并分解或構(gòu)建第一個(gè)和第二個(gè)服務(wù)。從分解一個(gè)單體系統(tǒng)的功能開始，這個(gè)功能相對(duì)目前的單體系統(tǒng)來說不需要變更很多客戶端接口應(yīng)用程序，也不需要數(shù)據(jù)存儲(chǔ)。交付團(tuán)隊(duì)的優(yōu)化點(diǎn)是驗(yàn)證他們的交付渠道，升級(jí)團(tuán)隊(duì)的技能，構(gòu)建最小基礎(chǔ)設(shè)施以交付部署安全服務(wù)以暴露自托管服務(wù)。做為示例，一個(gè)在線零售應(yīng)用程序，第一個(gè)服務(wù)是“終端用戶認(rèn)證”服務(wù)，單體服務(wù)請(qǐng)求以認(rèn)證終端用戶，第二個(gè)服務(wù)是“客戶檔案”服務(wù)，一個(gè)外觀服務(wù)為客戶提供更好的客戶視圖。

首先我推薦解耦簡(jiǎn)單的邊緣服務(wù)。下一步我們采用不同的方式解耦深度嵌入的單體系統(tǒng)。我建議先做邊緣服務(wù)是因?yàn)樵陂_始之初，交付團(tuán)隊(duì)最大的風(fēng)險(xiǎn)是合理的運(yùn)維微服務(wù)。所以使用邊緣服務(wù)體驗(yàn)運(yùn)維很有好處。一旦他們定位到問題，他們就可以定位到分離單體服務(wù)的關(guān)鍵問題。

最小化對(duì)單體的依賴

交付團(tuán)隊(duì)的基本原則是最小化新的微服務(wù)對(duì)單體系統(tǒng)的依賴。微服務(wù)的主要好處是快速獨(dú)立的發(fā)布閉體系。依賴單體系統(tǒng)的數(shù)據(jù)、邏輯、API，耦合服務(wù)到單體系統(tǒng)的發(fā)布體系，禁止使用單體系統(tǒng)的好處。通常從單體系統(tǒng)架構(gòu)跑路的主要?jiǎng)訖C(jī)是由于高昂的代價(jià)和封裝在單體系統(tǒng)中功能的緩慢變化，所以我們要緩緩的朝單體系統(tǒng)解耦核心功能的方向移動(dòng)。如果團(tuán)隊(duì)按照這篇文章的指導(dǎo)來為他們的微服務(wù)增加功能，那么他們會(huì)發(fā)現(xiàn)從單體系統(tǒng)到服務(wù)的替換、依賴的反轉(zhuǎn)。這是理想的依賴方向，因?yàn)樗粫?huì)放慢變更服務(wù)的步伐。

考慮一個(gè)在線零售系統(tǒng)，“購(gòu)買”和“促銷活動(dòng)”是核心功能。在結(jié)賬過程中，“購(gòu)買”使用“促銷活動(dòng)”給顧客提供最好的促銷活動(dòng)。如果要決定下一步解耦這兩個(gè)功能里的哪一個(gè)，我建議先開始解耦“促銷活動(dòng)”然后才是“購(gòu)買”。因?yàn)樵谶@個(gè)順序下我們減少里對(duì)單體系統(tǒng)的依賴。在這個(gè)順序下，“購(gòu)買”繼續(xù)鎖在單體系統(tǒng)中，依賴外部的新的“促銷活動(dòng)”微服務(wù)。

下一步本文將使用其它方式?jīng)Q定解耦服務(wù)。這意味著這些服務(wù)不是總是能避開對(duì)單體系統(tǒng)的依賴。如果一個(gè)新的服務(wù)最終回調(diào)到單體服務(wù)，我建議從單體系統(tǒng)中暴露一個(gè)新的 API，新的服務(wù)通過反腐層訪問 API 以確保單體系統(tǒng)的概念不泄漏。力爭(zhēng)定義的 API 對(duì)于領(lǐng)域概念和結(jié)構(gòu)有良好的反映，即便單體系統(tǒng)的內(nèi)部實(shí)現(xiàn)不是那樣的。在這個(gè)不幸的案例中，交付團(tuán)隊(duì)將承擔(dān)改變單體系統(tǒng)的開銷和困難，即測(cè)試、發(fā)布新的服務(wù)和單體系統(tǒng)發(fā)布耦合。

盡早分離黏性功能

假設(shè)交付團(tuán)隊(duì)已經(jīng)開始構(gòu)建微服務(wù)并且準(zhǔn)備進(jìn)攻黏性問題。然而他們可能會(huì)發(fā)現(xiàn)他們能力有限，使下一個(gè)解耦的功能不依賴于單體系統(tǒng)。根本原因是通常是單體系統(tǒng)功能泄漏，定義的領(lǐng)域概念不好，有很多單體系統(tǒng)功能依賴于它。為了能處理這個(gè)問題，開發(fā)者需要辨別黏性功能，把它解構(gòu)為定義良好的領(lǐng)域模型然后把這些領(lǐng)域概念實(shí)現(xiàn)到隔離的服務(wù)中。

例如 Web 單體系統(tǒng)，“session” 是最為常見的耦合因素之一。在在線零售示例中，session 通常是很多特性的封裝，從用戶的偏好（不同的領(lǐng)域邊界，比如：配送和支付偏好）到用戶的意圖和交互（比如：最近訪問的頁(yè)面、點(diǎn)擊的產(chǎn)品和購(gòu)買清單）。若非我們處理解耦、解構(gòu)和具體化當(dāng)前 session 的概念，我們將陷入解耦功能（這些功能通過泄漏的 session 概念纏住單體系統(tǒng)）的競(jìng)爭(zhēng)中。同時(shí)我也不鼓勵(lì)在單體系統(tǒng)外創(chuàng)建 session 服務(wù)，因?yàn)樗鼤?huì)導(dǎo)致和單體系統(tǒng)進(jìn)程中類似的緊耦合，更糟糕的是，在進(jìn)程外和跨網(wǎng)絡(luò)。

開發(fā)者可以逐步從黏性功能中抽取微服務(wù)，每次一個(gè)服務(wù)。例如，先重構(gòu)“顧客愿望清單”并抽取到一個(gè)新的服務(wù)中，然后重構(gòu)“顧客支付偏好”到另一個(gè)服務(wù)中。

垂直解耦，盡早釋放數(shù)據(jù)

從單體系統(tǒng)中解耦功能的主要驅(qū)動(dòng)是可以獨(dú)立發(fā)布它們。這是開發(fā)者在解耦過程中做每一個(gè)決定的首要原則。一個(gè)單體系統(tǒng)通常由緊密集成層，甚至幾個(gè)系統(tǒng)組成（需要發(fā)布在一起并且有脆弱的相互依賴關(guān)系）。例如，在一個(gè)在線零售系統(tǒng)中，單體系統(tǒng)由一個(gè)或幾個(gè)面向顧客的在線購(gòu)物應(yīng)用程序組成，一個(gè)后端系統(tǒng)實(shí)現(xiàn)很多業(yè)務(wù)功能（包含一個(gè)集中的數(shù)據(jù)存儲(chǔ)）。

大多數(shù)解耦嘗試從抽取面向用戶組件、幾個(gè)外觀服務(wù)為 UI 提供友好的開發(fā) API開始，同時(shí)數(shù)據(jù)仍然鎖在同一個(gè) schema 中。雖然這種方式在一些方面立竿見影，比如更加頻繁的變更 UI，當(dāng)涉及到核心功能時(shí)，交付團(tuán)隊(duì)只能按照最慢的部分步伐，單體系統(tǒng)和它的巨大數(shù)據(jù)存儲(chǔ)。簡(jiǎn)單的說，不解耦數(shù)據(jù)，架構(gòu)就不是微服務(wù)。所有數(shù)據(jù)在同一個(gè)存儲(chǔ)中與微服務(wù)去中心化數(shù)據(jù)管理的特征背道而馳。

策略是垂直移除功能，解耦核心功能和它的數(shù)據(jù)，并重定向所有前端應(yīng)用程序到新的 API。

有多個(gè)應(yīng)用程序從中心共享數(shù)據(jù)讀寫是服務(wù)解耦數(shù)據(jù)的主要障礙。交付團(tuán)隊(duì)需要納入一個(gè)數(shù)據(jù)遷移策略，這個(gè)策略適配他們的環(huán)境依賴，無論他們是否同時(shí)重定向和遷移所有數(shù)據(jù)讀寫者。四段數(shù)據(jù)遷移策略是其中一種適應(yīng)很多環(huán)境（需要逐步遷移集成數(shù)據(jù)庫(kù)的應(yīng)用程序，同時(shí)所有系統(tǒng)在變更下需要繼續(xù)運(yùn)行）的策略。

解耦對(duì)業(yè)務(wù)重要和頻繁變更的部分

從單體系統(tǒng)中解耦功能不容易。在在線零售應(yīng)用程序中，抽取一個(gè)功能需要仔細(xì)抽取功能的數(shù)據(jù)、邏輯、面向用戶的組件然后重定向它們到新的服務(wù)。因?yàn)檫@是一堆重要的工作，開發(fā)者需要持續(xù)評(píng)估解耦得到的好處，比如：跑的更快或者增加規(guī)模。例如，如果交付團(tuán)隊(duì)的目標(biāo)是加速修改已經(jīng)鎖在單體系統(tǒng)中的功能，那么他們必須確定修改最多的功能。解耦代碼中持續(xù)經(jīng)受修改的部分（這部分代碼持續(xù)得到開發(fā)者的關(guān)注，并最大限度限制了開發(fā)者快速交付成功）。交付團(tuán)隊(duì)可以分析代碼提交模型找出歷史上變化最大的內(nèi)容，并將其與產(chǎn)品路線圖和產(chǎn)品組合進(jìn)行疊加，以了解在不久的將來會(huì)受到關(guān)注的最需要的功能。他們需要和業(yè)務(wù)、產(chǎn)品經(jīng)理溝通以了解對(duì)他們來說重要的功能差異。

例如在一個(gè)在線零售系統(tǒng)中，“顧客個(gè)性化”是一個(gè)功能，該功能要進(jìn)行大量的實(shí)驗(yàn)以為顧客提供最好的體驗(yàn)，并且也是一個(gè)好的解耦候選項(xiàng)。它是一個(gè)對(duì)業(yè)務(wù)很重要的功能，用戶體驗(yàn)，并且頻繁被修改。

解耦功能，不是代碼

無論何時(shí)，開發(fā)者們要從一個(gè)現(xiàn)存系統(tǒng)中抽出一個(gè)服務(wù)，他們有兩種方式：抽取代碼或者重寫功能。

通常情況下，服務(wù)抽取或者單體系統(tǒng)解構(gòu)默認(rèn)假設(shè)為重用已有的實(shí)現(xiàn)，原樣抽取到一個(gè)分離的服務(wù)中。部分原因是我們對(duì)我們?cè)O(shè)計(jì)、編寫的代碼有一個(gè)認(rèn)知偏見。建筑（沒錯(cuò)，這里就是建筑，這里借助 IKEA Effect 理論）過程讓我們對(duì)它產(chǎn)生熱愛，無論這個(gè)過程多么痛苦，結(jié)果多么不完美。不幸的是這種偏見將阻礙單體系統(tǒng)解構(gòu)的努力。它引發(fā)開發(fā)者們和更多的重要技術(shù)管理者不理會(huì)高開銷和低價(jià)值的抽取和重用代碼。

交付團(tuán)隊(duì)可以選擇重寫功能然后讓老代碼淘汰。重寫給了他們機(jī)會(huì)重新訪問業(yè)務(wù)功能，和業(yè)務(wù)開始一個(gè)新的談話，簡(jiǎn)化遺留的過程和挑戰(zhàn)隨著時(shí)間推移建在系統(tǒng)中老的假設(shè)和限制。它同樣提供了一個(gè)刷新技術(shù)的機(jī)會(huì)，使用最合適的一門編程語(yǔ)言和技術(shù)棧實(shí)現(xiàn)一個(gè)新的服務(wù)。

例如在零售系統(tǒng)中，“定價(jià)和促銷活動(dòng)”功能是一段邏輯復(fù)雜的代碼。它啟用動(dòng)態(tài)配置和應(yīng)用程序定價(jià)、促銷活動(dòng)規(guī)則，提供折扣（在各種參數(shù)的基礎(chǔ)上，比如：客戶行為、忠誠(chéng)度、產(chǎn)品包等）。

這個(gè)功能可以說是一個(gè)很好的重用和抽取的候選項(xiàng)。相反，“顧客文檔”是一個(gè)簡(jiǎn)單的 CRUD 功能，通常由樣板代碼組成（序列化、處理存儲(chǔ)和配置），因此，它是重寫和淘汰代碼的候選項(xiàng)。

在我看來，在大多數(shù)解構(gòu)場(chǎng)景中，團(tuán)隊(duì)最好重寫功能到一個(gè)新的服務(wù)中，并且淘汰老的代碼。這里考慮高開銷和低價(jià)值的重用，因?yàn)橐韵聨讉€(gè)原因：

• 有大量的模版代碼要處理環(huán)境依賴，比如在運(yùn)行時(shí)訪問應(yīng)用程序配置、訪問數(shù)據(jù)存儲(chǔ)、緩存并且構(gòu)建于老的框架。大多數(shù)模版代碼需要重寫。新的基礎(chǔ)設(shè)施要托管一個(gè)微服務(wù)和幾十年應(yīng)用程序運(yùn)行時(shí)有很大的不同，并且需要不同種類的模版代碼。

• 很有可能存在的功能不是構(gòu)建于清晰的領(lǐng)域概念。導(dǎo)致傳輸或者存儲(chǔ)數(shù)據(jù)結(jié)構(gòu)不能反映新的領(lǐng)域模型和需要忍受一個(gè)大的重組。

• 一個(gè)長(zhǎng)時(shí)間存在的遺留代碼經(jīng)歷過很多迭代，導(dǎo)致很高的代碼毒性級(jí)別和重用價(jià)值低。

除非能力是相關(guān)的，與清晰的領(lǐng)域概念保持一致并且具有很高的知識(shí)產(chǎn)權(quán)，否則我強(qiáng)烈建議重寫和淘汰舊代碼。

先微服務(wù)，然后再劃分的更小

在遺留單體系統(tǒng)中尋找領(lǐng)域邊界既是藝術(shù)也是科學(xué)。通常應(yīng)用領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)技術(shù)查找邊界上下文定義微服務(wù)邊界是一個(gè)好的開始。我承認(rèn)，我經(jīng)?？吹綇木薮蟮膯误w系統(tǒng)到真正的小服務(wù)的過度修正，真正的小服務(wù)的設(shè)計(jì)是由于受到存在規(guī)范化的數(shù)據(jù)視圖的鼓勵(lì)和驅(qū)動(dòng)。這種方式確認(rèn)服務(wù)邊界導(dǎo)致寒武紀(jì)爆發(fā)大量的貧血服務(wù)（CRUD 資源）。對(duì)于微服務(wù)架構(gòu)新手來說，這會(huì)創(chuàng)建一個(gè)高摩擦環(huán)境，最終無法通過獨(dú)立發(fā)布和執(zhí)行服務(wù)的測(cè)試。它創(chuàng)建了一個(gè)難于調(diào)試的分布式系統(tǒng)，一個(gè)分布式系統(tǒng)打碎了事務(wù)邊界，因此難以保持一致性，對(duì)于組織的運(yùn)營(yíng)成熟度而言過于復(fù)雜的系統(tǒng)。雖然有一些如何“微”微服務(wù)的啟發(fā)式：團(tuán)隊(duì)大小、重寫服務(wù)的時(shí)間、要封裝多少行為等等。我的建議是大小依賴于有多少服務(wù)交付，多少服務(wù)運(yùn)維團(tuán)隊(duì)可以獨(dú)立發(fā)布、監(jiān)控和操作。從圍繞邏輯領(lǐng)域概念的大型服務(wù)開始，并在團(tuán)隊(duì)準(zhǔn)備就緒時(shí)將服務(wù)分解為多個(gè)服務(wù)。

例如，在解耦零售系統(tǒng)的過程中，開發(fā)者可能開始于服務(wù)“購(gòu)買”，這個(gè)服務(wù)封裝了“購(gòu)物袋”，功能是購(gòu)物和購(gòu)物袋（也就是買單）。隨著他們組建更小團(tuán)隊(duì)和發(fā)布更多服務(wù)的能力的增長(zhǎng)，他們可以將購(gòu)物袋與結(jié)帳分離成單獨(dú)的服務(wù)。

以原子進(jìn)化步驟遷移

通過將一個(gè)遺留的單體系統(tǒng)解耦成設(shè)計(jì)精美的微服務(wù)而讓它消失的想法在某種程度上是一個(gè)神話，可以說是不可取的。任何經(jīng)驗(yàn)豐富的工程師都可以分享遺留遷移和現(xiàn)代化嘗試的故事，這些嘗試是在對(duì)完全完成過于樂觀的情況下計(jì)劃和啟動(dòng)的，但充其量在足夠好的時(shí)間點(diǎn)被放棄。由于宏觀條件發(fā)生變化，此類努力的長(zhǎng)期計(jì)劃被放棄：該計(jì)劃的資金用完，組織將重點(diǎn)轉(zhuǎn)向其他事物或支持它的領(lǐng)導(dǎo)層離開。所以這個(gè)現(xiàn)實(shí)應(yīng)該被設(shè)計(jì)成團(tuán)隊(duì)如何處理單體應(yīng)用到微服務(wù)之旅。我稱這種方法為“架構(gòu)演化的原子步驟中的遷移”，其中遷移的每一步都應(yīng)該使架構(gòu)更接近其目標(biāo)狀態(tài)。每個(gè)進(jìn)化單元可能是一小步或一大步，但都是原子的，要么完成，要么恢復(fù)。這一點(diǎn)特別重要，因?yàn)槲覀冋诓捎玫驮隽糠椒▉砀倪M(jìn)整體架構(gòu)和解耦服務(wù)。每個(gè)增量都必須讓我們?cè)诩軜?gòu)目標(biāo)方面處于更好的位置。使用進(jìn)化架構(gòu)適應(yīng)度函數(shù)比喻，遷移的每個(gè)原子步驟之后的架構(gòu)適應(yīng)度函數(shù)應(yīng)該產(chǎn)生更接近架構(gòu)目標(biāo)的價(jià)值。

讓我通過一個(gè)例子圖解這個(gè)觀點(diǎn)。假設(shè)微服務(wù)架構(gòu)目的是增加開發(fā)者修改整個(gè)系統(tǒng)的速度交付價(jià)值。團(tuán)隊(duì)決定解耦用戶認(rèn)證到一個(gè)隔離的服務(wù)中，以 OAuth 2.0 協(xié)議為基礎(chǔ)。這個(gè)服務(wù)想要同時(shí)替換已有客戶端應(yīng)用程序認(rèn)證終端用戶，而且新的架構(gòu)微服務(wù)驗(yàn)證終端用戶。讓我們將這個(gè)進(jìn)化過程中的增量稱為“Auth 服務(wù)介紹”。一個(gè)方法介紹新的服務(wù)是先通過以下步驟：
（1）構(gòu)建 Auth 服務(wù)，實(shí)現(xiàn) OAuth 2.0 協(xié)議。
（2）在單體系統(tǒng)中添加一個(gè)新的認(rèn)證路徑并調(diào)用 Auth 服務(wù)認(rèn)證終端用戶。

如果團(tuán)隊(duì)在這里停下來并轉(zhuǎn)向構(gòu)建一些其他服務(wù)或功能，他們會(huì)使整體架構(gòu)處于熵增加的狀態(tài)。在這種狀態(tài)下，有兩種驗(yàn)證用戶的方法，新的 OAuth 2.0 基本路徑和舊客戶端的基于密碼/會(huì)話的路徑。在這一點(diǎn)上，團(tuán)隊(duì)實(shí)際上離他們更快地做出改變的總體目標(biāo)更遠(yuǎn)了。單體代碼的任何新開發(fā)人員都需要處理兩條代碼路徑，增加理解代碼的認(rèn)知負(fù)擔(dān)，以及更慢的更改和測(cè)試過程。

團(tuán)隊(duì)可以包含以下步驟到我們的原子進(jìn)化單元中：
（1）通過 OAuth 2.0 替換老客戶端的密碼/session
（2）從單體系統(tǒng)中淘汰老的認(rèn)證代碼

這時(shí)候我們可以說團(tuán)隊(duì)已經(jīng)接近目標(biāo)架構(gòu)了。

單體系統(tǒng)原子單元解構(gòu)包括：

• 解耦新服務(wù)

• 重定向消費(fèi)者到新的服務(wù)

• 從單體系統(tǒng)中淘汰來的代碼

反模式：解耦新服務(wù)用于新的消費(fèi)者并且從不淘汰老的服務(wù)。

我經(jīng)常發(fā)現(xiàn)團(tuán)隊(duì)終止從單體系統(tǒng)中遷移功能，新的功能開發(fā)出來以后馬上就宣布勝利了，也不淘汰老的代碼路徑，正如上面描述的反模式。主要原因是：（a）聚焦于引入新功能的短期利益（b）淘汰老的代碼會(huì)和構(gòu)建新功能形成競(jìng)爭(zhēng)優(yōu)先級(jí)。為了做正確的事，我們應(yīng)該盡可能的做原子步驟。

引用

How to break a Monolith into Microservices

總結(jié)

以上是生活随笔為你收集整理的单体系统如何拆分为微服务的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。