概述

將單體應(yīng)用改造為微服務(wù)實際上是應(yīng)用現(xiàn)代化的過程，這是開發(fā)者們在過去十年來一直在做的事情，所以已經(jīng)有一些可以復用的經(jīng)驗。

全部重寫是絕對不能用的策略，除非你要集中精力從頭構(gòu)建一個基于微服務(wù)的應(yīng)用。雖然聽起來很有吸引力，但是風險很大，很有可能會失敗。就像MartinFowler所說的：?『The only thing a Big Bang rewrite guarantees is a Big Bang!』

你應(yīng)該循序漸進地重構(gòu)你的單體應(yīng)用。你可以逐步地構(gòu)建一個部分微服務(wù)化的應(yīng)用，然后和你的單體應(yīng)用集成起來。單體應(yīng)用的實現(xiàn)的功能會逐漸變少，最終消失或變成一個新的微服務(wù)組件。

種應(yīng)用現(xiàn)代化的策略為Strangler Application。這個名字來源于在熱帶雨林發(fā)現(xiàn)的一種植物Strangler vine，?為了夠到充足的陽光，?它們繞樹生長，一直向上。當樹木死后，只會留下一個樹形的藤蔓。應(yīng)用的現(xiàn)代化就是類似的模式，我們會在舊有的應(yīng)用上，構(gòu)建一個新的包含微服務(wù)的應(yīng)用，慢慢取代舊的應(yīng)用。下面一起來看下這些策略：

策略1：止損

Law of Holes告訴我們，如果你正在一個洞里，就不要繼續(xù)再挖了。當你的單體應(yīng)用已經(jīng)變得無法管理的時候，就不要再繼續(xù)擴大它的規(guī)模了。?比如你想添加新功能，不要在單體應(yīng)用中添加代碼，而要將新的代碼放在另一個單獨的微服務(wù)中。?下圖展示了使用這種方法后的系統(tǒng)架構(gòu)：?

除了新服務(wù)和舊的單體應(yīng)用，還有兩個組件。一個是?請求路由?（request router），用來處理過來的（比如HTTP）請求，類似于API網(wǎng)關(guān)。這個路由發(fā)送與新功能相應(yīng)的請求到新的服務(wù)上，將舊服務(wù)相關(guān)的請求路由到單體應(yīng)用上。

另一個組件是?膠水代碼?（glue code），用來將服務(wù)與單體應(yīng)用集成起來。一個服務(wù)很少是隔離存在的，需要訪問單體應(yīng)用的數(shù)據(jù)。膠水代碼就負責這些數(shù)據(jù)集成。微服務(wù)組件可以通過它來讀寫單體應(yīng)用中的數(shù)據(jù)。

一個服務(wù)可以通過三種方式訪問單體應(yīng)用中的數(shù)據(jù)：

• 通過調(diào)用單體應(yīng)用提供的遠程API

• 直接訪問單體的數(shù)據(jù)庫

• 保存一份數(shù)據(jù)的副本，和單體數(shù)據(jù)庫保持同步

膠水代碼有時被稱為?防腐層（anti-corruption layer）?，可以防止擁有自己原始領(lǐng)域模型的服務(wù)，被來自單體領(lǐng)域模型的概念所影響。

膠水代碼可以在兩個不同的模型間充當翻譯官，防腐層這個詞最初出現(xiàn)在Eric Evans寫的《Domain DrivenDesign》一書中。開發(fā)一個防腐層不是一個小工程，但如果你想從單體地獄中走出來，這是很重要的。

用輕量級的服務(wù)實現(xiàn)一個新功能，有很多好處。首先，可以防止單體應(yīng)用變得更難以管理；其次，這個應(yīng)用可以被獨立地開發(fā)，部署和擴展。

然而，這個方法并不能解決在舊有的單體部分遇到的問題，你還需要破壞原有的單體部分。

策略2：前后端分離

縮減單體應(yīng)用的一個策略是將表現(xiàn)層從業(yè)務(wù)邏輯和數(shù)據(jù)訪問層中分離出來，一個典型的企業(yè)應(yīng)用至少包括三種組件：

• 表現(xiàn)層：?這層組件用來處理HTTP請求，實現(xiàn)（REST）API或者基于HTML的Web UI。在一個有著復雜的用戶接口的應(yīng)用中，表現(xiàn)層通常有大量的代碼；

• 業(yè)務(wù)邏輯層：?應(yīng)用的核心代碼，用來實現(xiàn)業(yè)務(wù)規(guī)則；

• 數(shù)據(jù)訪問層：?訪問數(shù)據(jù)庫或信息中介的組件。

在表現(xiàn)邏輯與業(yè)務(wù)和數(shù)據(jù)訪問邏輯之間通常有著明顯的區(qū)分。業(yè)務(wù)層有一個粗粒度的API，包含一個或多個外立面組成，外立面封裝了業(yè)務(wù)邏輯組件。這個API是自然的『縫合』，所以可以將單體分割為更小的應(yīng)用，一個應(yīng)用包含了表現(xiàn)層，另一個應(yīng)用包含了業(yè)務(wù)和數(shù)據(jù)訪問層。分隔后，表現(xiàn)邏輯層應(yīng)用可以遠程調(diào)用業(yè)務(wù)邏輯層應(yīng)用，下圖展示了改造前后的架構(gòu)：

