本篇內(nèi)容介紹了“Java微服務(wù)架構(gòu)的重構(gòu)策略是什么”的有關(guān)知識(shí)，在實(shí)際案例的操作過程中，不少人都會(huì)遇到這樣的困境，接下來就讓小編帶領(lǐng)大家學(xué)習(xí)一下如何處理這些情況吧！希望大家仔細(xì)閱讀，能夠?qū)W有所成！

創(chuàng)新互聯(lián)建站長期為上千多家客戶提供的網(wǎng)站建設(shè)服務(wù)，團(tuán)隊(duì)從業(yè)經(jīng)驗(yàn)10年，關(guān)注不同地域、不同群體，并針對(duì)不同對(duì)象提供差異化的產(chǎn)品和服務(wù)；打造開放共贏平臺(tái)，與合作伙伴共同營造健康的互聯(lián)網(wǎng)生態(tài)環(huán)境。為陸河企業(yè)提供專業(yè)的網(wǎng)站建設(shè)、網(wǎng)站制作，陸河網(wǎng)站改版等技術(shù)服務(wù)。擁有十多年豐富建站經(jīng)驗(yàn)和眾多成功案例,為您定制開發(fā)。

1.將新功能實(shí)現(xiàn)為服務(wù)

“挖坑法則”(The Law of  Holes)指出：如果你發(fā)現(xiàn)自己已經(jīng)陷入了困境，就不要再給自己繼續(xù)挖坑了。當(dāng)你的單體應(yīng)用變得無法管理時(shí)，這是一個(gè)很好的可供參考的建議。換句話說，如果你有一個(gè)龐大的、復(fù)雜的單體應(yīng)用程序，請(qǐng)不要通過向單體添加代碼來實(shí)現(xiàn)新功能。這將使你的單體變得更龐大，更難以管理。相反，你應(yīng)該將新功能實(shí)現(xiàn)為服務(wù)。

這是開始將單體應(yīng)用程序遷移到微服務(wù)架構(gòu)的好方法。它降低了單體的生長速度，加速了新功能的開發(fā)(因?yàn)槭窃谌碌拇a庫中進(jìn)行開發(fā))，還能快速展示采用微服務(wù)架構(gòu)的價(jià)值。

把新的服務(wù)與單體集成

圖 1顯示了將新功能實(shí)現(xiàn)為服務(wù)后的應(yīng)用程序架構(gòu)。除了新服務(wù)和單體外，該架構(gòu)還包括另外兩個(gè)將服務(wù)集成到應(yīng)用程序中的元素：

■ API Gateway：將對(duì)新功能的請(qǐng)求路由到新服務(wù)，并將遺留請(qǐng)求路由到單體。

■ 集成膠水代碼：將服務(wù)與單體結(jié)合。它使服務(wù)能夠訪問單體所擁有的數(shù)據(jù)，并能夠調(diào)用單體實(shí)現(xiàn)的功能。

集成膠水的代碼不是一個(gè)獨(dú)立組件。相反，它由單體中的適配器和使用一個(gè)或多個(gè)進(jìn)程間通信機(jī)制的服務(wù)組成。

何時(shí)把新功能實(shí)現(xiàn)為服務(wù)

理想情況下，你應(yīng)該在絞殺者應(yīng)用程序中而不是在單體中實(shí)現(xiàn)每個(gè)新功能。你將實(shí)現(xiàn)新功能作為新服務(wù)或作為現(xiàn)有服務(wù)的一部分。這樣你就可以避免和單體代碼庫打交道。不幸的是，并非每個(gè)新功能都可以作為服務(wù)實(shí)現(xiàn)。

