著名的推特論戰(zhàn)：Microservices vs. Monolithic

【編者按】Microservices和Monolithic的工程思路選擇上一直存在著分歧，那么在數(shù)據(jù)體積暴增的當(dāng)下，究竟哪一個(gè)才能符合實(shí)時(shí)、敏捷等新時(shí)代應(yīng)用需求？這里我們看HighScalability創(chuàng)始人Todd Hoff對(duì)近日“Microservices App vs. Monolithic App”推特論戰(zhàn)的總結(jié)。

---

免費(fèi)訂閱“CSDN大數(shù)據(jù)”微信公眾號(hào)，實(shí)時(shí)了解最新的大數(shù)據(jù)進(jìn)展！

CSDN大數(shù)據(jù)，專注大數(shù)據(jù)資訊、技術(shù)和經(jīng)驗(yàn)的分享和討論，提供Hadoop、Spark、Imapala、Storm、HBase、MongoDB、Solr、機(jī)器學(xué)習(xí)、智能算法等相關(guān)大數(shù)據(jù)觀點(diǎn)，大數(shù)據(jù)技術(shù)，大數(shù)據(jù)平臺(tái)，大數(shù)據(jù)實(shí)踐，大數(shù)據(jù)產(chǎn)業(yè)資訊等服務(wù)。

---

以下為譯文：

曾經(jīng)有一場(chǎng)著名的推特論戰(zhàn)，爭(zhēng)論的主題是“Consensus Best Way to Structure Systems”。競(jìng)爭(zhēng)雙方是Microservices App和Monolithic App。

Microservices大旗下是Netflix與ThougtWorks兩大王國(guó)，擁護(hù)者分別是 Adrian Cockcroft 和 Sam Newman先生。

Etsy王國(guó)則揮動(dòng)著Monolithic大旗，其擁護(hù)者是John Allspaw 先生。

除此之外，來(lái)自Digital Ocean王國(guó)和其他一些獨(dú)立區(qū)域的勇士也出現(xiàn)在這場(chǎng)論戰(zhàn)中。論戰(zhàn)的冠軍將獲得“開發(fā)者的高度關(guān)注和幸運(yùn)女神的青睞”。

最早的論戰(zhàn)是Cockcroft先生展開的，他參加了很多論戰(zhàn)：

adrian cockcroft ?@adrianco 3月5號(hào)

#qconlondon的Etsy讓我很清楚地意識(shí)到為什么Monolithicapp要滅亡了。使用Microservices來(lái)獲得持續(xù)的可擴(kuò)展的部署吧。

Neil Bartlett ?@nbartlett 3月5號(hào)

@adrianco是的，1000個(gè)支持。盡管人們?cè)贛icroservices的部署方面可能意見不同。 @AnneWoof

adrian cockcroft ?@adrianco 3月5號(hào)

@nbartlett @AnneWoof Monolithic app迫使人們做同樣的決定。Microservices解放了大家，大家可以按需求進(jìn)行創(chuàng)新或優(yōu)化。

John Allspaw ?@allspaw 3月5號(hào)

?@adrianco你在這個(gè)問(wèn)題上缺乏批判性思維，因?yàn)槟悴荒芟氲剿械囊嫣帯?

Sam Newman ?@samnewman 3月5號(hào)

@allspaw @adrianco通常，在如何解決問(wèn)題方面，Microservices給你更多選擇。

John Allspaw ?@allspaw  3月5號(hào)

@samnewman還有更多的限制 @adrianco

John Allspaw ?@allspaw 3月5號(hào)

@samnewman有些時(shí)候，更少的選擇會(huì)帶來(lái)更多的機(jī)會(huì)。少數(shù)的易懂的工具和模式會(huì)帶來(lái)好處。 @adrianco

John Allspaw ?@allspaw 3月5號(hào)

@samnewman Microservices也有一個(gè)別名――“我想堅(jiān)持自己的方式，不用討論我的決定的利弊”。 @adrianco

