使用微服務(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