譯者 | 劉汪洋
審校 | 重樓
單體架構(gòu)和微服務(wù)架構(gòu)是當(dāng)今軟件開(kāi)發(fā)中的兩種主要范式。人們常把它們分別視為傳統(tǒng)和現(xiàn)代的開(kāi)發(fā)方式，但實(shí)際情況要復(fù)雜得多。選擇合適的架構(gòu)需要權(quán)衡諸多因素，每種方案都有其獨(dú)特的優(yōu)劣勢(shì)。
對(duì)大多數(shù)新項(xiàng)目來(lái)說(shuō)，直接采用微服務(wù)架構(gòu)并非最佳選擇。從單體架構(gòu)起步，在需要時(shí)再逐步向微服務(wù)演進(jìn)，這種方式往往更高效、更經(jīng)濟(jì)。
隨著應(yīng)用規(guī)模擴(kuò)大，單體系統(tǒng)的維護(hù)成本不斷攀升。一些團(tuán)隊(duì)開(kāi)始考慮通過(guò)重構(gòu)將應(yīng)用拆分為微服務(wù)；也有團(tuán)隊(duì)僅僅因?yàn)樽非蠹夹g(shù)潮流而選擇轉(zhuǎn)型。這個(gè)過(guò)程往往耗時(shí)較長(zhǎng)，甚至可能增加維護(hù)負(fù)擔(dān)。因此，在啟動(dòng)轉(zhuǎn)型前，需要深入評(píng)估利弊得失，確保當(dāng)前架構(gòu)確實(shí)遇到了瓶頸。記住，拆分總比重建容易。
接下來(lái)，我們將聚焦于幾個(gè)核心話題：
- 如何充分發(fā)揮單體架構(gòu)的優(yōu)勢(shì)，為未來(lái)可能的微服務(wù)轉(zhuǎn)型打好基礎(chǔ)
- 如何實(shí)現(xiàn)從單體到微服務(wù)的平穩(wěn)過(guò)渡
- 微服務(wù)轉(zhuǎn)型可能帶來(lái)的連鎖反應(yīng)
更優(yōu)雅的模塊化單體架構(gòu)
在考慮架構(gòu)轉(zhuǎn)型前，不妨先審視項(xiàng)目的結(jié)構(gòu)設(shè)計(jì)。如果你的項(xiàng)目還沒(méi)有采用模塊化，這或許是一個(gè)值得嘗試的方向。模塊化不會(huì)強(qiáng)制你轉(zhuǎn)向微服務(wù)，但能讓你享受到微服務(wù)的諸多好處，同時(shí)避免額外的維護(hù)成本。
基于項(xiàng)目的構(gòu)建工具（Maven、Gradle等），我們可以把項(xiàng)目劃分為獨(dú)立的模塊。其中部分模塊可以共享復(fù)用，其他模塊則可以獨(dú)立封裝特定的業(yè)務(wù)領(lǐng)域或功能特性，為應(yīng)用提供獨(dú)立的服務(wù)能力。
模塊化架構(gòu)帶來(lái)的好處顯而易見(jiàn)。它讓?xiě)?yīng)用各個(gè)部分之間更加松耦合；讓功能開(kāi)發(fā)更加獨(dú)立，減少代碼沖突；讓新人更容易融入團(tuán)隊(duì)，因?yàn)樗麄兛梢詮木植咳胧郑鸩搅私庹w；讓測(cè)試更加精準(zhǔn)，因?yàn)槊總€(gè)模塊都可以獨(dú)立驗(yàn)證；如果未來(lái)需要遷移到微服務(wù)，這些模塊化的基礎(chǔ)會(huì)讓轉(zhuǎn)型事半功倍。
當(dāng)然，模塊化架構(gòu)也面臨一些局限。比如無(wú)法針對(duì)不同模塊獨(dú)立擴(kuò)展，系統(tǒng)整體的資源配置需要滿足負(fù)載最重的模塊需求，這可能造成資源浪費(fèi)。技術(shù)選擇也會(huì)受限，因?yàn)槟K化的單體應(yīng)用難以混用 Java、Golang 和Python 等不同語(yǔ)言，不過(guò)這在大多數(shù)場(chǎng)景下并非主要問(wèn)題。
模塊化整體式架構(gòu) vs 微服務(wù)
漸進(jìn)式的絞殺者模式
絞殺者模式借鑒了自然界中藤蔓植物的生長(zhǎng)特點(diǎn)，通過(guò)逐步替換的方式實(shí)現(xiàn)系統(tǒng)更新。這種模式讓你能夠在保持系統(tǒng)穩(wěn)定運(yùn)行的同時(shí)，逐步用新服務(wù)取代舊系統(tǒng)的各個(gè)部分。
實(shí)施絞殺者模式需要循序漸進(jìn)：
先進(jìn)行轉(zhuǎn)換，從單體架構(gòu)中識(shí)別并提取適合獨(dú)立的功能模塊，用現(xiàn)代技術(shù)重新實(shí)現(xiàn)，這是改進(jìn)原有實(shí)現(xiàn)的好機(jī)會(huì)。接著是共存階段，新舊系統(tǒng)并行運(yùn)行，通過(guò)灰度發(fā)布逐步遷移流量，同時(shí)保留回滾能力。最后是淘汰階段，當(dāng)新服務(wù)穩(wěn)定性得到驗(yàn)證后，完全切換流量并下線舊系統(tǒng)。
這種漸進(jìn)式遷移策略的優(yōu)勢(shì)顯著：既能保持系統(tǒng)持續(xù)交付能力，又能降低轉(zhuǎn)型風(fēng)險(xiǎn)，還能讓團(tuán)隊(duì)專注處理局部細(xì)節(jié)，及早發(fā)現(xiàn)并解決潛在問(wèn)題。
轉(zhuǎn)型中的挑戰(zhàn)與應(yīng)對(duì)
在實(shí)施絞殺者模式時(shí)，轉(zhuǎn)型策略的規(guī)劃至關(guān)重要。團(tuán)隊(duì)需要深入思考哪些組件優(yōu)先改造、如何確保新舊系統(tǒng)的無(wú)縫對(duì)接、如何維護(hù)數(shù)據(jù)一致性等關(guān)鍵問(wèn)題。同時(shí)，建立清晰的溝通機(jī)制和監(jiān)控體系，實(shí)時(shí)掌握每次替換的進(jìn)展和影響，這些都是確保轉(zhuǎn)型成功的重要保障。
微服務(wù)轉(zhuǎn)型帶來(lái)的連鎖反應(yīng)
轉(zhuǎn)向微服務(wù)固然能帶來(lái)諸多益處，但也會(huì)讓一些原本簡(jiǎn)單的事情變得復(fù)雜。比如本地測(cè)試場(chǎng)景，由于微服務(wù)數(shù)量眾多，開(kāi)發(fā)團(tuán)隊(duì)可能難以在個(gè)人設(shè)備上完整運(yùn)行測(cè)試環(huán)境。又如日志追蹤，當(dāng)一個(gè)業(yè)務(wù)流程橫跨多個(gè)服務(wù)時(shí)，完整的鏈路日志收集和分析就變得極具挑戰(zhàn)性。這就需要我們提前做好準(zhǔn)備，建立合適的工具和規(guī)范。
讓我們深入探討幾個(gè)需要重點(diǎn)關(guān)注的領(lǐng)域：
基礎(chǔ)設(shè)施的升級(jí)之路
單體應(yīng)用和微服務(wù)在基礎(chǔ)設(shè)施需求上有著本質(zhì)差異。運(yùn)行單體應(yīng)用時(shí)，基礎(chǔ)設(shè)施相對(duì)簡(jiǎn)單，用幾臺(tái)虛擬機(jī)或AWS EC2 這樣的 PaaS 方案就能應(yīng)對(duì)。擴(kuò)容、配置、升級(jí)、監(jiān)控等運(yùn)維工作也可以通過(guò)簡(jiǎn)單工具實(shí)現(xiàn)，不一定需要專業(yè)的 DevOps 團(tuán)隊(duì)支持。
而微服務(wù)架構(gòu)則對(duì)基礎(chǔ)設(shè)施提出了更高要求。伴隨服務(wù)數(shù)量增長(zhǎng)，手動(dòng)運(yùn)維很快就會(huì)力不從心。你需要引入Kubernetes這樣的容器編排平臺(tái)，或者選擇托管容器服務(wù)。這意味著更專業(yè)的技術(shù)棧和更系統(tǒng)的運(yùn)維能力儲(chǔ)備。
平臺(tái)能力的構(gòu)建之道
維護(hù)單體應(yīng)用時(shí)，很多工作都相對(duì)直觀。發(fā)現(xiàn)安全漏洞了？在一處更新依賴就夠了。需要規(guī)范化外部服務(wù)調(diào)用？寫(xiě)個(gè)統(tǒng)一的包裝類到處復(fù)用即可。
但在微服務(wù)場(chǎng)景下，這些看似簡(jiǎn)單的任務(wù)都變得復(fù)雜起來(lái)。原本的一次更新現(xiàn)在要協(xié)調(diào)多個(gè)服務(wù)，每個(gè)服務(wù)都有自己的版本節(jié)奏和依賴關(guān)系。當(dāng)服務(wù)和團(tuán)隊(duì)數(shù)量增多時(shí)，這種復(fù)雜度會(huì)進(jìn)一步提升。
這就是為什么許多組織會(huì)專門(mén)成立平臺(tái)團(tuán)隊(duì)，構(gòu)建統(tǒng)一的平臺(tái)層。平臺(tái)層就像是所有微服務(wù)的共同基礎(chǔ)，統(tǒng)一管理公共依賴，提供標(biāo)準(zhǔn)化模式，封裝現(xiàn)成的工具組件。這樣不僅簡(jiǎn)化了日常維護(hù)，還能確保整個(gè)系統(tǒng)的一致性。
結(jié)語(yǔ)：慎重選擇，穩(wěn)步前行
微服務(wù)轉(zhuǎn)型是一次重要的架構(gòu)升級(jí)，需要深思熟慮和周密規(guī)劃。我們探討的這些步驟和模式，都是為了讓這個(gè)過(guò)程更加平穩(wěn)可控。絞殺者模式提供了漸進(jìn)式的轉(zhuǎn)型思路，保障了系統(tǒng)持續(xù)穩(wěn)定運(yùn)行。而模塊化的單體架構(gòu)不僅是邁向微服務(wù)的重要準(zhǔn)備，有時(shí)甚至能讓我們重新審視轉(zhuǎn)型決策，在享受微服務(wù)優(yōu)勢(shì)的同時(shí)避免過(guò)度的復(fù)雜性。
選擇什么樣的架構(gòu)并不重要，重要的是這個(gè)選擇能否真正解決我們面臨的問(wèn)題，能否適應(yīng)團(tuán)隊(duì)的技術(shù)水平和業(yè)務(wù)需求。架構(gòu)轉(zhuǎn)型不是目的，而是手段，最終服務(wù)于業(yè)務(wù)發(fā)展才是根本。
作者介紹
劉汪洋，51CTO社區(qū)編輯，昵稱：明明如月，一個(gè)擁有 5 年開(kāi)發(fā)經(jīng)驗(yàn)的某大廠高級(jí) Java 工程師。