Sam Newman ?@samnewman 3月5號(hào)

@allspaw @adrianco它可以給我們更多自己自由――將我們從標(biāo)準(zhǔn)化的狀態(tài)轉(zhuǎn)為可以自由選擇的狀態(tài)。

Sam Newman ?@samnewman 3月5號(hào)

@allspaw @adrianco服務(wù)的標(biāo)準(zhǔn)化是很重要的（監(jiān)控，整合）。局限思維？給團(tuán)隊(duì)自主權(quán)。

Sam Newman ?@samnewman 3月5號(hào)

@allspaw @adrianco這些都基于對(duì)組織中的“好成員”有一個(gè)好的描述。

Mark Burgess ?@markburgess_osl 3月5號(hào)

@samnewman @allspaw @adrianco關(guān)鍵是你如何測(cè)量這些方法在用戶/供應(yīng)商體驗(yàn)和目標(biāo)適用性上的差異？

Mark Burgess ?@markburgess_osl 3月5號(hào)

@samnewman @allspaw @adrianco一旦你確定誰(shuí)可以從什么獲益后，你可以考慮一個(gè)加權(quán)優(yōu)化政策。

Mark Burgess ?@markburgess_osl 3月5號(hào)

@samnewman @allspaw @adrianco這是一個(gè)非常有趣的討論！

adrian cockcroft ?@adrianco 3月6號(hào)

@allspaw我在Netfix工作的頭三年，Netfix是一個(gè)Monolithic  app。這個(gè)團(tuán)隊(duì)有100多個(gè)工程師，大家的關(guān)注點(diǎn)都很分散。

adrian cockcroft ?@adrianco 3月6號(hào)

@samnewman @allspaw中心計(jì)劃和協(xié)商的事情不會(huì)擴(kuò)展，其創(chuàng)新速度也不如高信任度的自由和責(zé)任。

John Allspaw ?@allspaw 3月6號(hào)

@adrianco @samnewman在Etsy，我們的架構(gòu)和流程有高信任度、自由和責(zé)任。Conway的條例不能稱之為條例。@samnewman

John Allspaw ?@allspaw 3月6號(hào)

@adrianco我想說(shuō)的是你忽略了一點(diǎn)――你關(guān)于Etsy的言論可能是錯(cuò)的。

John Allspaw ?@allspaw  3月6號(hào)

@adrianco誰(shuí)說(shuō)Etsy是中心計(jì)劃的？你鬧鐘的Etsy開發(fā)模型是有缺陷的。

adrian cockcroft ?@adrianco 3月6號(hào)

@allspaw抱歉，我不確定你覺得我說(shuō)的哪一部分是錯(cuò)誤的。我在討論擴(kuò)展一個(gè)像Etsy和Facebook一樣的monolith的替代選項(xiàng)。

John Allspaw ?@allspaw 3月6號(hào)

@adrianco我沒有聽到“替代選項(xiàng)”，我只聽到“不能運(yùn)行”，“滅亡”和“Microservices在各方面都很優(yōu)秀”。如果我說(shuō)錯(cuò)了，我向你道歉。

adrian cockcroft ?@adrianco  3月6號(hào)

@allspaw昨天我去參加了Etsy大會(huì)。Php語(yǔ)言的Monolithic導(dǎo)致功能不能用其他語(yǔ)言實(shí)施，如clojure

John Allspaw ?@allspaw 3月6號(hào)

@adrianco 是的。而且Clojure語(yǔ)言的Microservices也不具有php的優(yōu)勢(shì)。工程是在多種影響之中的權(quán)衡。

John Allspaw ?@allspaw 3月6號(hào)

@adrianco我已經(jīng)在這工作4年多了，我想說(shuō)，你考慮的不全面。：）

adrian cockcroft ?@adrianco 3月6號(hào)

@allspaw我想來(lái)自Etsy的伙計(jì)應(yīng)該談一談使用monolith的好處，但我不認(rèn)為增加獨(dú)立隊(duì)伍會(huì)阻礙創(chuàng)新。

