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

模塊化

微服務(wù)***的好處是對功能模塊的劃分。這是個(gè)既重要又奇怪的好處，因?yàn)槔碚撋蠜]有理由來解釋為何微服務(wù)比單體架構(gòu)有更強(qiáng)大的模塊劃分。

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

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

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

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

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

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

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

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

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

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

分布式特性

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

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

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

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

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

這就是分布式計(jì)算最主要的兩個(gè)難題。

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

當(dāng)然，分布式特性永遠(yuǎn)都是一個(gè)成本。我總是不太愿意打分布式這張牌，因?yàn)橄氲胶芏嗪芏嗳耍虻凸肋@些難題而太快地引入了分布式系統(tǒng)。

#p#

最終一致性

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

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

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

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

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

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

獨(dú)立部署

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

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

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

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

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

運(yùn)維的復(fù)雜性

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

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

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

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

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

技術(shù)的多樣性

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

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

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

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

#p#

其他因素

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

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

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

總結(jié)

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

單體架構(gòu)和微服務(wù)并不是簡單的二選一。兩者都是模糊的定義，意味著大多數(shù)系統(tǒng)都將在一個(gè)模糊的邊界區(qū)域。當(dāng)然也還有其他系統(tǒng)，不適合這兩個(gè)類別的。大多數(shù)人，包括我自己，討論微服務(wù)時(shí)用單體架構(gòu)作對比，這是因?yàn)樗鼈兏Ｒ姡覀儽仨氂涀。€是有系統(tǒng)不屬于這兩類的。我認(rèn)為，單體架構(gòu)和微服務(wù)是架構(gòu)設(shè)計(jì)領(lǐng)域重要的兩部分。它們值得被討論，因?yàn)樗鼈兇嬖谟腥さ奶匦裕约坝杏玫挠懻摚菦]有合適的架構(gòu)師可以對它們在架構(gòu)設(shè)計(jì)領(lǐng)域進(jìn)行一個(gè)全面的區(qū)分。

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

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

腳注

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

[2] 能獨(dú)立部署服務(wù)是微服務(wù)定義的一部分。所以這么說還是有道理的，即必須在其部署時(shí)協(xié)調(diào)服務(wù)的架構(gòu)不是微服務(wù)架構(gòu)。也可以這么說，很多團(tuán)隊(duì)嘗試微服務(wù)架構(gòu)而陷入麻煩是因?yàn)樗麄冏罱K不得不協(xié)調(diào)多個(gè)服務(wù)來部署。

致謝

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

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