因?yàn)槲⒎?wù)架構(gòu)的本質(zhì)是一組圍繞業(yè)務(wù)功能組織的松耦合服務(wù)。例如，某個(gè)功能可能太小而無法成為有意義的服務(wù)。例如，你可能只需要向現(xiàn)有類添加一些字段和方法?；蛘咝鹿δ芸赡芘c單體中的代碼緊耦合。如果你嘗試將此類功能實(shí)現(xiàn)為服務(wù)，則通常會(huì)發(fā)現(xiàn)，由于過多的進(jìn)程間通信而導(dǎo)致性能下降。你可能還會(huì)遇到數(shù)據(jù)一致性的問題。如果新功能無法作為服務(wù)實(shí)現(xiàn)，則解決方案通常是首先在單體中實(shí)現(xiàn)新功能。之后，你可以將該功能以及其他相關(guān)功能提取到自己的服務(wù)中。

以服務(wù)的方式實(shí)現(xiàn)新功能，可以加速這些功能的開發(fā)。這是快速展示微服務(wù)架構(gòu)價(jià)值的好方法。它還能夠降低單體的增長速度。但最終，你需要使用另外兩種策略來分解單體。你需要通過將單體中的功能提取到服務(wù)，從而將單體中的功能遷移到絞殺者應(yīng)用程序。你也可以通過水平分割單體架構(gòu)來提高開發(fā)速度。我們來看看如何做到這一點(diǎn)。

2.隔離表現(xiàn)層與后端

縮小單體應(yīng)用程序的一個(gè)策略是將表現(xiàn)層與業(yè)務(wù)邏輯和數(shù)據(jù)訪問層分開。典型的企業(yè)應(yīng)用程序包含以下各層：

■ 表現(xiàn)邏輯層：它由處理 HTTP 請(qǐng)求的模塊組成，并生成實(shí)現(xiàn) Web UI 的 HTML  頁面。在具有復(fù)雜用戶界面的應(yīng)用程序中，表現(xiàn)層通常包含大量代碼。

■ 業(yè)務(wù)邏輯層：由實(shí)現(xiàn)業(yè)務(wù)規(guī)則的模塊組成，這些模塊在企業(yè)應(yīng)用程序中可能很復(fù)雜。

■ 數(shù)據(jù)訪問邏輯層：包含訪問基礎(chǔ)設(shè)施服務(wù)(如數(shù)據(jù)庫和消息代理)的模塊。 表現(xiàn)邏輯層與業(yè)務(wù)和數(shù)據(jù)訪問邏輯層之間通常存在清晰的邊界。業(yè)務(wù)層具有粗粒度  API，由一個(gè)或多個(gè)封裝業(yè)務(wù)邏輯的門面(Facade)組成。這個(gè) API 是一個(gè)自然的接縫，你可以沿著它將單體分成兩個(gè)較小的應(yīng)用程序，如圖 2 所示。

一個(gè)應(yīng)用程序包含表現(xiàn)層，另一個(gè)包含業(yè)務(wù)和數(shù)據(jù)訪問邏輯層。分割后，表現(xiàn)邏輯應(yīng)用程序?qū)I(yè)務(wù)邏輯應(yīng)用程序進(jìn)行遠(yuǎn)程調(diào)用。

以這種方式拆分單體應(yīng)用有兩個(gè)主要好處。它使你能夠彼此獨(dú)立地開發(fā)、部署和擴(kuò)展這兩個(gè)應(yīng)用程序。特別是，它允許表現(xiàn)層開發(fā)人員快速迭代用戶界面并輕松執(zhí)行A/B測試，而無須部署后端。這種方法的另一個(gè)好處是它公開了業(yè)務(wù)邏輯的一組遠(yuǎn)程API，可以被稍后開發(fā)的微服務(wù)調(diào)用。

但這種策略只是部分解決方案。很可能至少有一個(gè)或兩個(gè)最終的應(yīng)用程序仍然是一個(gè)難以管理的單體。你需要使用第三種策略將單體替換為服務(wù)。

3.提取業(yè)務(wù)能力到服務(wù)中

將新功能實(shí)現(xiàn)為服務(wù)，并從后端拆分出前端Web應(yīng)用程序并不會(huì)讓你抵達(dá)勝利的彼岸。你仍將最終在單體代碼中進(jìn)行大量開發(fā)。如果你希望顯著改進(jìn)應(yīng)用程序的架構(gòu)并提高開發(fā)速度，則需要通過逐步將業(yè)務(wù)功能從單體遷移到服務(wù)來拆分單體應(yīng)用。當(dāng)你使用此策略時(shí)，隨著時(shí)間推移，服務(wù)實(shí)現(xiàn)的業(yè)務(wù)功能數(shù)量會(huì)增加，而單體會(huì)逐漸縮小。