Alan ?@AlanMorrison 3月6號(hào)

@adrianco @allspaw （鏈接 http://bit.ly/1nha966 ）正確的服務(wù)水平應(yīng)該在微觀和宏觀之間，如一個(gè)過(guò)程中的步驟，對(duì)不對(duì)？

John Allspaw ?@allspaw 3月6號(hào)

@adrianco好主意。

Adam Thody ?@thody 3月6號(hào)

@allspaw @adrianco先生們，這是一場(chǎng)挺好的，但冗長(zhǎng)的、過(guò)時(shí)的辯論。軟件和組織中應(yīng)該避免教條主義。

John Allspaw ?@allspaw 3月6號(hào)

@adrianco 以下是我的想法的整理（鏈接https://gist.github.com/anonymous/9388472 … /cc） @kellan

• Monolithic不同應(yīng)用間架構(gòu)不同，具體情況需要具體分析。
• Microservice也是，應(yīng)用和架構(gòu)要具體問(wèn)題具體分析。
• Microservices和Monolithic架構(gòu)都有優(yōu)點(diǎn)。
• 組織應(yīng)該充分利用這些優(yōu)點(diǎn)，避免缺點(diǎn)。
• 商業(yè)的成功是考慮使用何種開發(fā)解決方案的要考慮的很大因素。
• 所有的益處和工作隊(duì)伍都是環(huán)境敏感的。也就是說(shuō)它們是由所在組織的技術(shù)和社會(huì)構(gòu)造的。
• 路徑依賴是一點(diǎn)。歷史影響著、也說(shuō)明了組織中的架構(gòu)決定和升級(jí)。
• 模式的存在是為了告知實(shí)踐，不是為了指示實(shí)踐。一味的依附于架構(gòu)模式可能會(huì)導(dǎo)致實(shí)踐中忽略文化環(huán)境的風(fēng)險(xiǎn)。
• 架構(gòu)模式會(huì)擴(kuò)展、收縮、升級(jí)和改變來(lái)適應(yīng)組織所要達(dá)到的權(quán)衡。

Kevin Behr ?@kevinbehr 3月6號(hào)

@allspaw @adrianco很有趣。我讀了這個(gè)帖子，還把“我熱愛多樣性和適應(yīng)性”大聲念了出來(lái)。

Sam Newman ?@samnewman 3月6號(hào)

@allspaw @adrianco我發(fā)現(xiàn)conway定律更多的是定義什么是對(duì)的，而不是什么是錯(cuò)的。我把它當(dāng)做指導(dǎo)，而不是硬性規(guī)定。

Sam Newman ?@samnewman 3月6號(hào)

@allspaw @adrianco信任實(shí)現(xiàn)自治是關(guān)鍵――有很多種方法可以達(dá)到這一點(diǎn)。我們追求的是正確的架構(gòu)。

Sam Newman ?@samnewman 3月6號(hào)

@allspaw @adrianco 當(dāng)需要標(biāo)準(zhǔn)化時(shí)，我試圖使標(biāo)準(zhǔn)化容易、透明，如提供標(biāo)準(zhǔn)化工具。

adrian cockcroft ?@adrianco 3月6號(hào)

@allspaw @kellan 我同意，我還要補(bǔ)充一點(diǎn)：一個(gè)Microservice可以看做是一組小monolith的和。

adrian cockcroft ?@adrianco  3月6號(hào)

@samnewman @allspaw反轉(zhuǎn)conways定律的應(yīng)用有助于影響搭建的架構(gòu)。

Steve Smith ?@AgileSteveSmith 3月6號(hào)

@samnewman我喜歡看到標(biāo)準(zhǔn)逐漸成為成功的副產(chǎn)品，成為未來(lái)改進(jìn)的基礎(chǔ)。/@allspaw @adrianco

Anthony Elizondo ?@complex 3月6號(hào)

@adrianco @allspaw @kellan 基于你們的觀點(diǎn)，消費(fèi)者看到的是Microservice，供應(yīng)商看到的是monolith。

