著名的推特論戰：Microservices vs. Monolithic

【編者按】Microservices和Monolithic的工程思路選擇上一直存在著分歧，那么在數據體積暴增的當下，究竟哪一個才能符合實時、敏捷等新時代應用需求？這里我們看HighScalability創始人Todd Hoff對近日“Microservices App vs. Monolithic App”推特論戰的總結。

---

免費訂閱“CSDN大數據”微信公眾號，實時了解最新的大數據進展！

CSDN大數據，專注大數據資訊、技術和經驗的分享和討論，提供Hadoop、Spark、Imapala、Storm、HBase、MongoDB、Solr、機器學習、智能算法等相關大數據觀點，大數據技術，大數據平臺，大數據實踐，大數據產業資訊等服務。

---

以下為譯文：

曾經有一場著名的推特論戰，爭論的主題是“Consensus Best Way to Structure Systems”。競爭雙方是Microservices App和Monolithic App。

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

Etsy王國則揮動著Monolithic大旗，其擁護者是John Allspaw 先生。

除此之外，來自Digital Ocean王國和其他一些獨立區域的勇士也出現在這場論戰中。論戰的冠軍將獲得“開發者的高度關注和幸運女神的青睞”。

最早的論戰是Cockcroft先生展開的，他參加了很多論戰：

adrian cockcroft ?@adrianco 3月5號

#qconlondon的Etsy讓我很清楚地意識到為什么Monolithicapp要滅亡了。使用Microservices來獲得持續的可擴展的部署吧。

Neil Bartlett ?@nbartlett 3月5號

@adrianco是的，1000個支持。盡管人們在Microservices的部署方面可能意見不同。 @AnneWoof

adrian cockcroft ?@adrianco 3月5號

@nbartlett @AnneWoof Monolithic app迫使人們做同樣的決定。Microservices解放了大家，大家可以按需求進行創新或優化。

John Allspaw ?@allspaw 3月5號

?@adrianco你在這個問題上缺乏批判性思維，因為你不能想到所有的益處。

Sam Newman ?@samnewman 3月5號

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

John Allspaw ?@allspaw  3月5號

@samnewman還有更多的限制 @adrianco

John Allspaw ?@allspaw 3月5號

@samnewman有些時候，更少的選擇會帶來更多的機會。少數的易懂的工具和模式會帶來好處。 @adrianco

John Allspaw ?@allspaw 3月5號

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

Sam Newman ?@samnewman 3月5號

@allspaw @adrianco它可以給我們更多自己自由――將我們從標準化的狀態轉為可以自由選擇的狀態。

Sam Newman ?@samnewman 3月5號

@allspaw @adrianco服務的標準化是很重要的（監控，整合）。局限思維？給團隊自主權。

Sam Newman ?@samnewman 3月5號

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

Mark Burgess ?@markburgess_osl 3月5號

@samnewman @allspaw @adrianco關鍵是你如何測量這些方法在用戶/供應商體驗和目標適用性上的差異？

Mark Burgess ?@markburgess_osl 3月5號

@samnewman @allspaw @adrianco一旦你確定誰可以從什么獲益后，你可以考慮一個加權優化政策。

Mark Burgess ?@markburgess_osl 3月5號

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

adrian cockcroft ?@adrianco 3月6號

@allspaw我在Netfix工作的頭三年，Netfix是一個Monolithic  app。這個團隊有100多個工程師，大家的關注點都很分散。

adrian cockcroft ?@adrianco 3月6號

@samnewman @allspaw中心計劃和協商的事情不會擴展，其創新速度也不如高信任度的自由和責任。

John Allspaw ?@allspaw 3月6號

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

John Allspaw ?@allspaw 3月6號

@adrianco我想說的是你忽略了一點――你關于Etsy的言論可能是錯的。

John Allspaw ?@allspaw  3月6號

@adrianco誰說Etsy是中心計劃的？你鬧鐘的Etsy開發模型是有缺陷的。

adrian cockcroft ?@adrianco 3月6號

@allspaw抱歉，我不確定你覺得我說的哪一部分是錯誤的。我在討論擴展一個像Etsy和Facebook一樣的monolith的替代選項。

John Allspaw ?@allspaw 3月6號