你想要提取到服務(wù)中的功能是對(duì)單體應(yīng)用自上而下的一個(gè)“垂直切片”。該切片包含以下內(nèi)容：

■ 實(shí)現(xiàn)API端點(diǎn)的入站適配器。

■ 領(lǐng)域邏輯。

■ 出站適配器，例如數(shù)據(jù)庫訪問邏輯。

■ 單體的數(shù)據(jù)庫模式。

如圖 3 所示，此代碼從單體中提取并移至獨(dú)立服務(wù)中。API Gateway  將調(diào)用提取的業(yè)務(wù)功能的請(qǐng)求路由到該服務(wù)，并將其他請(qǐng)求路由到單體。單體和服務(wù)通過集成膠水代碼進(jìn)行協(xié)作。集成膠水由服務(wù)中的適配器和使用一個(gè)或多個(gè)進(jìn)程間通信機(jī)制的單體組成。

提取服務(wù)具有挑戰(zhàn)性。你需要確定如何將單體的領(lǐng)域模型分成兩個(gè)獨(dú)立的領(lǐng)域模型，其中一個(gè)模型成為服務(wù)的領(lǐng)域模型。你需要打破對(duì)象引用等依賴。你甚至可能需要拆分類，以將功能移動(dòng)到服務(wù)中。對(duì)了，你還需要重構(gòu)數(shù)據(jù)庫。

提取服務(wù)通常很耗時(shí)，尤其是當(dāng)單體的代碼庫很混亂時(shí)。因此，你需要仔細(xì)考慮要提取的服務(wù)。應(yīng)當(dāng)重點(diǎn)關(guān)注重構(gòu)那些能夠提供很多價(jià)值的應(yīng)用程序部分。在提取服務(wù)之前，問問自己這樣做的好處是什么。

例如，提取一項(xiàng)實(shí)現(xiàn)對(duì)業(yè)務(wù)至關(guān)重要且不斷發(fā)展的功能的服務(wù)是值得的。如果沒有太多的好處，那么在提取服務(wù)方面投入精力是沒有價(jià)值的。在本節(jié)的后面部分，我將介紹一些用于確定服務(wù)提取范圍和時(shí)間的策略。但首先讓我們更詳細(xì)地了解一下在提取服務(wù)時(shí)將面臨的一些挑戰(zhàn)以及解決這些挑戰(zhàn)的方法。

提取服務(wù)時(shí)會(huì)遇到以下這些挑戰(zhàn)：

■ 拆解領(lǐng)域模型。

■ 重構(gòu)數(shù)據(jù)庫。

拆解領(lǐng)域模型

為了提取服務(wù)，你需要從單體的領(lǐng)域模型中提取服務(wù)相關(guān)的領(lǐng)域模型。你需要進(jìn)行大動(dòng)作來拆分領(lǐng)域模型。你將遇到的一個(gè)挑戰(zhàn)是消除跨越服務(wù)邊界的對(duì)象引用。保留在單體中的類可能會(huì)引用已移動(dòng)到服務(wù)的類，反之亦然。例如，想象一下，如圖  4 所示，你提取了Order  Service，其Order類引用了單體的Restaurant類。因?yàn)榉?wù)實(shí)例通常是一個(gè)進(jìn)程，所以讓對(duì)象引用跨越服務(wù)邊界是沒有意義的。你需要消除這種類型的對(duì)象引用。

解決此問題的一個(gè)好方法是根據(jù)DDD聚合進(jìn)行思考。聚合使用主鍵而不是對(duì)象引用相互引用。因此，你可以將 Order 和 Restaurant  類視為聚合，如圖5所示，將Order類中對(duì) Restaurant 的引用替換為存儲(chǔ)主鍵值的restaurantId 字段。

