究竟是該采用面向服務(wù)結(jié)構(gòu)，還是單體結(jié)構(gòu)

作者 | Goksu Toprak，譯者 | 張衛(wèi)濱，策劃 | 萬佳來自：架構(gòu)頭條 關(guān)于采用微服務(wù)架構(gòu)還是單體架構(gòu)，最近業(yè)界有不少相關(guān)的討論。本文作者 Goksu Toprak 分析了兩種架構(gòu)風(fēng)格的優(yōu)勢和適用場景。 本文最初發(fā)表于 Station Wagon Full of Tapes 網(wǎng)站，經(jīng)原作者 Goksu Toprak 授權(quán)由 InfoQ 中文站翻譯分享。

圍繞該使用面向服務(wù)的架構(gòu)還是該使用單體架構(gòu)的討論已經(jīng)持續(xù)很長時間了。大多數(shù)團(tuán)隊確實選擇了微服務(wù)這條道路，因為這是目前的“行業(yè)標(biāo)準(zhǔn)”。但是，單體設(shè)計依然有其用途和空間，尤其是在某個想法或產(chǎn)品的早期階段。

我有幸在這兩種方式的代碼庫中都工作過，而且它們都是很標(biāo)準(zhǔn)的形式。我傾向于采用微服務(wù)。我有我的理由，并且會在下面的內(nèi)容中進(jìn)行分享。首先，我們來談一下這兩種架構(gòu)模式。

1 單體架構(gòu) 它們已經(jīng)滅絕了嗎？沒有，而且它們也不應(yīng)該滅絕。如果你正在開發(fā)的應(yīng)用的代碼庫可以分組成為一個包，進(jìn)行一次性的部署，并且能夠在負(fù)載均衡器背后進(jìn)行復(fù)制（水平擴展），那么就沒有必要引入復(fù)雜的微服務(wù)設(shè)計。

水平擴展

當(dāng)然，從理論上來講，單體設(shè)計并不意味著無法實現(xiàn)擁有單一責(zé)任的服務(wù)設(shè)計。實際上，因為在單體架構(gòu)中，所有的模塊都很易于訪問，隨著時間的推移，界限很變得非常模糊，如果需要的話，將系統(tǒng)拆分為更小的部分將會變得越來越難。

根據(jù)我的經(jīng)驗，單體架構(gòu)在早期的迭代中速度會比較快，但是隨著時間的推移，變更的迭代速度會變得越來越慢。對于如今的初創(chuàng)公司和小規(guī)模團(tuán)隊來講，這個特點使得單體架構(gòu)依然是一個很有價值的應(yīng)用開發(fā)方式。

如果業(yè)務(wù)一切進(jìn)展順利的話，現(xiàn)在你需要每秒鐘為大量的請求提供服務(wù)（因為你的產(chǎn)品有越來越多的客戶），準(zhǔn)確的說，在要求應(yīng)用 99.9% 的時間都能正常訪問的情況下，單體設(shè)計的局限性就開始出現(xiàn)了。

Airbnb 必須要經(jīng)歷這樣的變化，來自 Airbnb 工程團(tuán)隊的 Jessica Tai 曾經(jīng)做過名為“大遷移：從單體到面向服務(wù)”的演講。

許多團(tuán)隊在達(dá)到某種狀態(tài)時，都會面臨相同模式的問題：

• 持續(xù)部署慢得令人痛苦，因為每個變更都需要構(gòu)建整個包并重新部署。

  
  

• 緩慢的持續(xù)部署導(dǎo)致了緩慢的持續(xù)集成，這會導(dǎo)致在每次變更后運行的測試數(shù)量不斷減少。

  
  

• 曾經(jīng)的快速代碼庫變成了一個雷區(qū)，即便是微小的變更也是如此，因為工程人員無法知道他們所做的變更的影響是什么。

  
  

• 不可能抽象出特定的服務(wù)來管理基礎(chǔ)設(shè)施，數(shù)據(jù)庫連接、管理以及模式變化都是耦合的。

  
  

• 在部署的時候，無法使用像 scratch 這樣的容器鏡像（雖然這一條在問題清單上的位置比較靠后，但是考慮到我過去在 Docker 方面的工作，這是我最看重的一點）。

  
  