Sam Newman ?@samnewman 3月6號(hào)

@AgileSteveSmith @allspaw @adrianco我在內(nèi)部工具鏈和服務(wù)模板中增量變化中發(fā)現(xiàn)了這一點(diǎn)。

Sam Newman ?@samnewman 3月6號(hào)

@AgileSteveSmith @allspaw @adrianco 基本同意，不過(guò)有些事情需要預(yù)先決定。如，避免連鎖故障的措施。

如你所見，這里存在很多關(guān)于這兩個(gè)模式的討論，但似乎都沒有掐中要害，然后就變成顧左右而言其他。也許有一天這樣的辯論還會(huì)繼續(xù)，但也可能存在大同小異的辯論內(nèi)容。下面談?wù)劄槭裁葱枰@種論戰(zhàn)。

Monolithic APP被視為Anti-Pattern

Etsy的開發(fā)、部署和整合版塊寫道：“每天在Etsy有大約150個(gè)工程師部署單個(gè)Monolithic應(yīng)用六十多次。”Monolithic應(yīng)用的 “所有所需的邏輯都在一個(gè)“單元”（一個(gè)jar，一個(gè)應(yīng)用，一個(gè)資源庫(kù)）。

作為一個(gè)公司，Etsy很成功，Etsy可不是什么小站點(diǎn)，2013年2月，Etsy有：14.9億次頁(yè)面瀏覽，169個(gè)主題出售，價(jià)值9470萬(wàn)的商品出售，2200多萬(wàn)個(gè)商品，8000000多個(gè)活躍商鋪。

Etsy還示范了如何搭建一個(gè)好站點(diǎn)，正確的做事：持續(xù)的集成；平均每個(gè)開發(fā)組一個(gè)VMs；按鈕式部署；良好監(jiān)控；開發(fā)者在第一天部署站點(diǎn)；GitHub；Chef；用IRC控制發(fā)布管理；儀表盤；不使用源代碼控制分支，總是在主分支有效地部署。那么，Etsy怎么還在使用Monolithic？

這種懷疑是因?yàn)镸onolithic應(yīng)用使用Anti-Pattern。關(guān)于這一點(diǎn)，請(qǐng)參見《Monolithic架構(gòu)無(wú)法擴(kuò)展》。這篇文章的主旨是：擴(kuò)展指的是大的開發(fā)者組織成功的修改、測(cè)試、發(fā)布代碼的能力，指的不是系統(tǒng)每秒可處理的請(qǐng)求數(shù)量。

俗話說(shuō)的好：廚師太多反而做不好湯。

我們都知道，要做好湯，我們需要把大廚房分為很多小廚房，每個(gè)小廚房都有自己的廚師、人員、貨物供應(yīng)和設(shè)備，饑餓的消費(fèi)者協(xié)調(diào)各個(gè)分離的廚師做出美味的湯。然后得到好湯，這將我們引向了Microservice。

Microservice很棒

解決Monolithic應(yīng)用的一個(gè)問(wèn)題是將應(yīng)用分為多個(gè)Microservice。Matin Fowler解釋道：

2011年5月，威尼斯的一個(gè)軟件架構(gòu)工作坊提到了“microserverice”這一術(shù)語(yǔ)，這一術(shù)語(yǔ)描述了參與者們正在探索的通用架構(gòu)類型。2012年5月，這個(gè)組織決定“Microservice”是最合適的名字。2012年3月，James在波蘭以案例學(xué)習(xí)的形式展示了其中的一些觀點(diǎn)，同時(shí)期，F(xiàn)red George也闡述了這些觀點(diǎn)。Adrian Cockcroft將這種方法描述為“細(xì)紋理SOA”，是網(wǎng)絡(luò)規(guī)模類型的先驅(qū)。

Sir Cockroft 先生在DevOps咖啡店的一次訪談提到了Microservice的嚴(yán)格定義。概況如下：

