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

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

我有幸在這兩種方式的代碼庫中都工作過，而且它們都是很標準的形式。我傾向于采用微服務。我有我的理由，并且會在下面的內容中進行分享。首先，我們來談一下這兩種架構模式。

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

水平擴展

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

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

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

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

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

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

  
  

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

  
  

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

  
  

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

  
  

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

  
  

2 面向服務架構 到目前為止，在本文中，我都將面向服務和微服務視為可互換的術語。我認為它們是一回事兒，但是微服務這個詞容易讓人們認為每個服務都是微型的，這并不是這種風格的架構的要求。

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

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

  
  

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

  
  

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

  
  

• 進行擴展的時候不再局限于添加更多的機器來運行重復的單體應用，而是可以進行垂直擴展。

  
  

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

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

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

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

面向服務架構

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

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

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