?作者 | Shai Almog

策劃 | 云昭

歷史總會(huì)重演。一切剛過去的，又會(huì)被重新提起。開源項(xiàng)目Codename One的聯(lián)合創(chuàng)始人Shai，曾是Sun Microsystems開源LWUIT項(xiàng)目的共同作者，參與了無(wú)數(shù)開源項(xiàng)目。作為最早一批Java開發(fā)者，最近感慨道：?jiǎn)误w，又回來(lái)了！

Shai說道：我已經(jīng)在這個(gè)圈子里很久時(shí)間了，看到了一次次被拋棄、被重新發(fā)現(xiàn)的想法，超越“時(shí)髦詞匯”，并凱旋而歸。

他進(jìn)一步舉例，“近年來(lái)，SQL也掙扎過后，死而復(fù)生。我們?cè)俅螣釔坳P(guān)系數(shù)據(jù)庫(kù)。我認(rèn)為單體架構(gòu)將再次迎來(lái)奇幻之旅。微服務(wù)和無(wú)服務(wù)器是云供應(yīng)商推動(dòng)的趨勢(shì)，目的當(dāng)然是在向我們兜售更多的云計(jì)算資源。然而對(duì)于大多數(shù)用例來(lái)說，微服務(wù)在財(cái)務(wù)上意義不大。是的，供應(yīng)商當(dāng)然也可以降低成本。但當(dāng)他們擴(kuò)大規(guī)模時(shí)，他們會(huì)以股息來(lái)覆蓋掉成本。單是可觀測(cè)性成本的增加，就讓‘大型云’供應(yīng)商的腰包鼓起來(lái)了！”

作為從業(yè)近30年的資深技術(shù)大神，為何做此感嘆？本文通過一場(chǎng)“利用模塊降低架構(gòu)成本”的探討，幫助大家梳理現(xiàn)在的架構(gòu)設(shè)計(jì)難題，希望對(duì)諸君有所啟發(fā)。

1、問題背景

我最近領(lǐng)導(dǎo)了一個(gè)會(huì)議小組，討論了微服務(wù)與單體服務(wù)的主題。組內(nèi)認(rèn)為，單塊的規(guī)模不如微服務(wù)。這對(duì)于亞馬遜、eBay等所取代的那些龐然大物來(lái)說可能是正確的。這些確實(shí)是巨大的代碼庫(kù)，其中的每一次修改都是痛苦的，而且它們的擴(kuò)展都是具有挑戰(zhàn)性的。但這不是一個(gè)公平的比較。較新的方法通常優(yōu)于舊的方法。但如果我們用更新的工具構(gòu)建一個(gè)整體，我們會(huì)得到更好的可擴(kuò)展性嗎？它的局限性是什么？現(xiàn)代的單體（也稱巨石）到底該是什么樣子？

2、單體回歸范例：Modulith

Spring Modulith是一個(gè)模塊化的單體結(jié)構(gòu)，可以讓我們使用動(dòng)態(tài)隔離件構(gòu)建單體結(jié)構(gòu)。通過這種方法，我們可以分離測(cè)試、開發(fā)、文檔和依賴項(xiàng)。這有助于微服務(wù)開發(fā)的獨(dú)立方面，而所涉及的開銷很少。它消除了遠(yuǎn)程調(diào)用和功能復(fù)制（存儲(chǔ)、身份驗(yàn)證等）的開銷。

Spring Modulith不是基于Java平臺(tái)模塊化（Jigsaw）。他們?cè)跍y(cè)試期間和運(yùn)行時(shí)強(qiáng)制分離，這是一個(gè)常規(guī)的Spring Boot項(xiàng)目。它有一些額外的運(yùn)行時(shí)功能，可以實(shí)現(xiàn)模塊化的可觀測(cè)性，但它主要是“最佳實(shí)踐”的執(zhí)行者。這種分離的價(jià)值超出了我們通常使用微服務(wù)的價(jià)值，但也有一些權(quán)衡。

