互聯網 - 大數據

原文地址：http://martinfowler.com/articles/microservice-trade-offs.html
作者：Martin Fowler

很多開發團隊已經認識到 微服務架構比單體架構更優越。但是也有其他團隊感覺到這是一種消弱生產力的負擔。就像任何軟件架構，微服務架構同樣有利弊。為了能做出一個明智的選擇，你必須了解這些應用并將它們運用到你特定的環境中。

微服務的優勢

• 具有邊界的健壯模塊：有邊界的模塊化業務，可以隨著團隊規模的擴大而陸續增加。
  　　　　　　　　　　
  

• 獨立部署：服務的部署更加簡單容易，另外，因為每個微服務是獨立的，所以其中一個出問題不會影響到整個系統。
  　　　　　　　　　　
  

• 技術的多樣性：在微服務中，可以有一種以上的語言，開發框架，以及數據庫存儲相結合。

微服務的附加成本

• 分布式：分布式系統編程相對困難，因為遠程調用慢，所以可能總是會存在失敗的風險。
  　　　　　　　　　　
  

• 最終一致性：在分布式系統中，保持強一致性是非常困難的，所以必須要處理最終一致性。
  　　　　　　　　　　
  

• 操作復雜性：你需要一個經驗豐富的運營團隊來管理很多需要定時重新部署的服務。

具有邊界的健壯模塊

微服務最大的好處是對功能模塊的劃分。這是個既重要又奇怪的好處，因為理論上沒有理由來解釋為何微服務比單體架構有更強大的模塊劃分。

那到底什么是我說的模塊邊界。我想大多數人同意，將軟件劃分成多個模塊，非常好：彼此就可以分離解耦。如果我需要改變系統的一小部分，大多數的時候我只需要弄清楚這一小塊，然后做些改動，我們會發現小變動真的很容易。對于任何程序而言，好的模塊化結構非常有用，特別是當軟件的規模變大，模塊化會顯得格外重要。也許，它會變得更重要，因為團隊的規模也在增加。

提倡微服務，需要快速介紹一下 康威定律，該定律認為一個軟件系統的結構反映了團隊的溝通結構。對于較大的團隊，特別對于那些分散在各地的團隊，對軟件實施結構化顯得尤為重要，跨團隊之間的溝通與一個團隊內部溝通相比，將會變得不那么頻繁且更加正式。微服務允許每個團隊用類似的溝通模式來照看相對獨立的模塊單元。

正如我前面所說，沒有理由可以解釋為何一個單體系統不應該擁有一個良好的模塊化結構[1]。但是很多人都觀察到這似乎很少見，因此大雜燴成了最常見的架構模式。事實上單體架構這種固有的困惑，驅動一些團隊開始使用微服務架構。模塊的解耦能夠起作用，是因為模塊的邊界就是模塊之間引用的障礙。麻煩的是，一個單體系統，通常都很容易繞過障礙。這樣做，可能是構建功能時有用的技術捷徑，可是呢，如果廣泛運用這種方法，將削弱模塊化的結構和降低團隊的生產力。將模塊放入獨立的服務，這樣做使模塊的邊界更為牢固，使這種自殺式的解決方案更難實現。

耦合的重要部分是持久化的數據。微服務的關鍵特征是 去中心的數據管理，也就是說每個服務管理它自己的數據庫，其它的服務必須通過該服務的API來交互。這就會消除 集成數據庫，這是大系統非常討厭耦合的主要原因。

值得強調的是在一個單體系統中，使用模塊化完全可能，但是它需要紀律來保證。同樣地，你也可能得到微服務的大雜燴模式，但是對于本身已是微服務的架構，要犯這樣的錯還是不太容易的。在我看來，使用微服務，可以幫助你實現更好的模塊化。如果你對團隊紀律很有信心，那么可能會消除這一優勢，不過，隨著團隊的規模增加，保持紀律會變得越來越，這也就意味著維護模塊邊界將顯得更為重要性。

如果你不好好管理模塊的邊界，這個優勢就會變成障礙。這就是 單體優先策略的兩個主要原因之一，也是為何我更傾向于 較早使用微服務，你只能在一個領域了解得非常透徹。

但我現在不會在這方面做出警告。只有經過時間的洗禮，你才能真正講出要如何才能把一個系統的模塊化維護好。所以只有我們看到微服務系統已經運行好多年，才可以評估它是否會帶來更好的模塊化特性。而且，早期接納者更有才華，也就是說在我們能夠評估一般團隊構建的微服務系統的模塊化優勢之前，還有好幾年的延遲。所以與其和高水平的團隊比較成果，還不如比較那些已經使用單體架構的軟件帶來的變化，這是一個棘手的違背事實的評估。

