作者 | Goksu Toprak，譯者 | 張衛(wèi)濱，策劃 | 萬(wàn)佳
來自：架構(gòu)頭條 關(guān)于采用微服務(wù)架構(gòu)還是單體架構(gòu)，最近業(yè)界有不少相關(guān)的討論。本文作者 Goksu Toprak 分析了兩種架構(gòu)風(fēng)格的優(yōu)勢(shì)和適用場(chǎng)景。
本文最初發(fā)表于 Station Wagon Full of Tapes 網(wǎng)站，經(jīng)原作者 Goksu Toprak 授權(quán)由 InfoQ 中文站翻譯分享。
圍繞該使用面向服務(wù)的架構(gòu)還是該使用單體架構(gòu)的討論已經(jīng)持續(xù)很長(zhǎng)時(shí)間了。大多數(shù)團(tuán)隊(duì)確實(shí)選擇了微服務(wù)這條道路，因?yàn)檫@是目前的“行業(yè)標(biāo)準(zhǔn)”。但是，單體設(shè)計(jì)依然有其用途和空間，尤其是在某個(gè)想法或產(chǎn)品的早期階段。
我有幸在這兩種方式的代碼庫(kù)中都工作過，而且它們都是很標(biāo)準(zhǔn)的形式。我傾向于采用微服務(wù)。我有我的理由，并且會(huì)在下面的內(nèi)容中進(jìn)行分享。首先，我們來談一下這兩種架構(gòu)模式。
1 單體架構(gòu) 它們已經(jīng)滅絕了嗎？沒有，而且它們也不應(yīng)該滅絕。如果你正在開發(fā)的應(yīng)用的代碼庫(kù)可以分組成為一個(gè)包，進(jìn)行一次性的部署，并且能夠在負(fù)載均衡器背后進(jìn)行復(fù)制（水平擴(kuò)展），那么就沒有必要引入復(fù)雜的微服務(wù)設(shè)計(jì)。
水平擴(kuò)展
當(dāng)然，從理論上來講，單體設(shè)計(jì)并不意味著無(wú)法實(shí)現(xiàn)擁有單一責(zé)任的服務(wù)設(shè)計(jì)。實(shí)際上，因?yàn)樵趩误w架構(gòu)中，所有的模塊都很易于訪問，隨著時(shí)間的推移，界限很變得非常模糊，如果需要的話，將系統(tǒng)拆分為更小的部分將會(huì)變得越來越難。
根據(jù)我的經(jīng)驗(yàn)，單體架構(gòu)在早期的迭代中速度會(huì)比較快，但是隨著時(shí)間的推移，變更的迭代速度會(huì)變得越來越慢。對(duì)于如今的初創(chuàng)公司和小規(guī)模團(tuán)隊(duì)來講，這個(gè)特點(diǎn)使得單體架構(gòu)依然是一個(gè)很有價(jià)值的應(yīng)用開發(fā)方式。
如果業(yè)務(wù)一切進(jìn)展順利的話，現(xiàn)在你需要每秒鐘為大量的請(qǐng)求提供服務(wù)（因?yàn)槟愕漠a(chǎn)品有越來越多的客戶），準(zhǔn)確的說，在要求應(yīng)用 99.9% 的時(shí)間都能正常訪問的情況下，單體設(shè)計(jì)的局限性就開始出現(xiàn)了。
Airbnb 必須要經(jīng)歷這樣的變化，來自 Airbnb 工程團(tuán)隊(duì)的 Jessica Tai 曾經(jīng)做過名為“大遷移：從單體到面向服務(wù)”的演講。
許多團(tuán)隊(duì)在達(dá)到某種狀態(tài)時(shí)，都會(huì)面臨相同模式的問題：
-
持續(xù)部署慢得令人痛苦，因?yàn)槊總€(gè)變更都需要構(gòu)建整個(gè)包并重新部署。
-
緩慢的持續(xù)部署導(dǎo)致了緩慢的持續(xù)集成，這會(huì)導(dǎo)致在每次變更后運(yùn)行的測(cè)試數(shù)量不斷減少。
-
曾經(jīng)的快速代碼庫(kù)變成了一個(gè)雷區(qū)，即便是微小的變更也是如此，因?yàn)楣こ倘藛T無(wú)法知道他們所做的變更的影響是什么。
-
不可能抽象出特定的服務(wù)來管理基礎(chǔ)設(shè)施，數(shù)據(jù)庫(kù)連接、管理以及模式變化都是耦合的。
-
在部署的時(shí)候，無(wú)法使用像 scratch 這樣的容器鏡像（雖然這一條在問題清單上的位置比較靠后，但是考慮到我過去在 Docker 方面的工作，這是我最看重的一點(diǎn)）。
2 面向服務(wù)架構(gòu) 到目前為止，在本文中，我都將面向服務(wù)和微服務(wù)視為可互換的術(shù)語(yǔ)。我認(rèn)為它們是一回事兒，但是微服務(wù)這個(gè)詞容易讓人們認(rèn)為每個(gè)服務(wù)都是微型的，這并不是這種風(fēng)格的架構(gòu)的要求。
該結(jié)構(gòu)風(fēng)格的優(yōu)勢(shì)恰好對(duì)應(yīng)著單體架構(gòu)局限性。這并不是一個(gè)巧合。當(dāng)然，這種風(fēng)格的設(shè)計(jì)帶來的影響不僅僅是積極的，它們對(duì)基礎(chǔ)設(shè)施設(shè)計(jì)的要求在增加。分布式系統(tǒng)實(shí)現(xiàn)起來并不容易。但是，面向服務(wù)架構(gòu)的優(yōu)點(diǎn)是多于缺點(diǎn)的：
-
更快的部署，每次部署之后都會(huì)有更高的測(cè)試執(zhí)行率。
-
藍(lán) - 綠更新會(huì)很容易（相對(duì)來講），這會(huì)限制每個(gè)服務(wù)的停機(jī)時(shí)間。
-
工程師對(duì)他們的變更的爆炸半徑會(huì)更有信心，因?yàn)樗麄冎滥K的依賴圖。
-
進(jìn)行擴(kuò)展的時(shí)候不再局限于添加更多的機(jī)器來運(yùn)行重復(fù)的單體應(yīng)用，而是可以進(jìn)行垂直擴(kuò)展。
通過上面列出的每種方式的優(yōu)點(diǎn)和缺點(diǎn)，有些讀者可能已經(jīng)有了自己的判斷。然而，正如我在文章開頭所提到的那樣，面向服務(wù)解鎖了單體架構(gòu)一種無(wú)法實(shí)現(xiàn)的擴(kuò)展策略，那就是
組織性擴(kuò)展（organizational scaling）。
有個(gè)很好的問題就是，當(dāng)一個(gè)產(chǎn)品需要超過數(shù)百名工程師來一起工作時(shí)，隨著接觸同一代碼庫(kù)的人員規(guī)模的增加，保持所有的組織有信心且靈活地進(jìn)行創(chuàng)新確實(shí)是一個(gè)挑戰(zhàn)。不要與 mono-repo（指的是將項(xiàng)目的代碼放到一個(gè) Git 倉(cāng)庫(kù)的做法——譯者注）相混淆。mono-repo 并不要求采用單一架構(gòu)。
在單體架構(gòu)中，團(tuán)隊(duì)經(jīng)常會(huì)被阻塞到代碼審查中，因?yàn)楹苋菀捉佑|到其他團(tuán)隊(duì)擁有的部分代碼。任何的代碼變更都需要完整的構(gòu)建，這會(huì)造成團(tuán)隊(duì)之間相互耦合。如果團(tuán)隊(duì) A 有一個(gè)失敗的 Selenium 測(cè)試，那團(tuán)隊(duì) B 想要部署與之不相關(guān)的服務(wù)變更，憑什么要被阻止呢？(他們不應(yīng)如此。)
每個(gè)服務(wù)由只關(guān)注該服務(wù)的團(tuán)隊(duì)及其消費(fèi)者所擁有，當(dāng)涉及到建立一個(gè)強(qiáng)大的測(cè)試基礎(chǔ)設(shè)施，以及與指標(biāo)和日志進(jìn)行集成時(shí)，這種架構(gòu)方式也會(huì)產(chǎn)生更大的影響。團(tuán)隊(duì)能夠更加自信地部署新的變化，因?yàn)樗麄兦宄卦O(shè)定了邊界，一些東西如果出現(xiàn)問題的爆炸半徑也能精確測(cè)量了，因?yàn)閳F(tuán)隊(duì)能夠測(cè)量一切。
面向服務(wù)架構(gòu)
這種類型的架構(gòu)設(shè)計(jì)交流的前提一般是以后端軟件開發(fā)作為目標(biāo)的。
不過，前端開發(fā)“最近”也有一個(gè)重大的變化，即前端該如何架構(gòu)。其核心是，就像微服務(wù)一樣，它們給出了一個(gè)實(shí)現(xiàn)組織化擴(kuò)展的機(jī)會(huì)。這種變化就是“基于組件的架構(gòu)”，這種方式隨著 React 已經(jīng)成為了主流。公司構(gòu)建自己的設(shè)計(jì)系統(tǒng)不僅僅是為了提高產(chǎn)品開發(fā)的速度，他們也希望能夠借此擴(kuò)展組織，實(shí)現(xiàn)更低的耦合。
當(dāng)我被問到這兩種方式該選擇哪種時(shí)，我一般傾向于回答“視情況而定”，隨后我經(jīng)常會(huì)得到一個(gè)不滿意的表情。盡管如此，在有利于組織規(guī)模擴(kuò)展方面，面向服務(wù)架構(gòu)的優(yōu)勢(shì)是不容忽視的。
下載文檔