舉個(gè)例子，傳統(tǒng)的Spring monolith將采用分層架構(gòu)，其包如下：

com.debugagent.myapp
com.debugagent.myapp.services
com.debugagent.myapp.db
com.debugagent.myapp.rest

這很有價(jià)值，因?yàn)樗梢詭椭覀儽苊鈱又g的依賴關(guān)系；例如，DB層不應(yīng)依賴于服務(wù)層。我們可以使用這樣的模塊，并有效地將依賴關(guān)系圖推向一個(gè)方向：向下。但隨著我們的成長(zhǎng)，這沒有多大意義。每一層都將充滿業(yè)務(wù)邏輯類和數(shù)據(jù)庫(kù)復(fù)雜性。

有了Modulith，我們的架構(gòu)看起來(lái)更像這樣：

com.debugagent.myapp.customers
com.debugagent.myapp.customers.services
com.debugagent.myapp.customers.db
com.debugagent.myapp.customers.rest

com.debugagent.myapp.invoicing
com.debugagent.myapp.invoicing.services
com.debugagent.myapp.invoicing.db
com.debugagent.myapp.invoicing.rest

com.debugagent.myapp.hr
com.debugagent.myapp.hr.services
com.debugagent.myapp.hr.db
com.debugagent.myapp.hr.rest

這看起來(lái)非常接近一個(gè)合適的微服務(wù)架構(gòu)。我們根據(jù)業(yè)務(wù)邏輯分離了所有部分。在這里，可以更好地控制交叉依賴關(guān)系，團(tuán)隊(duì)可以專注于自己的孤立區(qū)域，而不必互相踩腳。這是微服務(wù)的價(jià)值之一，且沒有開銷。

我們可以使用注釋進(jìn)一步深入地和聲明性地實(shí)現(xiàn)分離。我們可以定義哪個(gè)模塊使用哪個(gè)并強(qiáng)制單向依賴關(guān)系，因此人力資源模塊將與發(fā)票無(wú)關(guān)?？蛻裟K也不會(huì)。我們可以在客戶和發(fā)票之間建立單向關(guān)系，并使用事件進(jìn)行反饋。Modulith中的事件是簡(jiǎn)單、快速和事務(wù)性的。它們消除了模塊之間的依賴關(guān)系，無(wú)需麻煩。這可以用微服務(wù)實(shí)現(xiàn)，但很難實(shí)現(xiàn)。比如，開票需要向不同的模塊公開接口。如何防止客戶使用該界面？

有了模塊，我們就可以做到。對(duì)用戶可以更改代碼并提供訪問權(quán)限，但這需要經(jīng)過代碼審查，這會(huì)帶來(lái)自己的問題。請(qǐng)注意，對(duì)于模塊，我們?nèi)匀豢梢砸蕾嚦Ｒ姷奈⒎?wù)，如功能標(biāo)志、消息傳遞系統(tǒng)等。您可以在文檔和Nicolas Fr?nkel的博客中閱讀有關(guān)Spring Modulith的更多信息。

模塊系統(tǒng)中的每個(gè)依賴項(xiàng)都被映射并記錄在代碼中。Spring實(shí)現(xiàn)包括使用方便的最新圖表自動(dòng)記錄所有內(nèi)容的能力。你可能會(huì)認(rèn)為，依賴性是Terraform的原因。對(duì)于這樣的“高級(jí)”設(shè)計(jì)來(lái)說，這是正確的地方嗎？

對(duì)于Modulith部署，像Terraform這樣的基礎(chǔ)設(shè)施即代碼（IaC）解決方案仍然存在，但它們會(huì)簡(jiǎn)單得多。問題是責(zé)任的劃分。正如下圖所展示，微服務(wù)并沒有消除整體結(jié)構(gòu)的復(fù)雜性。我們只把“難啃的骨頭”踢給了DevOps團(tuán)隊(duì)。更糟糕的是，我們沒有給他們正確的工具來(lái)理解這種復(fù)雜性，所以他們不得不從外部管理。