所有我現在能做的，就是聽聽那些我認識的人，他們使用微服務架構的早期經驗。他們的判斷就是微服務能讓他們更容易去維護功能模塊。

有一個案例特別有意思。有一個團隊做了一個錯誤的決定，在一個不那么復雜的系統上面 使用微服務。后來這個項目碰到了問題，需要幫助，然后很多人就跑了進來。這方面，微服務還是有所幫助的，因為這個系統能夠吸引開發者的快速涌入，和單體架構相比，團隊更容易擴張。最終這個項目的進度大大超過使用單體架構的預期，使整個團隊趕上進度。當然也有負面的，和單體架構相比，微服務的方式耗費了更多的人力，但是微服務的架構能夠支持未來更大的規模。

如果你想要知道更多有關于如何構建微服務系統，Sam Newman的 這本書是很重要的資料。

獨立部署

微服務是DevOps革命后第一新的軟件架構。-- Neal Ford

模塊化和分布式系統的復雜性一直伴隨著我整個職業生涯中。但是有一件事情發生了明顯的變化，就是在過去的十年中，有關生產環境的發布。在二十世紀，生產環境的發布幾乎總是痛苦且罕見的事情，周末的白天或晚上部署一些能用的軟件。但是現在呢，熟練的團隊頻繁發布到生產環境，許多團隊實行 持續交付，使他們一天能夠在生產環境發布很多次。

這種轉變已經對軟件產業產生了深遠的影響，并與微服務運動深深交織在一起。當部分的小變化可能導致整個部署失敗，微服務終于被單體架構的部署難題所激發出來。微服務的一個關鍵原則是， 每個服務都是系統的一個組件，均可獨立部署。所以現在當你做出改變時，你只需要測試和部署一個小服務。如果你把它搞砸了，你不會把整個系統都搞砸。畢竟，事先對故障進行了設計，即使失敗了，你的組件也不應該停止其他部分的系統工作，盡管功能上有些退化。

這種關系是雙向的。由于許多微服務需要頻繁部署，統一部署行為顯得尤為重要。這就是為什么應用的快速部署和快速配置是 微服務的先決條件。對于任何以此為基礎的服務，你都需要做持續的交付。

持續交付的好處是減少了由想法變成軟件的時間。那么，團隊可以快速響應市場變化，并快于競爭對手先引入新的功能。

盡管許多人認為持續交付是使用微服務的一個原因，但值得注意的是，即使單體架構也可以持續交付。Facebook和Etsy是兩個最好的例子。還有一些嘗試微服務的例子，因為多個服務需要認真協調才能發布，因此無法獨立部署[2]。同時我也聽到很多人認為使用微服務能更容易做持續交付，我是不太相信模塊化可以使持續發布更容易，盡管它可以大大提高交付的速度。

技術的多樣性

由于每個微服務都是一個獨立的部署單元，你有相當的自由選擇需要的技術。微服務可以用不同的語言，使用不同的庫，并使用不同的數據存儲方式。這使得團隊可以選擇合適的工具來工作，有些語言和庫更適合某些類型的問題。

技術多樣性通常以最佳的工具為中心進行討論，但往往微服務最大的好處確是更令人頭疼的版本問題。在單體架構中你可以只使用一個單一的版本庫，這種情況經常導致升級出現問題。系統的一部分可能需要升級，來實現使用它的新功能，但不能因為升級而中斷系統的另一部分。處理庫的版本問題是其中的一個難題，因為隨著代碼庫的增大，難度會呈指數級增長。

這里有一個風險，有這么多的技術多樣性，開發團隊會被壓倒。我所認識的大多數組織都鼓勵有限的一組技術。這種鼓勵是通過提供共同的工具來支持監測，使它更容易將服務穩定在一個小的通用環境中。

不要低估了支持使用新技術的價值。用單體架構系統，早期對語言和框架的決定是很難逆轉的。經過十年左右，這些的決定可能會限制團隊并使團隊陷入尷尬的技術境地。微服務讓團隊嘗試新工具，并逐步一次遷移系統的一個服務，使新老技術有所關聯。

分布式