這樣分隔單體應(yīng)用有兩個主要好處。?首先你可以獨立地開發(fā)，部署和擴展兩個應(yīng)用，?比如對于表現(xiàn)層開發(fā)者來說，他們可以實現(xiàn)用戶界面的快速迭代，A/B測試也很容易實現(xiàn)；?其次，這樣做會向外開放一個微服務(wù)也可以調(diào)用的遠程API。

但是這個策略只是部分解決方案，很有可能會變成兩個混亂的單體應(yīng)用。需要用下面第三個策略去減少單體部分的比重。

策略3：提取服務(wù)

第三個策略的目的是將單體中的模塊，轉(zhuǎn)變?yōu)閱为毜奈⒎?wù)。每次提取一個模塊，就改造為微服務(wù)，單體部分就縮減了。一旦你轉(zhuǎn)化了足夠的模塊，最后不管單體部分是完全消失了，還是變小成了另一個微服務(wù)，都不是問題了。

優(yōu)先改造哪個模塊？

一個大型的復雜的單體應(yīng)用，通常包含數(shù)十甚至上百個模塊，都可以被提取出來，選擇先提取哪個是個問題?？梢詮娜菀妆惶崛〉拈_始，積累微服務(wù)的經(jīng)驗，然后提取那些能給你帶來最大好處的模塊。

通常提取那些頻繁變化的模塊很有用?，一旦你將這個模塊提取出來，就可以獨立開發(fā)和部署它了，可以加速開發(fā)。

另外一個就是提取那些資源需求和其它部分有很大不同的模塊。?比如將一個有內(nèi)存數(shù)據(jù)庫的模塊轉(zhuǎn)變?yōu)榉?wù)，就可以把它部署在內(nèi)存很大的主機上；同樣的，提取那些實現(xiàn)復雜算法的模塊，就可以把它部署在CPU多的主機上。總之這樣做有助于你擴展應(yīng)用。

當決定了提取哪個模塊后，需要看下現(xiàn)有的粗粒度邊界，可以幫助你將模塊轉(zhuǎn)化為服務(wù)。比如一個只會通過異步信息和其它應(yīng)用交互的模塊，就很容易能被改造為微服務(wù)。

如何提取一個模塊？

第一步是在模塊和單體之間定義一個粗粒度的接口。?由于單體和微服務(wù)的數(shù)據(jù)互相都有需求，所以它?很像一個雙向的API。但是在這個模塊和應(yīng)用的剩余部分之間，有著混亂的依賴關(guān)系和細粒度的交互模式，所以實現(xiàn)這個API還是很有挑戰(zhàn)的。通過域模型實現(xiàn)的業(yè)務(wù)邏輯，改造起來尤其困難，因為各個域模型間的關(guān)系復雜。通常需要進行大量的代碼修改，去打破這些依賴。

一旦你實現(xiàn)了細粒度的接口，就可以將模塊改造為一個獨立的服務(wù)。要寫代碼實現(xiàn)單體和微服務(wù)間的通信，通過使用了IPC機制的API。下圖展現(xiàn)了一個架構(gòu)在改造前，改造中和改造后的樣子：

?

在這個例子中，模塊Z是待提取的模塊。模塊X使用了Z的組件，Z又使用了模塊Y。

改造的第一步是定義一對粗粒度的API，第一個接口是模塊X調(diào)用模塊Z的入站接口，第二個是模塊Z調(diào)用模塊Y的出站接口；

第二步是將這個模塊改造為獨立的服務(wù)。入站接口和出站接口都通過IPC機制的代碼實現(xiàn)?？赡苣阈枰ㄟ^結(jié)合模塊Z到微服務(wù)底盤框架（用來處理橫切關(guān)注點，比如服務(wù)發(fā)現(xiàn)）上，來構(gòu)建這個服務(wù)。

一旦你提取了這個模塊，就可以獨立地開發(fā)，部署和擴展它了。你甚至可以從頭重寫這個服務(wù)，將這個服務(wù)和單體結(jié)合起來的API代碼就成了防腐層，相當于兩個域模型之間的翻譯官。每次提取一個服務(wù)，都是向著微服務(wù)又進了一步，單體的比重會逐步縮減。

總結(jié)

將單體架構(gòu)改造為微服務(wù)的過程是一種應(yīng)用現(xiàn)代化的形式，不應(yīng)該從頭重寫來實現(xiàn)。而是應(yīng)該循序漸進地改造你的應(yīng)用成為一系列微服務(wù)。有三種策略可以應(yīng)用：?用微服務(wù)實現(xiàn)新的功能；將表現(xiàn)層組件從業(yè)務(wù)和數(shù)據(jù)訪問組件中分離出來；改造單體中的模塊為微服務(wù)。?隨著時間的推移，你的微服務(wù)比重會增大，你的開發(fā)團隊的靈活性和速度也會提高

轉(zhuǎn)載于:https://www.cnblogs.com/cim3221847/p/6129433.html

總結(jié)

以上是生活随笔為你收集整理的【转】应用架构一团糟？如何将单体应用改造为微服务的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

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