使用主鍵替換對(duì)象引用的一個(gè)問題是，雖然這是對(duì)類的一個(gè)小改動(dòng)，但它可能會(huì)對(duì)期望對(duì)象引用的類的客戶端產(chǎn)生很大的影響。在本節(jié)的后面部分，我將介紹如何通過在服務(wù)和單體之間復(fù)制數(shù)據(jù)來減少更改的范圍。例如，Delivery  Service可以定義一個(gè)Restaurant類，后者是單體中Restaurant 類的復(fù)制品。

提取服務(wù)通常比將整個(gè)類移動(dòng)到服務(wù)中的工作量要大得多。拆分領(lǐng)域模型面臨的更大挑戰(zhàn)是提取嵌入在具有其他職責(zé)的類中的功能。這個(gè)問題經(jīng)常出現(xiàn)在具有過多職責(zé)的上帝類(God  Class)中。例如，Order 類是FTGO應(yīng)用程序中的上帝類之一。它實(shí)現(xiàn)了多種業(yè)務(wù)功能，包括訂單管理、送餐管理等。Delivery  實(shí)體會(huì)實(shí)現(xiàn)之前與Order類中的其他功能捆綁在一起的送餐管理功能。

重構(gòu)數(shù)據(jù)庫

拆分領(lǐng)域模型不僅僅涉及更改代碼。領(lǐng)域模型中的許多類都是在數(shù)據(jù)庫中持久化保存的。它們的字段映射到具體的數(shù)據(jù)庫模式。因此，當(dāng)你從單體中提取服務(wù)時(shí)，你也會(huì)移動(dòng)數(shù)據(jù)。你需要將表從單體的數(shù)據(jù)庫移動(dòng)到服務(wù)的數(shù)據(jù)庫。

此外，拆分實(shí)體時(shí)，需要拆分相應(yīng)的數(shù)據(jù)庫表并將新表移動(dòng)到服務(wù)中。例如，在將送餐管理提取到服務(wù)中時(shí)，你需要拆分Order實(shí)體并提取出一個(gè)Delivery實(shí)體。在數(shù)據(jù)庫級(jí)別，你要拆分ORDERS表并定義新的DELIVERY表。然后，將DELIVERY表移動(dòng)到該服務(wù)。

復(fù)制數(shù)據(jù)以避免更廣泛的更改

如上所述，提取服務(wù)需要你對(duì)單體的領(lǐng)域模型做出更改。例如，使用主鍵和拆分類替換對(duì)象引用。這些類型的更改可能會(huì)影響代碼庫，并要求你對(duì)單體各個(gè)受影響的部分進(jìn)行廣泛的更改。例如，如果拆分Order實(shí)體并提取Delivery實(shí)體，則必須更改代碼中引用被移動(dòng)字段而受影響的每個(gè)部分。進(jìn)行這些改變可能會(huì)非常耗時(shí)，并且可能成為打破單體的巨大障礙。

延遲并可能避免進(jìn)行這些昂貴更改的一種好方法是使用類似于《數(shù)據(jù)庫重構(gòu)》一書中描述的方法。重構(gòu)數(shù)據(jù)庫的一個(gè)主要障礙是更改該數(shù)據(jù)庫的所有客戶端以使用新模式。本書中提出的解決方案是在過渡期內(nèi)保留原模式，并使用觸發(fā)器在原模式和新模式間同步。然后，你可以將客戶端從舊模式遷移到新模式。