微服務采用分布式系統來提高模塊化。但是分布式軟件有一個主要的缺陷，就是分布式系統本身。一旦你開始玩分布式系統，你就會碰到一堆復雜的問題。 我不認為微服務社區對分布式系統所帶來的成本沒有概念，但是復雜性也確實存在。

首先是性能。這時候，你不得不以一種不常見的方式，看著進程內的函數調用轉變成性能的瓶頸，遠程調用是很慢的。如果你的服務調用了很多遠程服務，這些遠程服務本身也要調用了另外一些遠程服務，這些響應時間加起來，就會帶來很恐怖的延遲特征。

當然你有辦法減少延遲。首先，你可以增加調用的粒度，減少調用的數目。這會使你的編程模式變得復雜，使得你必須想清楚如何批量處理跨服務交互。由于你必須調用至少一次這些所有合作的服務，因此到目前為止，你能做的就這么多了。

第二種方法就是使用異步通信。如果六個服務異步并行調用，延遲只會是那個最慢的調用，而不是所有調用延遲的總和。這大大改善了性能，但也帶來了認知成本。異步編程很難，你很難用好它，而且很難調試。但我聽到的大多數微服務的例子，都需要異步來獲得預期的性能。

速度之后就是可靠性的問題。你期望in-process函數調用能夠成功，可是一個遠程調用可能在任何時間失敗。在很多的微服務中，甚至有很多的潛在的故障點。明智的開發人員知道這些， 為可能發生的故障事先設計。你為異步協作做的方案，也適應于故障處理，還可提高服務的彈性。然而，這些補償仍然不夠，仍然有著額外的復雜性，你需要弄明白每一個遠程調用失敗的后果。

這就是分布式計算最主要的 兩個難題。

對于這個問題，還有一些要注意的地方。首先，很多這類的問題出現在單體架構規模擴充的時候。很少有單體架構可以真正獨立運行，通常是跟其他系統一起，這些系統大部分是遺留系統。和這些系統通過網絡進行交互，同樣會碰到這些類似的問題。這就是為何很多人都傾向于更快轉移到微服務架構，來處理遠程系統的交互問題。這個問題，同樣也和經驗有關系，更熟練的團隊更有能力處理分布式特性所帶來的問題。

當然，分布式特性永遠都是一個成本。我總是不太愿意打分布式這張牌，因為想到很多很多人，因低估這些難題而太快地引入了分布式系統。

最終一致性

我想你應該知道，網站的更新著實需要一點耐心。更新某一個東西之后刷新屏幕，可是更新的東西還沒有出現。你等了一兩分鐘后，它出現了。

這是一個非常惱人的可用性問題，幾乎可以肯定是由于最終的一致性造成的。你的更新被節點P收到，可是呢，你的請求卻被另一個節點G處理。直到節點G從節點P那兒得到更新之前，你一直處于數據不一致的狀態。最終，它會變成一致的，但在這之前，你會疑惑是不是有什么東西弄錯了。

像這樣的不一致是令人惱火的，但他們可以更嚴重。業務邏輯會停滯在對不一致的信息上做出決策，當這種事發生時，在不一致的窗口關閉之前，也難以診斷出到底什么出了問題。

微服務帶來了最終一致性的問題，是因為他們堅持對去中心的數據管理，這種堅持值得稱贊。單體架構，你可以一次更新一堆東西。微服務則需要多個資源的更新和分布式的處理，這確實頭疼。所以現在，開發者需要意識到一致性問題，在寫任何代碼之前，弄明白如何檢測數據的不一致。

單體架構在這些問題上同樣不能全身而退。隨著系統的增長，更需要使用緩存來提高性能，緩存失效是 另一個困難的問題。大多數應用程序需要脫機鎖，以避免長期的數據庫事務處理。外部系統需要更新，不能與事務管理器協調。商業流程往往更具寬容的不一致性，因為企業對可用性要求更高（業務流程，一直以來對 CAP理論都是一種直覺上的理解）。

和其他分布式問題一樣，單體架構也不能完全避免非一致性問題，但它們受到的困擾不多，特別當它們規模很小時。

操作復雜性

能夠迅速部署獨立的小單位，是項目開發的一大福音，但由于幾十個應用現在轉變為幾百個小的微服務，給運維額外增加了負擔。許多組織會發現，處理這樣一個迅速變化的工具，有一種令人望而卻步的難度。

這加強了持續交付的重要性。而持續交付是單體架構一項有價值的技能，也是一個微服務所必須的。如果沒有自動化協作，持續交付也無法處理那么多的服務。運維的復雜性也是由管理這些服務和監控的需求的增加而增加。運維的復雜性對單體架構的應用也有所幫助，不過對微服務來說，這是必然的。