圖源：Twitter

這就是為什么我們行業(yè)的基礎(chǔ)設(shè)施成本在上升，而傳統(tǒng)行業(yè)的基礎(chǔ)設(shè)施價(jià)格卻在下降。當(dāng)DevOps團(tuán)隊(duì)遇到問題時(shí)，他們會(huì)投入資源。這顯然不是正確的做法。

3、其他模塊

我們可以使用標(biāo)準(zhǔn)Java平臺(tái)模塊（Jigsaw）來(lái)構(gòu)建Spring Boot應(yīng)用程序。這樣做的好處是可以分解應(yīng)用程序和標(biāo)準(zhǔn)Java語(yǔ)法，但有時(shí)可能會(huì)很尷尬。當(dāng)使用外部庫(kù)或?qū)⒁恍┕ぷ鞑鸱譃橥ㄓ霉ぞ邥r(shí)，可能會(huì)更有效。

另一個(gè)選項(xiàng)是Maven中的模塊系統(tǒng)。這個(gè)系統(tǒng)允許我們將構(gòu)建分解為多個(gè)單獨(dú)的項(xiàng)目。這是一個(gè)非常方便的過程，可以讓我們省去大量項(xiàng)目的麻煩。每個(gè)項(xiàng)目都是獨(dú)立的，易于使用。它可以使用自己的構(gòu)建過程。然后，當(dāng)我們構(gòu)建主項(xiàng)目時(shí)，這些全部都變成了一個(gè)單體。在某種程度上，這才是我們真正想要的。

4、單體架構(gòu)：擴(kuò)展，有解嗎

可以使用大多數(shù)微服務(wù)擴(kuò)展工具來(lái)擴(kuò)展我們的單體們。許多與擴(kuò)展和集群相關(guān)的開發(fā)都是在單體架構(gòu)的情況下進(jìn)行的。這是一個(gè)更簡(jiǎn)單的過程，因?yàn)橹挥幸粋€(gè)移動(dòng)部分：應(yīng)用程序。我們復(fù)制其他實(shí)例并觀察它們。沒有哪項(xiàng)服務(wù)是失敗的。我們有細(xì)粒度的性能工具，所有的功能都可以作為一個(gè)統(tǒng)一的版本。

我認(rèn)為擴(kuò)展單體為微服務(wù)比直接構(gòu)建微服務(wù)更簡(jiǎn)單——

• 我們可以使用分析工具，并獲得瓶頸的合理近似值。
• 我們的團(tuán)隊(duì)可以輕松地（并且經(jīng)濟(jì)實(shí)惠地）設(shè)置運(yùn)行測(cè)試的登臺(tái)環(huán)境。
• 我們擁有整個(gè)系統(tǒng)及其依賴關(guān)系的單一視圖。
• 我們可以單獨(dú)測(cè)試單個(gè)模塊并驗(yàn)證性能假設(shè)。

跟蹤和可觀測(cè)性工具非常棒。但它們也會(huì)影響生產(chǎn)，有時(shí)還會(huì)產(chǎn)生噪音。當(dāng)我們?cè)噲D解決伸縮瓶頸或性能問題時(shí)，這些工具可能會(huì)讓設(shè)計(jì)者踩一些坑。

我們可以將Kubernetes與monolits一起使用，就像將其與微服務(wù)一起使用一樣有效。鏡像尺寸會(huì)更大（如果我們使用GraalVM這樣的工具，則可能不會(huì)太大）。有了這一點(diǎn)，我們可以跨區(qū)域復(fù)制monolith ，并提供與微服務(wù)相同的故障轉(zhuǎn)移行為。相當(dāng)多的開發(fā)人員將monolics部署到Lambdas。筆者不太喜歡這種方法，因?yàn)榉浅０嘿F。

5、單體的瓶頸問題：有解