• 對(duì)速度的優(yōu)化促使開發(fā)者將代碼整合到Monolithic app。讓一個(gè)Monolithic app工作很難。當(dāng)一個(gè)功能出問(wèn)題需要返工時(shí)，同期發(fā)布的所有功能都需要返工。
• 當(dāng)多于100個(gè)開發(fā)者工作于同一個(gè)項(xiàng)目時(shí)，就會(huì)達(dá)到使用Monolithic方法的閾值，搭建一個(gè)項(xiàng)目會(huì)變得越來(lái)越難。只有10個(gè)開發(fā)者時(shí)Monolithic方法可行。
• 當(dāng)多于100個(gè)開發(fā)者時(shí)，Netfix的DVD app就出現(xiàn)問(wèn)題了。于是他們就想把a(bǔ)pp分為單獨(dú)的片。最終他們采用了Microservice。Microservice旨在滿足速度和敏捷度的需求，通過(guò)Microservice，團(tuán)隊(duì)可實(shí)現(xiàn)獨(dú)立部署。
• 與SOA不同，Microservice是松耦合的。如果升級(jí)一個(gè)服務(wù)需要其它服務(wù)的協(xié)作，那么這個(gè)服務(wù)不是松耦合。如果你的app需要Google、Facebook和Foursquare  API的升級(jí)，那么這個(gè)app不是松耦合的。
• 如果一個(gè)服務(wù)出了問(wèn)題，并且導(dǎo)致了連鎖反應(yīng)，相關(guān)的服務(wù)也開始出問(wèn)題，那么這就是個(gè)大問(wèn)題。我們需要搭建隔板、斷路器和其它企業(yè)類型模式。我們?cè)诖罱ǚ烙酱a。
• 瀑布式的問(wèn)題是花費(fèi)時(shí)間太長(zhǎng)，反饋路徑太不連貫。問(wèn)題具體化給了其它組。在瀑布式方法中，當(dāng)問(wèn)題出現(xiàn)時(shí)，最早的團(tuán)隊(duì)通常已經(jīng)解散了。
• 持續(xù)交付，數(shù)天或數(shù)周調(diào)試代碼，在產(chǎn)品中運(yùn)行代碼可以產(chǎn)生一個(gè)立即的反饋回路。如果開發(fā)者代碼寫的不好，服務(wù)會(huì)立刻出問(wèn)題，開發(fā)者可以得到立即的反饋。
• 我們還需要包括失敗的波及范圍。去耦合的Microservice意味著更高的可用性。如果一個(gè)服務(wù)失敗了，我們很容易識(shí)別和包括這個(gè)識(shí)別。我們可以很容易的判斷出誰(shuí)跟這個(gè)服務(wù)有關(guān)，進(jìn)而確保問(wèn)題不會(huì)擴(kuò)散到其它服務(wù)。
• 這和緊密相連的企業(yè)模型很不相同，在這些模型中運(yùn)維的兄弟們告訴開發(fā)者一切都很好，開發(fā)者不需要為了宕機(jī)的事情編程。告訴開發(fā)者，任何事情在任何時(shí)刻都可能宕機(jī)，這是與開發(fā)者合作的另一種方式。開發(fā)者需要做更多的工作，但最終產(chǎn)品更早進(jìn)入市場(chǎng)，產(chǎn)品也更可靠。因?yàn)殚_發(fā)者自己運(yùn)行產(chǎn)品，所以他們?cè)谂c其他組開交接會(huì)議上所花的時(shí)間更少，因此他們有更多的時(shí)間編程。

我們所期待的目標(biāo)是很好的。避免防御式編程，去耦合，關(guān)注點(diǎn)分離，迅速部署，錯(cuò)誤隔離，快速反饋回路，開發(fā)者責(zé)任制，專注做好一件事情的app，獨(dú)立升級(jí)路徑，優(yōu)化的版本控制，團(tuán)隊(duì)間分離……這些都是我們的目標(biāo)。