微服務的支持者指出，由于每個服務更小，所以更容易理解。但風險在于，復雜性并沒有消除，它只是轉移到服務之間的相互聯系中。這會增加運維的復雜性，比如調試、跨服務的難度。良好的服務邊界的選擇將減少這個問題，但如果用錯地方，則更糟糕。

處理這種運維復雜度，需要一個新的技能和工具——重點是技能。工具仍然是不成熟的，但我的直覺告訴我，即使有更好的工具，微服務還得靠高技能。

然而，對技能和工具的需求不是解決運維復雜性最難的部分。想要高效地解決，你還需要引入一個DevOps文化：開發者和運維之間的緊密合作，每個人都參與軟件交付。文化變革是困難的，尤其是在更大和更老的組織中。如果你不改變這個技能和文化，單體架構的應用只會受到阻礙，而微服務應用則會受到創傷。

其他因素

在我看來，上面的因素是作為首要權衡指標來考慮的。這里要討論的一些事情，我認為就沒那么重要了。

微服務的支持者們經常說服務更容易擴展：一個服務得到大量的負載，你就可以擴展，而不用對整個應用進行擴展。然而，我努力回憶起一個過往的經驗報告，它使我相信，和 千篇一律的應用復制相比，它實際上是更有效地進行選擇性擴展。

微服務允許你隔離敏感數據以及給數據增加安全性。此外，在保證微服務間交互安全的前提下，微服務難以被攻入。安全問題越來越重要，這可以成為使用微服務的主要考慮因素。即使不用微服務，對于單體架構的系統創建隔離服務來處理敏感數據，也是很常見的。

批評者說微服務應用的測試要比單體架構的應用難度更大。雖然這個真正的困難部分來自于分布式應用程序的復雜性，但還是有 好的方法可以測試微服務。在這里，最重要的是要有紀律，要認真測試，單體架構和微服務應用的測試方法的區別只是第二位的。

總結

任何有關架構的綜述文章都會受到 一般性建議的限制。所以讀一篇這樣的文章不能幫助你做決定，但這樣的文章可以幫助你確保考慮到你應該考慮的各種因素。這里對不同的系統，成本和收益做了不同的權重，甚至成本收益會被顛倒過來（在更復雜的系統中強模塊化更好，但對于一個簡單的系統，這就增加了障礙），你所做的任何決定取決于環境中使用條件，評估哪些因素最重要，以及它們如何影響你的特定評估條件。此外，我們對微服務架構經驗相對有限。在一個系統成熟后，你通常只會在這個體系中決定相應的架構。我們還沒有很多關于長期運行的微服務架構的實例。

單體架構和微服務并不是簡單的二選一。兩者都是模糊的定義，意味著大多數系統都將在一個模糊的邊界區域。當然也還有其他系統，不適合這兩個類別的。大多數人，包括我自己，討論微服務時用單體架構作對比，這是因為它們更常見，但我們必須記住，還是有系統不屬于這兩類的。我認為，單體架構和微服務是架構設計領域重要的兩部分。它們值得被討論，因為它們存在有趣的特性，以及有用的討論，但是沒有合適的架構師可以對它們在架構設計領域進行一個全面的區分。

總結起來，微服務的好處：微服務提高了生產效率，但同時也帶來了復雜性。所以如果你可以用單體架構管理好你的系統，那么就無需微服務。

對微服務的討論不應該讓我們忘記了更重要的問題，驅動軟件項目成功和失敗的重要因素。軟因素如團隊中人的素質，以及他們如何彼此合作，與領域專家的溝通能力，這都會對是否使用微服務有更加的影響。在純技術層面上來講，更重要的是把重點放在干凈的代碼、完善的測試，并持續關注架構的演化進步。

腳注

[1] 有些人認為"單體架構"是一種侮辱，總是意味著很糟糕的模塊化結構。在微服務世界，大多數人不這樣做，他們將單體架構定義為將整個應用構建為一個獨立的單元。當然，微服務倡導者相信大多數單體架構最終會變成大雜燴，但我不知道有誰會認為建立一個結構良好的單體架構毫無可能。

[2] 能獨立部署服務是 微服務定義的一部分。所以這么說還是有道理的，即必須在其部署時協調服務的架構不是微服務架構。也可以這么說，很多團隊嘗試微服務架構而陷入麻煩是因為他們最終不得不協調多個服務來部署。