但仍有一點(diǎn)是巨大的障礙：數(shù)據(jù)庫(kù)。由于微服務(wù)固有地具有多個(gè)獨(dú)立的數(shù)據(jù)庫(kù)，因此它們實(shí)現(xiàn)了巨大的規(guī)模。單體架構(gòu)通常與單個(gè)數(shù)據(jù)存儲(chǔ)一起工作。這通常是應(yīng)用程序的真正瓶頸。有多種方法可以擴(kuò)展現(xiàn)代數(shù)據(jù)庫(kù)。集群和分布式緩存是強(qiáng)大的工具，可以讓我們達(dá)到在微服務(wù)架構(gòu)中很難達(dá)到的性能水平。

在一個(gè)單體結(jié)構(gòu)中，也并不需要單個(gè)數(shù)據(jù)庫(kù)。例如：在使用Redis進(jìn)行緩存時(shí)，選擇使用SQL數(shù)據(jù)庫(kù)也是很常見的事情。但我們也可以為時(shí)間序列或空間數(shù)據(jù)使用單獨(dú)的數(shù)據(jù)庫(kù)。我們也可以使用單獨(dú)的數(shù)據(jù)庫(kù)來(lái)提高性能，盡管根據(jù)筆者經(jīng)驗(yàn)，這種情況從未發(fā)生過。將數(shù)據(jù)保存在同一數(shù)據(jù)庫(kù)中的好處是巨大的。

6、回歸單體的好處

事實(shí)上，這樣做有一個(gè)驚人的好處，我們可以在不依賴“最終一致性”的情況下完成交易。當(dāng)我們嘗試調(diào)試和復(fù)制分布式系統(tǒng)時(shí)，可能會(huì)遇到一個(gè)很難在本地復(fù)制的過渡狀態(tài)，甚至很難通過查看可觀測(cè)性數(shù)據(jù)來(lái)完全理解。

原始性能消除了大量網(wǎng)絡(luò)開銷。通過適當(dāng)調(diào)整的二級(jí)緩存，我們可以進(jìn)一步刪除80-90%的讀IO。在微服務(wù)中，要實(shí)現(xiàn)這一點(diǎn)要困難得多，而且可能不會(huì)刪除網(wǎng)絡(luò)調(diào)用的開銷。

正如我之前提到的，應(yīng)用程序的復(fù)雜性在微服務(wù)架構(gòu)中不會(huì)消失。我們只是把它搬到了另一個(gè)地方。所以從這個(gè)層面講，微服務(wù)并不算真正的進(jìn)步，因?yàn)樵诖诉^程中平白添加了許多移動(dòng)部件，增加了整體復(fù)雜性。因此，回歸更智能、更簡(jiǎn)單的統(tǒng)一架構(gòu)更有意義。

7、再看微服務(wù)的賣點(diǎn)

編程語(yǔ)言的選擇是微服務(wù)親和力的首要指標(biāo)之一。微服務(wù)的興起與Python和JavaScript的興起相關(guān)。這兩種語(yǔ)言非常適合小型應(yīng)用程序，對(duì)于較大型的應(yīng)用就不太適用了。

Kubernetes使得擴(kuò)展此類部署相對(duì)容易，因此為已經(jīng)增長(zhǎng)的趨勢(shì)增添了動(dòng)力。微服務(wù)也有一些相對(duì)快速的升降能力。這可以以更細(xì)粒度的方式控制成本。在這方面，微服務(wù)被出售給組織，作為降低成本的一種方式。

這并非完全沒有優(yōu)點(diǎn)。如果以前的服務(wù)器部署需要強(qiáng)大（昂貴）的服務(wù)器，那么這一論點(diǎn)可能有一定道理。這可能適用于極端使用的情況，比如：突然面臨非常高的負(fù)載，但隨后沒有堵塞。在這些情況下，可以從托管的Kubernetes提供商動(dòng)態(tài)（廉價(jià)）獲取資源。