問(wèn)題是：Microservice是實(shí)現(xiàn)這些目標(biāo)的唯一辦法么？即使不是，Microservice是實(shí)現(xiàn)這些目標(biāo)的最好辦法么？

對(duì)于第一點(diǎn)，發(fā)布非獨(dú)立功能時(shí)，如果一個(gè)功能失敗了，所有的功能都要返工。這是分支和粒度發(fā)布策略（release granularity policies）的架構(gòu)。Erst推測(cè)可以通過(guò)不緩存功能的方式來(lái)避免這個(gè)問(wèn)題，功能一旦完成就進(jìn)行發(fā)布。一天持續(xù)發(fā)布很多次意味著一天發(fā)布了很多變化，這些發(fā)布是獨(dú)立可復(fù)原的，因此就不會(huì)有什么問(wèn)題。功能標(biāo)識(shí)是另一種應(yīng)對(duì)產(chǎn)品功能問(wèn)題的辦法，不過(guò)沒那么好。

盡管Microservice是解決返工問(wèn)題的一個(gè)解決方案，但這不是唯一的解決方案，也不是最好的解決方案，Microservice只是這場(chǎng)論戰(zhàn)中反復(fù)提到的一個(gè)模式。

服務(wù)不是什么新東西

很顯然Microservice處于領(lǐng)先地位。故事是不是還有另一面呢？我同意Microservice是對(duì)已有服務(wù)的再造。我們一定需要一個(gè)新詞么？我認(rèn)為這可以讓溝通更明晰，因此可以。那么服務(wù)的內(nèi)容有什么變化呢？一個(gè)新的綁定需要新的詞語(yǔ)。這就像語(yǔ)言方法進(jìn)行版本控制。10年前Microservice的詞也是不同的，所以我們需要用一個(gè)新詞來(lái)描述現(xiàn)在。

真正的對(duì)比應(yīng)該是和Unix和我們的老朋友/etc/services對(duì)比，etc/services中有很多獨(dú)立的服務(wù)，例如nfs、ntp、smtp、whois、echo、time、ftp、quote和 hostnames。這些服務(wù)的復(fù)雜度各不相同，有些很簡(jiǎn)單，有些很復(fù)雜。這些服務(wù)都是獨(dú)立的，因此它們可以都運(yùn)行在同一臺(tái)機(jī)器上，不需要類似于VM的容器。神奇吧！

服務(wù)是怎么創(chuàng)建的？閱讀W.Richard Stevens的著作，使用本地TCP/IP和線程庫(kù)創(chuàng)建自己的信息handler、格式和協(xié)議。在此之上你可以搭建Actor，狀態(tài)機(jī)處理器，消息代理，發(fā)布和訂閱機(jī)制，計(jì)數(shù)器handler，線程池，工作序列和高級(jí)CPU調(diào)度算法。或者你可以使用雷系A(chǔ)CE的框架幫助你。

很多服務(wù)都是按上述描述搭建的，它們性能很快，不需要HTTP、網(wǎng)絡(luò)服務(wù)器或任何其他現(xiàn)代的“改進(jìn)”。在移動(dòng)領(lǐng)域，HTTP絕不是助力。因此服務(wù)總是在工作，沒有什么理由去換新。

捍衛(wèi)monolith―如上所述，因此：

Monolith總是工作的。一個(gè)有任何復(fù)雜形式的服務(wù)通常也有復(fù)雜的現(xiàn)場(chǎng)和內(nèi)部結(jié)構(gòu)，因?yàn)榉?wù)是請(qǐng)求會(huì)話和響應(yīng)會(huì)話的端點(diǎn)。這意味著服務(wù)的內(nèi)部可以很復(fù)雜，需要很大的團(tuán)隊(duì)開發(fā)這些內(nèi)容，需要嚴(yán)格的延遲控制和高可用性。