2 面向服務(wù)架構(gòu) 到目前為止，在本文中，我都將面向服務(wù)和微服務(wù)視為可互換的術(shù)語。我認(rèn)為它們是一回事兒，但是微服務(wù)這個詞容易讓人們認(rèn)為每個服務(wù)都是微型的，這并不是這種風(fēng)格的架構(gòu)的要求。

該結(jié)構(gòu)風(fēng)格的優(yōu)勢恰好對應(yīng)著單體架構(gòu)局限性。這并不是一個巧合。當(dāng)然，這種風(fēng)格的設(shè)計帶來的影響不僅僅是積極的，它們對基礎(chǔ)設(shè)施設(shè)計的要求在增加。分布式系統(tǒng)實現(xiàn)起來并不容易。但是，面向服務(wù)架構(gòu)的優(yōu)點是多于缺點的：

• 更快的部署，每次部署之后都會有更高的測試執(zhí)行率。

  
  

• 藍(lán) - 綠更新會很容易（相對來講），這會限制每個服務(wù)的停機時間。

  
  

• 工程師對他們的變更的爆炸半徑會更有信心，因為他們知道模塊的依賴圖。

  
  

• 進(jìn)行擴展的時候不再局限于添加更多的機器來運行重復(fù)的單體應(yīng)用，而是可以進(jìn)行垂直擴展。

  
  

通過上面列出的每種方式的優(yōu)點和缺點，有些讀者可能已經(jīng)有了自己的判斷。然而，正如我在文章開頭所提到的那樣，面向服務(wù)解鎖了單體架構(gòu)一種無法實現(xiàn)的擴展策略，那就是 組織性擴展（organizational scaling）。

有個很好的問題就是，當(dāng)一個產(chǎn)品需要超過數(shù)百名工程師來一起工作時，隨著接觸同一代碼庫的人員規(guī)模的增加，保持所有的組織有信心且靈活地進(jìn)行創(chuàng)新確實是一個挑戰(zhàn)。不要與 mono-repo（指的是將項目的代碼放到一個 Git 倉庫的做法——譯者注）相混淆。mono-repo 并不要求采用單一架構(gòu)。

在單體架構(gòu)中，團(tuán)隊經(jīng)常會被阻塞到代碼審查中，因為很容易接觸到其他團(tuán)隊擁有的部分代碼。任何的代碼變更都需要完整的構(gòu)建，這會造成團(tuán)隊之間相互耦合。如果團(tuán)隊 A 有一個失敗的 Selenium 測試，那團(tuán)隊 B 想要部署與之不相關(guān)的服務(wù)變更，憑什么要被阻止呢？(他們不應(yīng)如此。)

每個服務(wù)由只關(guān)注該服務(wù)的團(tuán)隊及其消費者所擁有，當(dāng)涉及到建立一個強大的測試基礎(chǔ)設(shè)施，以及與指標(biāo)和日志進(jìn)行集成時，這種架構(gòu)方式也會產(chǎn)生更大的影響。團(tuán)隊能夠更加自信地部署新的變化，因為他們清楚地設(shè)定了邊界，一些東西如果出現(xiàn)問題的爆炸半徑也能精確測量了，因為團(tuán)隊能夠測量一切。

面向服務(wù)架構(gòu)

這種類型的架構(gòu)設(shè)計交流的前提一般是以后端軟件開發(fā)作為目標(biāo)的。

不過，前端開發(fā)“最近”也有一個重大的變化，即前端該如何架構(gòu)。其核心是，就像微服務(wù)一樣，它們給出了一個實現(xiàn)組織化擴展的機會。這種變化就是“基于組件的架構(gòu)”，這種方式隨著 React 已經(jīng)成為了主流。公司構(gòu)建自己的設(shè)計系統(tǒng)不僅僅是為了提高產(chǎn)品開發(fā)的速度，他們也希望能夠借此擴展組織，實現(xiàn)更低的耦合。

當(dāng)我被問到這兩種方式該選擇哪種時，我一般傾向于回答“視情況而定”，隨后我經(jīng)常會得到一個不滿意的表情。盡管如此，在有利于組織規(guī)模擴展方面，面向服務(wù)架構(gòu)的優(yōu)勢是不容忽視的。