從單體式架構(gòu)遷移到微服務(wù)架構(gòu)：三個(gè)策略敘述
遷移到微服務(wù)綜述
遷移單體式應(yīng)用到微服務(wù)架構(gòu)意味著一系列現(xiàn)代化過程，有點(diǎn)像這幾代開發(fā)者一直在做的事情，實(shí)時(shí)上，當(dāng)遷移時(shí)，我們可以重用一些想法。
一個(gè)策略是：不要大規(guī)模(big bang)重寫代碼(只有當(dāng)你承擔(dān)重建一套全新基于微服務(wù)的應(yīng)用時(shí)候可以采用重寫這種方法)。重寫代碼聽起來很不錯(cuò)，但實(shí)際上充滿了風(fēng)險(xiǎn)最終可能會(huì)失敗，就如 Martin Fowler 所說：“the only thing a Big Bang rewrite guarantees is a Big Bang!”
相反，應(yīng)該采取逐步遷移單體式應(yīng)用的策略，通過逐步生成微服務(wù)新應(yīng)用，與舊的單體式應(yīng)用集成，隨著時(shí)間推移，單體式應(yīng)用在整個(gè)架構(gòu)中比例逐漸下降直到消失或者成為微服務(wù)架構(gòu)一部分。這個(gè)策略有點(diǎn)像在高速路上限速到 70 邁對(duì)車做維護(hù)，盡管有挑戰(zhàn)，但是比起重寫的風(fēng)險(xiǎn)小很多。
Martin Fowler 將這種現(xiàn)代化策略成為絞殺(Strangler)應(yīng)用，名字來源于雨林中的絞殺藤(strangler vine)，也叫絞殺榕 (strangler fig)。絞殺藤為了爬到森林頂端都要纏繞著大叔生長(zhǎng)，一段時(shí)間后，樹死了，留下樹形藤。這種應(yīng)用也使用同一種模式，圍繞著傳統(tǒng)應(yīng)用開發(fā)了新型微服務(wù)應(yīng)用，傳統(tǒng)應(yīng)用會(huì)漸漸退出舞臺(tái)。
我們來看看其他可行策略。
策略 1——停止挖掘
Law of Holes 是說當(dāng)自己進(jìn)洞就應(yīng)該停止挖掘。對(duì)于單體式應(yīng)用不可管理時(shí)這是最佳建議。換句話說，應(yīng)該停止讓單體式應(yīng)用繼續(xù)變大，也就是說當(dāng)開發(fā)新功能時(shí)不應(yīng)該為舊單體應(yīng)用添加新代碼，最佳方法應(yīng)該是將新功能開發(fā)成獨(dú)立微服務(wù)。如下圖所示：
除了新服務(wù)和傳統(tǒng)應(yīng)用，還有兩個(gè)模塊，其一是請(qǐng)求路由器，負(fù)責(zé)處理入口(http)請(qǐng)求，有點(diǎn)像之前提到的 API 網(wǎng)關(guān)。路由器將新功能請(qǐng)求發(fā)送給新開發(fā)的服務(wù)，而將傳統(tǒng)請(qǐng)求還發(fā)給單體式應(yīng)用。
另外一個(gè)是膠水代碼(glue code)，將微服務(wù)和單體應(yīng)用集成起來，微服務(wù)很少能獨(dú)立存在，經(jīng)常會(huì)訪問單體應(yīng)用的數(shù)據(jù)。膠水代碼，可能在單體應(yīng)用或者為服務(wù)或者二者兼而有之，負(fù)責(zé)數(shù)據(jù)整合。微服務(wù)通過膠水代碼從單體應(yīng)用中讀寫數(shù)據(jù)。
微服務(wù)有三種方式訪問單體應(yīng)用數(shù)據(jù)：
換氣單體應(yīng)用提供的遠(yuǎn)程 API
直接訪問單體應(yīng)用數(shù)據(jù)庫(kù)
自己維護(hù)一份從單體應(yīng)用中同步的數(shù)據(jù)
膠水代碼也被稱為容災(zāi)層(anti-corruption layer)，這是因?yàn)槟z水代碼保護(hù)微服務(wù)全新域模型免受傳統(tǒng)單體應(yīng)用域模型污染。膠水代碼在這兩種模型間提供翻譯功能。術(shù)語(yǔ) anti-corruption layer 第一次出現(xiàn)在 Eric Evans 撰寫的必讀書 Domain Driven Design，隨后就被提煉為一篇白皮書。開發(fā)容災(zāi)層可能有點(diǎn)不是很重要，但卻是避免單體式泥潭的必要部分。
將新功能以輕量級(jí)微服務(wù)方式實(shí)現(xiàn)由很多優(yōu)點(diǎn)，例如可以阻止單體應(yīng)用變的更加無(wú)法管理。微服務(wù)本身可以開發(fā)、部署和獨(dú)立擴(kuò)展。采用微服務(wù)架構(gòu)會(huì)給開發(fā)者帶來不同的切身感受。
然而，這方法并不解決任何單體式本身問題，為了解決單體式本身問題必須深入單體應(yīng)用做出改變。我們來看看這么做的策略。
策略 2——將前端和后端分離
減小單體式應(yīng)用復(fù)雜度的策略是講表現(xiàn)層和業(yè)務(wù)邏輯、數(shù)據(jù)訪問層分開。典型的企業(yè)應(yīng)用至少有三個(gè)不同元素構(gòu)成：
- 表現(xiàn)層——處理 HTTP 請(qǐng)求，要么響應(yīng)一個(gè) RESTAPI 請(qǐng)求，要么是提供一個(gè)基于 HTML 的圖形接口。對(duì)于一個(gè)復(fù)雜用戶接口應(yīng)用，表現(xiàn)層經(jīng)常是代碼重要的部分。
- 業(yè)務(wù)邏輯層——完成業(yè)務(wù)邏輯的應(yīng)用核心。
- 數(shù)據(jù)訪問層——訪問基礎(chǔ)元素，例如數(shù)據(jù)庫(kù)和消息代理。
在表現(xiàn)層與業(yè)務(wù)數(shù)據(jù)訪問層之間有清晰的隔離。業(yè)務(wù)層有由若干方面組成的粗粒度(coarse-grained)的 API，內(nèi)部包含了業(yè)務(wù)邏輯元素。API 是可以將單體業(yè)務(wù)分割成兩個(gè)更小應(yīng)用的天然邊界，其中一個(gè)應(yīng)用是表現(xiàn)層，另外一個(gè)是業(yè)務(wù)和數(shù)據(jù)訪問邏輯。分割后，表現(xiàn)邏輯應(yīng)用遠(yuǎn)程調(diào)用業(yè)務(wù)邏輯應(yīng)用，下圖表示遷移前后架構(gòu)不同：
單體應(yīng)用這么分割有兩個(gè)好處，其一使得應(yīng)用兩部分開發(fā)、部署和擴(kuò)展各自獨(dú)立，特別地，允許表現(xiàn)層開發(fā)者在用戶界面上快速選擇，進(jìn)行 A/B 測(cè)試;其二，使得一些遠(yuǎn)程 API 可以被微服務(wù)調(diào)用。
然而，這種策略只是部分的解決方案。很可能應(yīng)用的兩部分之一或者全部都是不可管理的，因此需要使用第三種策略來消除剩余的單體架構(gòu)。
策略 3——抽出服務(wù)
第三種遷移策略就是從單體應(yīng)用中抽取出某些模塊成為獨(dú)立微服務(wù)。每當(dāng)抽取一個(gè)模塊變成微服務(wù)，單體應(yīng)用就變簡(jiǎn)單一些;一旦轉(zhuǎn)換足夠多的模塊，單體應(yīng)用本身已經(jīng)不成為問題了，要么消失了，要么簡(jiǎn)單到成為一個(gè)服務(wù)。
排序那個(gè)模塊應(yīng)該被轉(zhuǎn)成微服務(wù)
一個(gè)巨大的復(fù)雜單體應(yīng)用由成十上百個(gè)模塊構(gòu)成，每個(gè)都是被抽取對(duì)象。決定第一個(gè)被抽取模塊一般都是挑戰(zhàn)，一般最好是從最容易抽取的模塊開始，這會(huì)讓開發(fā)者積累足夠經(jīng)驗(yàn)，這些經(jīng)驗(yàn)可以為后續(xù)模塊化工作帶來巨大好處。
轉(zhuǎn)換模塊成為微服務(wù)一般很耗費(fèi)時(shí)間，一般可以根據(jù)獲益程度來排序，一般從經(jīng)常變化模塊開始會(huì)獲益最大。一旦轉(zhuǎn)換一個(gè)模塊為微服務(wù)，就可以將其開發(fā)部署成獨(dú)立模塊，從而加速開發(fā)進(jìn)程。
將資源消耗大戶先抽取出來也是排序標(biāo)準(zhǔn)之一。例如，將內(nèi)存數(shù)據(jù)庫(kù)抽取出來成為一個(gè)微服務(wù)會(huì)非常有用，可以將其部署在大內(nèi)存主機(jī)上。同樣的，將對(duì)計(jì)算資源很敏感的算法應(yīng)用抽取出來也是非常有益的，這種服務(wù)可以被部署在有很多 CPU 的主機(jī)上。通過將資源消耗模塊轉(zhuǎn)換成微服務(wù)，可以使得應(yīng)用易于擴(kuò)展。
查找現(xiàn)有粗粒度邊界來決定哪個(gè)模塊應(yīng)該被抽取，也是很有益的，這使得移植工作更容易和簡(jiǎn)單。例如，只與其他應(yīng)用異步同步消息的模塊就是一個(gè)明顯邊界，可以很簡(jiǎn)單容易地將其轉(zhuǎn)換為微服務(wù)。
如何抽取模塊
抽取模塊第一步就是定義好模塊和單體應(yīng)用之間粗粒度接口，由于單體應(yīng)用需要微服務(wù)的數(shù)據(jù)，反之亦然，因此更像是一個(gè)雙向 API。因?yàn)楸仨氃谪?fù)責(zé)依賴關(guān)系和細(xì)粒度接口模式之間做好平衡，因此開發(fā)這種 API 很有挑戰(zhàn)性，尤其對(duì)使用域模型模式的業(yè)務(wù)邏輯層來說更具有挑戰(zhàn)，因此經(jīng)常需要改變代碼來解決依賴性問題，如圖所示：
一旦完成粗粒度接口，也就將此模塊轉(zhuǎn)換成獨(dú)立微服務(wù)。為了實(shí)現(xiàn)，必須寫代碼使得單體應(yīng)用和微服務(wù)之間通過使用進(jìn)程間通信(IPC)機(jī)制的 API 來交換信息。如圖所示遷移前后對(duì)比：
此例中，正在使用 Y 模塊的 Z 模塊是備選抽取模塊，其元素正在被 X 模塊使用，遷移第一步就是定義一套粗粒度 APIs，第一個(gè)接口應(yīng)該是被 X 模塊使用的內(nèi)部接口，用于激活 Z 模塊;第二個(gè)接口是被 Z 模塊使用的外部接口，用于激活 Y 模塊。
遷移第二步就是將模塊轉(zhuǎn)換成獨(dú)立服務(wù)。內(nèi)部和外部接口都使用基于 IPC 機(jī)制的代碼，一般都會(huì)將 Z 模塊整合成一個(gè)微服務(wù)基礎(chǔ)框架，來出來割接過程中的問題，例如服務(wù)發(fā)現(xiàn)。
抽取完模塊，也就可以開發(fā)、部署和擴(kuò)展另外一個(gè)服務(wù)，此服務(wù)獨(dú)立于單體應(yīng)用和其它服務(wù)?？梢詮念^寫代碼實(shí)現(xiàn)服務(wù);這種情況下，將服務(wù)和單體應(yīng)用整合的 API 代碼成為容災(zāi)層，在兩種域模型之間進(jìn)行翻譯工作。每抽取一個(gè)服務(wù)，就朝著微服務(wù)方向前進(jìn)一步。隨著時(shí)間推移，單體應(yīng)用將會(huì)越來越簡(jiǎn)單，用戶就可以增加更多獨(dú)立的微服務(wù)。 將現(xiàn)有應(yīng)用遷移成微服務(wù)架構(gòu)的現(xiàn)代化應(yīng)用，不應(yīng)該通過從頭重寫代碼方式實(shí)現(xiàn)，相反，應(yīng)該通過逐步遷移的方式。有三種策略可以考慮：將新功能以微服務(wù)方式實(shí)現(xiàn);將表現(xiàn)層與業(yè)務(wù)數(shù)據(jù)訪問層分離;將現(xiàn)存模塊抽取變成微服務(wù)。隨著時(shí)間推移，微服務(wù)數(shù)量會(huì)增加，開發(fā)團(tuán)隊(duì)的彈性和效率將會(huì)大大增加。