從單體中提取服務(wù)時(shí)，我們可以使用類似的方法。例如，在提取Delivery實(shí)體時(shí)，我們將Order實(shí)體在過渡期內(nèi)大部分保持不變。如圖6所示，我們將與交付相關(guān)的字段設(shè)置為只讀，并通過將數(shù)據(jù)從Delivery  Service復(fù)制回單體來使其保持***。因此，我們只需要在單體的代碼中找到更新這些字段的位置，并更改它們?yōu)檎{(diào)用新的Delivery Service即可。

通過從Delivery  Service復(fù)制數(shù)據(jù)來保留Order實(shí)體的結(jié)構(gòu)，可以顯著減少我們需要立即完成的工作量。隨著時(shí)間的推移，我們可以將使用與交付相關(guān)的Order實(shí)體字段或ORDERS表列的代碼遷移到Delivery  Service。更重要的是，我們可能永遠(yuǎn)不需要在單體中做出改變。如果隨后將該代碼提取到服務(wù)中，則該服務(wù)可以訪問DeliveryService。

確定提取何種服務(wù)以及何時(shí)提取

正如我所提到的，拆解單體是耗時(shí)的。它分散了實(shí)施新功能的人力資源。因此，你必須仔細(xì)確定提取服務(wù)的順序。你需要專注于提取能夠帶來***收益的服務(wù)。更重要的是，你希望不斷向業(yè)務(wù)部門展示遷移到微服務(wù)架構(gòu)的價(jià)值。

在任何旅程中，了解你要去的地方至關(guān)重要。開始遷移到微服務(wù)的好方法是使用時(shí)間框架來定義工作。你應(yīng)該花費(fèi)很短的時(shí)間，例如幾周，集思廣益討論理想架構(gòu)并定義一組服務(wù)。這將為你提供一個(gè)目標(biāo)。但是，重要的是要記住，這種架構(gòu)并非一成不變。當(dāng)你分解單體并獲得經(jīng)驗(yàn)后，你應(yīng)該應(yīng)用你所獲得的經(jīng)驗(yàn)對(duì)重構(gòu)計(jì)劃及時(shí)做出調(diào)整。

一旦確定了目標(biāo)，下一步就是開始拆分單體結(jié)構(gòu)?？梢允褂脦追N不同的策略來確定提取服務(wù)的順序。

一種策略是有效地凍結(jié)單體架構(gòu)的開發(fā)并按需提取服務(wù)。你可以提取必要的服務(wù)并進(jìn)行更改，而不是在單體中實(shí)現(xiàn)功能或修復(fù)錯(cuò)誤。這種方法的一個(gè)好處是它會(huì)迫使你打破單體。一個(gè)弊端是服務(wù)的提取是由短期需求而不是長期需求驅(qū)動(dòng)的。例如，即使你對(duì)系統(tǒng)中相對(duì)穩(wěn)定的部分進(jìn)行了少量更改，也需要你提取服務(wù)。因此，你做的大量工作可能只能換來較小的收益。

另一種策略是更有計(jì)劃的方法，你可以根據(jù)提取應(yīng)用程序模塊獲得的預(yù)期收益，對(duì)應(yīng)用程序的模塊進(jìn)行排名。提取服務(wù)有益的原因有以下幾點(diǎn)：

■ 加速開發(fā)：如果你的應(yīng)用程序的路線圖表明應(yīng)用程序的特定部分將在明年進(jìn)行大量開發(fā)，那么將其轉(zhuǎn)換為服務(wù)可加速開發(fā)。

■ 解決性能、可擴(kuò)展性或可靠性問題：如果應(yīng)用程序的特定部分存在性能、可擴(kuò)展性問題或不可靠，那么將其轉(zhuǎn)換為服務(wù)是有價(jià)值的。

■ 允許提取其他一些服務(wù)：由于模塊之間的依賴關(guān)系，有時(shí)提取一個(gè)服務(wù)會(huì)簡化另一個(gè)服務(wù)的提取。  你可以使用這些條件將重構(gòu)任務(wù)添加到應(yīng)用程序的“待辦事項(xiàng)”中，并按預(yù)期收益排名。這種方法的好處在于它更具戰(zhàn)略性，并且更符合業(yè)務(wù)需求。在做 Sprint  的計(jì)劃時(shí)，你可以確定實(shí)現(xiàn)功能或提取服務(wù)哪個(gè)更有價(jià)值。

“Java微服務(wù)架構(gòu)的重構(gòu)策略是什么”的內(nèi)容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業(yè)相關(guān)的知識(shí)可以關(guān)注創(chuàng)新互聯(lián)網(wǎng)站，小編將為大家輸出更多高質(zhì)量的實(shí)用文章！