@adrianco我沒有聽到“替代選項”，我只聽到“不能運行”，“滅亡”和“Microservices在各方面都很優秀”。如果我說錯了，我向你道歉。

adrian cockcroft ?@adrianco  3月6號

@allspaw昨天我去參加了Etsy大會。Php語言的Monolithic導致功能不能用其他語言實施，如clojure

John Allspaw ?@allspaw 3月6號

@adrianco 是的。而且Clojure語言的Microservices也不具有php的優勢。工程是在多種影響之中的權衡。

John Allspaw ?@allspaw 3月6號

@adrianco我已經在這工作4年多了，我想說，你考慮的不全面。：）

adrian cockcroft ?@adrianco 3月6號

@allspaw我想來自Etsy的伙計應該談一談使用monolith的好處，但我不認為增加獨立隊伍會阻礙創新。

Alan ?@AlanMorrison 3月6號

@adrianco @allspaw （鏈接 http://bit.ly/1nha966 ）正確的服務水平應該在微觀和宏觀之間，如一個過程中的步驟，對不對？

John Allspaw ?@allspaw 3月6號

@adrianco好主意。

Adam Thody ?@thody 3月6號

@allspaw @adrianco先生們，這是一場挺好的，但冗長的、過時的辯論。軟件和組織中應該避免教條主義。

John Allspaw ?@allspaw 3月6號

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

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

Kevin Behr ?@kevinbehr 3月6號

@allspaw @adrianco很有趣。我讀了這個帖子，還把“我熱愛多樣性和適應性”大聲念了出來。

Sam Newman ?@samnewman 3月6號

@allspaw @adrianco我發現conway定律更多的是定義什么是對的，而不是什么是錯的。我把它當做指導，而不是硬性規定。

Sam Newman ?@samnewman 3月6號

@allspaw @adrianco信任實現自治是關鍵――有很多種方法可以達到這一點。我們追求的是正確的架構。

Sam Newman ?@samnewman 3月6號

@allspaw @adrianco 當需要標準化時，我試圖使標準化容易、透明，如提供標準化工具。

adrian cockcroft ?@adrianco 3月6號

@allspaw @kellan 我同意，我還要補充一點：一個Microservice可以看做是一組小monolith的和。

adrian cockcroft ?@adrianco  3月6號

@samnewman @allspaw反轉conways定律的應用有助于影響搭建的架構。

Steve Smith ?@AgileSteveSmith 3月6號

@samnewman我喜歡看到標準逐漸成為成功的副產品，成為未來改進的基礎。/@allspaw @adrianco

Anthony Elizondo ?@complex 3月6號

@adrianco @allspaw @kellan 基于你們的觀點，消費者看到的是Microservice，供應商看到的是monolith。

Sam Newman ?@samnewman 3月6號

@AgileSteveSmith @allspaw @adrianco我在內部工具鏈和服務模板中增量變化中發現了這一點。

Sam Newman ?@samnewman 3月6號

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

如你所見，這里存在很多關于這兩個模式的討論，但似乎都沒有掐中要害，然后就變成顧左右而言其他。也許有一天這樣的辯論還會繼續，但也可能存在大同小異的辯論內容。下面談談為什么需要這種論戰。

Monolithic APP被視為Anti-Pattern

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

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

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

這種懷疑是因為Monolithic應用使用Anti-Pattern。關于這一點，請參見《Monolithic架構無法擴展》。這篇文章的主旨是：擴展指的是大的開發者組織成功的修改、測試、發布代碼的能力，指的不是系統每秒可處理的請求數量。

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

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

Microservice很棒

解決Monolithic應用的一個問題是將應用分為多個Microservice。Matin Fowler解釋道：

2011年5月，威尼斯的一個軟件架構工作坊提到了“microserverice”這一術語，這一術語描述了參與者們正在探索的通用架構類型。2012年5月，這個組織決定“Microservice”是最合適的名字。2012年3月，James在波蘭以案例學習的形式展示了其中的一些觀點，同時期，Fred George也闡述了這些觀點。Adrian Cockcroft將這種方法描述為“細紋理SOA”，是網絡規模類型的先驅。

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

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

我們所期待的目標是很好的。避免防御式編程，去耦合，關注點分離，迅速部署，錯誤隔離，快速反饋回路，開發者責任制，專注做好一件事情的app，獨立升級路徑，優化的版本控制，團隊間分離……這些都是我們的目標。