微服務(wù)的主要賣點(diǎn)之一是組織調(diào)度方面。這使得各個(gè)敏捷團(tuán)隊(duì)能夠在不完全了解“大局”的情況下解決小問題。問題也在于此，這就會(huì)創(chuàng)造一種“單干”文化，讓每個(gè)團(tuán)隊(duì)都“自己做自己的事情”。在縮減規(guī)模的過程中，尤其是在代碼“腐爛”的情況下，問題更甚。系統(tǒng)可能仍能工作數(shù)年，但實(shí)際上無(wú)法維護(hù)。

8、互聯(lián)網(wǎng)建立在單體之上

為什么要離開呢

筆者組內(nèi)中的一個(gè)共識(shí)是，我們應(yīng)該始終從單體開始。它更容易構(gòu)建，如果我們選擇使用微服務(wù)，我們可以稍后將單體分解。

提及具體某個(gè)軟件相關(guān)的復(fù)雜性,我們討論單個(gè)模塊而不是單個(gè)應(yīng)用程序要更有意義些。二者在資源使用和財(cái)務(wù)浪費(fèi)上的差異是巨大的。在這個(gè)追求“降本”的時(shí)代，為什么人們還要不知變通地默認(rèn)構(gòu)建微服務(wù)，而不是動(dòng)態(tài)的模塊化單體架構(gòu)呢？

我們可以從這兩大“架構(gòu)陣營(yíng)”學(xué)到很多東西。誠(chéng)然，微服務(wù)為亞馬遜創(chuàng)造了奇跡。但公平地說，他們的云成本已包含在這個(gè)奇跡之中。所以，一位的搞微服務(wù)教條肯定是有問題的。

另一方面，互聯(lián)網(wǎng)是建立在單體之上的。它們中的大多數(shù)都不是模塊化的。兩者都有普遍適用的技術(shù)。因此，筆者看來(lái)，正確的選擇是構(gòu)建一個(gè)模塊化的單體結(jié)構(gòu)，先搭建好合適的身份驗(yàn)證基礎(chǔ)設(shè)施，如果我們想在未來(lái)轉(zhuǎn)向微服務(wù)，我們可以利用這些基礎(chǔ)設(shè)施來(lái)進(jìn)行解構(gòu)拆分。

9、后記

在設(shè)計(jì)應(yīng)用時(shí)，我們目前更多是面臨“二選一”的架構(gòu)選擇：?jiǎn)误w和微服務(wù)。它們二者通常被視為相反的方法。

在小型系統(tǒng)演進(jìn)過程中，有這樣一個(gè)不爭(zhēng)的事實(shí)：?jiǎn)误w應(yīng)用程序往往會(huì)隨著時(shí)間的推移而在架構(gòu)上降級(jí)，即使在其生命周期開始階段就定義其為架構(gòu)。隨著時(shí)間的推移，各種架構(gòu)的禁止事項(xiàng)會(huì)不知不覺地進(jìn)入項(xiàng)目，久而久之，系統(tǒng)變得更難改變，進(jìn)化性受到影響。

另一方面，微服務(wù)提供了更強(qiáng)的分離手段，但同時(shí)也帶來(lái)了許多復(fù)雜性，因?yàn)榧词箤?duì)于小型應(yīng)用程序，團(tuán)隊(duì)也必須應(yīng)對(duì)分布式系統(tǒng)的挑戰(zhàn)。

單體回歸，也是具體的有條件的回歸。我們看到，趨勢(shì)的改變，代表著某段時(shí)期具體任務(wù)或者目標(biāo)正在變化。出于目標(biāo)的變化，我們對(duì)于微服務(wù)和單體架構(gòu)的二選一的選擇問題，也不能再教條式的看待。

事物往往都在螺旋式的演進(jìn)，對(duì)于架構(gòu)而言，亦如是。

原文鏈接：https://dzone.com/articles/is-it-time-to-go-back-to-the-monolith