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

模塊化

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

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

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

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

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

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

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

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

所有我現(xiàn)在能做的，就是聽聽那些我認識的人，他們使用微服務(wù)架構(gòu)的早期經(jīng)驗。他們的判斷就是微服務(wù)能讓他們更容易去維護功能模塊。

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

如果你想要知道更多有關(guān)于如何構(gòu)建微服務(wù)系統(tǒng)，Sam Newman的這本書是很重要的資料。

分布式特性

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

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

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

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

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

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

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

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

#p#

最終一致性

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

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

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

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

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

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

獨立部署

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

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

這種關(guān)系是雙向的。由于許多微服務(wù)需要頻繁部署，統(tǒng)一部署行為顯得尤為重要。這就是為什么應(yīng)用的快速部署和快速配置是微服務(wù)的先決條件。對于任何以此為基礎(chǔ)的服務(wù)，你都需要做持續(xù)的交付。

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

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

運維的復(fù)雜性

能夠迅速部署獨立的小單位，是項目開發(fā)的一大福音，但由于幾十個應(yīng)用現(xiàn)在轉(zhuǎn)變?yōu)閹装賯€小的微服務(wù)，給運維額外增加了負擔。許多組織會發(fā)現(xiàn)，處理這樣一個迅速變化的工具，有一種令人望而卻步的難度。

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

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

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

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

技術(shù)的多樣性

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

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

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

不要低估了支持使用新技術(shù)的價值。用單體架構(gòu)系統(tǒng)，早期對語言和框架的決定是很難逆轉(zhuǎn)的。經(jīng)過十年左右，這些的決定可能會限制團隊并使團隊陷入尷尬的技術(shù)境地。微服務(wù)讓團隊嘗試新工具，并逐步一次遷移系統(tǒng)的一個服務(wù)，使新老技術(shù)有所關(guān)聯(lián)。

#p#

其他因素

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

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

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

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

總結(jié)

任何有關(guān)架構(gòu)的綜述文章都會受到一般性建議的限制。所以讀一篇這樣的文章不能幫助你做決定，但這樣的文章可以幫助你確保考慮到你應(yīng)該考慮的各種因素。這里對不同的系統(tǒng)，成本和收益做了不同的權(quán)重，甚至成本收益會被顛倒過來(在更復(fù)雜的系統(tǒng)中強模塊化更好，但對于一個簡單的系統(tǒng)，這就增加了障礙)，你所做的任何決定取決于環(huán)境中使用條件，評估哪些因素最重要，以及它們?nèi)绾斡绊懩愕奶囟ㄔu估條件。此外，我們對微服務(wù)架構(gòu)經(jīng)驗相對有限。在一個系統(tǒng)成熟后，你通常只會在這個體系中決定相應(yīng)的架構(gòu)。我們還沒有很多關(guān)于長期運行的微服務(wù)架構(gòu)的實例。

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

總結(jié)起來，微服務(wù)的好處：微服務(wù)提高了生產(chǎn)效率，但同時也帶來了復(fù)雜性。所以如果你可以用單體架構(gòu)管理好你的系統(tǒng)，那么就無需微服務(wù)。

對微服務(wù)的討論不應(yīng)該讓我們忘記了更重要的問題，驅(qū)動軟件項目成功和失敗的重要因素。軟因素如團隊中人的素質(zhì)，以及他們?nèi)绾伪舜撕献鳎c領(lǐng)域?qū)＜业臏贤芰?，這都會對是否使用微服務(wù)有更加的影響。在純技術(shù)層面上來講，更重要的是把重點放在干凈的代碼、完善的測試，并持續(xù)關(guān)注架構(gòu)的演化進步。

腳注

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

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

致謝

Brian Mason、Chris Ford、Rebecca Parsons、Rob Miles、Scott Robinson、Stefan Tilkov、Steven Lowe以及Unmesh Joshi和我一起討論這篇文章的草稿。

原文鏈接：http://www.dockone.io/article/492