我們所看到的是復(fù)雜是保守的。都是你自己的代碼時(shí)，不會(huì)因?yàn)楹?jiǎn)單的把一切都隔離到墻后面而導(dǎo)致復(fù)雜。復(fù)雜在什么地方。只有本質(zhì)簡(jiǎn)單的簡(jiǎn)單才是真的簡(jiǎn)單，否則簡(jiǎn)單只是一種抽象的說(shuō)法，大家很快就會(huì)識(shí)破。

去耦合和關(guān)注點(diǎn)分離的優(yōu)點(diǎn)都可以在代碼庫(kù)中實(shí)現(xiàn)，如果你不能讓復(fù)雜的代碼工作，你可以查看代碼結(jié)構(gòu)，編程語(yǔ)言的選擇，程序員，源代碼控制策略，分支策略，故障修復(fù)策略，發(fā)布策略和搭建和部署系統(tǒng)。不要一下子就斷定是Monolith的問(wèn)題。

例如，一直以來(lái)去耦合都是通過(guò)庫(kù)機(jī)制實(shí)現(xiàn)的。我知道這是軟件工程，不是算法，請(qǐng)屈尊和我一起從軟件工程的角度看問(wèn)題吧。如果代碼庫(kù)分為了獨(dú)立的庫(kù)，有著清晰地接口，那么來(lái)自世界各地的上百個(gè)人都可以獨(dú)立的工作于這些庫(kù)。是的，庫(kù)可以作為分離的產(chǎn)品放入源代碼樹，任何需要這些產(chǎn)品的工程都可以使用這些產(chǎn)品。這些產(chǎn)品有自己的發(fā)布策略，故障追蹤等。接口必須保證真實(shí)有效，就像服務(wù)接口一樣。如果接口變化了，那么另一個(gè)版本的庫(kù)可以創(chuàng)建，就像一個(gè)服務(wù)。每個(gè)庫(kù)可以單獨(dú)測(cè)試，就像一個(gè)服務(wù)。每個(gè)團(tuán)隊(duì)都可以使用自己的流程和策略進(jìn)行開發(fā)，就像一個(gè)服務(wù)。

不同的組件是如何在流程中協(xié)作的呢？

流程中的內(nèi)部代碼應(yīng)該和將所有庫(kù)組件聚集起來(lái)、安裝、配置、管理所經(jīng)歷的引導(dǎo)順序差不多。

所有運(yùn)行代碼的事項(xiàng)都必須這么做。Microservices一定有內(nèi)部的方式來(lái)解決內(nèi)部和外部的服務(wù)引用，以依賴順序開啟服務(wù)，啟動(dòng)時(shí)配置服務(wù)，運(yùn)行時(shí)重新配置服務(wù)，處理失敗，處理HA，使用度量監(jiān)控等。

當(dāng)OS啟動(dòng)時(shí)，OS也做同樣的事情，OS上運(yùn)行的每個(gè)流程也做同樣的事情。每個(gè)服務(wù)也做同樣的事情。每種情況下為達(dá)到目標(biāo)調(diào)整的是機(jī)制而不是模式本身。每種情況都受制于自身的困難，這些困難不會(huì)藏置于抽象層后。

Monolith不能做的是支持不同語(yǔ)言的開發(fā)，因?yàn)楸仨氁獦?gòu)建一個(gè)圖形。不過(guò)這是要評(píng)估的權(quán)衡，不是一個(gè)強(qiáng)烈的反對(duì)理由。

因此，Microservices運(yùn)動(dòng)目標(biāo)是完美無(wú)缺。實(shí)現(xiàn)這些目標(biāo)的機(jī)制比支持者預(yù)想的靈活。可能成為Big Ball of Mud 。許多敏捷/TDD/極限編程都是管理代碼熵的一種方法，服務(wù)也可以通過(guò)同樣的方法，形成自己的Ball of Mud。一個(gè)有良好軟件工程支持的Monolithic代碼庫(kù)可以良好工作，Etsy就是如此。

原文鏈接： The Great Microservices Vs Monolithic Apps Twitter Melee （翻譯/蔡仁君 責(zé)編/仲浩）