微服務(wù)就是一個(gè)大泥潭！

使用微服務(wù)往往是有代價(jià)的，而這種代價(jià)往往會(huì)被低估。

原文鏈接：https://code-held.com/2022/07/28/microservices/

(資料圖片)

作者 | Marcus Held

譯者 | 彎月 責(zé)編 | 屠敏

出品 | CSDN（ID：CSDNnews）

在過(guò)去的幾年里，我曾圍繞微服務(wù)這個(gè)話題采訪過(guò)數(shù)百個(gè)人，很多人都自豪地講述了他們使用微服務(wù)架構(gòu)開(kāi)發(fā)項(xiàng)目的故事。然而，無(wú)需太多提問(wèn)就可以看出他們發(fā)射了一枚大火箭，最后卻只是干掉了一只老鼠。

微服務(wù)很難。每個(gè)接觸過(guò)這類(lèi)架構(gòu)的人都有著痛苦的經(jīng)歷。終有一天，你會(huì)被復(fù)雜性淹沒(méi)，而且你不得不對(duì)架構(gòu)進(jìn)行多次重構(gòu)。我很納悶，為什么這種架構(gòu)對(duì)開(kāi)發(fā)人員如此有吸引力？然后，我想起十年前自己也被這種框架所吸引。

大多人的共同經(jīng)歷是，他們不得不面對(duì)一個(gè)遺留下來(lái)的單體系統(tǒng)，而且整個(gè)代碼庫(kù)都是一團(tuán)糟。遇到這種情況很令人沮喪。實(shí)現(xiàn)需要很長(zhǎng)時(shí)間，編寫(xiě)測(cè)試很乏味甚至幾乎不可能，理解代碼也很困難，bug 堆積如山，部署也不可靠，每次代碼變更都會(huì)引發(fā)問(wèn)題。重構(gòu)遺留代碼似乎是不可能的，而且一想到這個(gè)問(wèn)題就會(huì)讓你覺(jué)得頭疼，甚至徹夜難眠。

這個(gè)時(shí)候，微服務(wù)就會(huì)變得非常具有吸引力。那一刻，小型、可管理、分離的代碼庫(kù)會(huì)帶給你極大的安全感和解脫感。

但是，使用微服務(wù)也是有代價(jià)的，而且往往容易被低估。

弊端1：無(wú)法正確切分領(lǐng)域

只有當(dāng)你能夠正確切分領(lǐng)域時(shí)，使用微服務(wù)才有效。然而，領(lǐng)域的劃分非常艱難。你需要知道自己構(gòu)建的是什么，但往往大多數(shù)時(shí)候我們并不是特別清楚。完全綁定到一個(gè)領(lǐng)域，會(huì)導(dǎo)致系統(tǒng)的靈活性降低，而這恰恰與你實(shí)際的期望背道而馳。

在切分領(lǐng)域時(shí)，有可能你還不清楚產(chǎn)品需求。將來(lái)難免會(huì)出現(xiàn)一個(gè)功能，迫使兩個(gè)服務(wù)糾纏在一起，這就導(dǎo)致它們屬于同一個(gè)領(lǐng)域，卻還是分布式的。

弊端2：復(fù)雜性

雖然剛開(kāi)始的時(shí)候，微服務(wù)的架構(gòu)看起來(lái)非常簡(jiǎn)單。架構(gòu)師非常確定這種架構(gòu)不會(huì)被打破，而且對(duì)于團(tuán)隊(duì)來(lái)說(shuō)，只需要維護(hù)一個(gè)小型代碼庫(kù)，感覺(jué)很舒服。然而到了部署服務(wù)時(shí)，情況就會(huì)發(fā)生變化。你需要協(xié)調(diào)一切。儀表板、監(jiān)控系統(tǒng)、日志聚合器、部署、CI 作業(yè)、警報(bào)、文檔……而且你引入這些服務(wù)只是因?yàn)槟愕募軜?gòu)有這種需求。你需要分布式隊(duì)列、共享緩存、共享數(shù)據(jù)庫(kù)、服務(wù)發(fā)現(xiàn)、多個(gè)負(fù)載均衡器、動(dòng)態(tài)路由器、API 網(wǎng)關(guān)、中央配置服務(wù)器……

于是，代碼泥沼變成了基礎(chǔ)設(shè)施泥沼。優(yōu)步這樣的大公司經(jīng)歷過(guò)慘痛的教訓(xùn)后，終于意識(shí)到了這一點(diǎn)：

弊端3：過(guò)早優(yōu)化

幾十年來(lái)，我們將軟件分割成了各種服務(wù)，只不過(guò)我們沒(méi)有稱(chēng)它們?yōu)椤拔⒎?wù)”。我們拆分應(yīng)用程序主要有兩個(gè)原因。

首先，這種拆分對(duì)組織來(lái)說(shuō)有意義。

很明顯，我們應(yīng)該建立兩個(gè)獨(dú)立的團(tuán)隊(duì)分別負(fù)責(zé)客戶(hù)關(guān)系管理工具和電子商務(wù)平臺(tái)，盡管這兩個(gè)平臺(tái)有時(shí)候需要相互交流。這已經(jīng)是一個(gè)面向服務(wù)的架構(gòu)。為了實(shí)現(xiàn)銷(xiāo)售產(chǎn)品的單一業(yè)務(wù)目標(biāo)，我們需要兩項(xiàng)服務(wù)。只不過(guò)我們從未稱(chēng)其為微服務(wù)架構(gòu)。

其次，為了性能。

根據(jù)我的經(jīng)驗(yàn)，受這個(gè)原因影響的軟件只有1%。如果只有幾百個(gè)用戶(hù)，使用垂直擴(kuò)展就可以了。我們開(kāi)發(fā)的系統(tǒng)有數(shù)以萬(wàn)計(jì)的并發(fā)用戶(hù)，這些用戶(hù)與系統(tǒng)進(jìn)行了大量交互，但我們?nèi)匀荒軌虼怪睌U(kuò)展。

我們想要什么？

我們發(fā)現(xiàn)了一個(gè)問(wèn)題：遺留系統(tǒng)這個(gè)巨大的泥潭。可惜微服務(wù)架構(gòu)并不是解決這個(gè)問(wèn)題的正確方法。你需要的是模塊，正確的模塊，因?yàn)槟K使得我們很難越界，而且可以根據(jù)需要輕松、獨(dú)立地部署模塊。這個(gè)概念本身并不新穎，但很多人往往無(wú)法正確實(shí)施。

十年前，我想要模塊，卻采納了微服務(wù)架構(gòu)，現(xiàn)在是時(shí)候結(jié)束這種過(guò)度設(shè)計(jì)了。

《2022-2023 中國(guó)開(kāi)發(fā)者大調(diào)查》重磅啟動(dòng)，歡迎掃描下方二維碼，參與問(wèn)卷調(diào)研，更有 iPad 等精美大禮等你拿！

? 兩萬(wàn)字長(zhǎng)文，史上最全 C++ 年度總結(jié)！

? 在 MacOS 上運(yùn)行 Docker 太慢！

? 為了忘卻的紀(jì)念——2022 Linux 內(nèi)核十大技術(shù)革新功能 | 年終盤(pán)點(diǎn)

責(zé)任編輯：Rex_19