問題是：Microservice是實現這些目標的唯一辦法么？即使不是，Microservice是實現這些目標的最好辦法么？

對于第一點，發布非獨立功能時，如果一個功能失敗了，所有的功能都要返工。這是分支和粒度發布策略（release granularity policies）的架構。Erst推測可以通過不緩存功能的方式來避免這個問題，功能一旦完成就進行發布。一天持續發布很多次意味著一天發布了很多變化，這些發布是獨立可復原的，因此就不會有什么問題。功能標識是另一種應對產品功能問題的辦法，不過沒那么好。

盡管Microservice是解決返工問題的一個解決方案，但這不是唯一的解決方案，也不是最好的解決方案，Microservice只是這場論戰中反復提到的一個模式。

服務不是什么新東西

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

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

服務是怎么創建的？閱讀W.Richard Stevens的著作，使用本地TCP/IP和線程庫創建自己的信息handler、格式和協議。在此之上你可以搭建Actor，狀態機處理器，消息代理，發布和訂閱機制，計數器handler，線程池，工作序列和高級CPU調度算法。或者你可以使用雷系ACE的框架幫助你。

很多服務都是按上述描述搭建的，它們性能很快，不需要HTTP、網絡服務器或任何其他現代的“改進”。在移動領域，HTTP絕不是助力。因此服務總是在工作，沒有什么理由去換新。

捍衛monolith―如上所述，因此：

Monolith總是工作的。一個有任何復雜形式的服務通常也有復雜的現場和內部結構，因為服務是請求會話和響應會話的端點。這意味著服務的內部可以很復雜，需要很大的團隊開發這些內容，需要嚴格的延遲控制和高可用性。

我們所看到的是復雜是保守的。都是你自己的代碼時，不會因為簡單的把一切都隔離到墻后面而導致復雜。復雜在什么地方。只有本質簡單的簡單才是真的簡單，否則簡單只是一種抽象的說法，大家很快就會識破。

去耦合和關注點分離的優點都可以在代碼庫中實現，如果你不能讓復雜的代碼工作，你可以查看代碼結構，編程語言的選擇，程序員，源代碼控制策略，分支策略，故障修復策略，發布策略和搭建和部署系統。不要一下子就斷定是Monolith的問題。

例如，一直以來去耦合都是通過庫機制實現的。我知道這是軟件工程，不是算法，請屈尊和我一起從軟件工程的角度看問題吧。如果代碼庫分為了獨立的庫，有著清晰地接口，那么來自世界各地的上百個人都可以獨立的工作于這些庫。是的，庫可以作為分離的產品放入源代碼樹，任何需要這些產品的工程都可以使用這些產品。這些產品有自己的發布策略，故障追蹤等。接口必須保證真實有效，就像服務接口一樣。如果接口變化了，那么另一個版本的庫可以創建，就像一個服務。每個庫可以單獨測試，就像一個服務。每個團隊都可以使用自己的流程和策略進行開發，就像一個服務。

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

流程中的內部代碼應該和將所有庫組件聚集起來、安裝、配置、管理所經歷的引導順序差不多。

所有運行代碼的事項都必須這么做。Microservices一定有內部的方式來解決內部和外部的服務引用，以依賴順序開啟服務，啟動時配置服務，運行時重新配置服務，處理失敗，處理HA，使用度量監控等。

當OS啟動時，OS也做同樣的事情，OS上運行的每個流程也做同樣的事情。每個服務也做同樣的事情。每種情況下為達到目標調整的是機制而不是模式本身。每種情況都受制于自身的困難，這些困難不會藏置于抽象層后。

Monolith不能做的是支持不同語言的開發，因為必須要構建一個圖形。不過這是要評估的權衡，不是一個強烈的反對理由。

因此，Microservices運動目標是完美無缺。實現這些目標的機制比支持者預想的靈活。可能成為Big Ball of Mud 。許多敏捷/TDD/極限編程都是管理代碼熵的一種方法，服務也可以通過同樣的方法，形成自己的Ball of Mud。一個有良好軟件工程支持的Monolithic代碼庫可以良好工作，Etsy就是如此。

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