“微服務架構”這一術語在前幾年橫空出世，用于描述這樣一種特定的軟件設計方法，即以若干組可獨立部署的服務的方式進行軟件應用系統的設計。盡管這種架構風格尚無明確的定義，但其在下述方面還是存在一定的共性，即圍繞業務功能的組織、自動化部署、端點智能、以及在編程語言和數據方面進行去中心化的控制。

本文目錄

• 微服務架構的九大特性

  • 特性一：“組件化”與“多服務”
  • 特性二：圍繞“業務功能”組織團隊
  • 特性三：“做產品”而不是“做項目”
  • 特性四：“智能端點”與“傻瓜管道”
  • 特性五：“去中心化”地治理技術
  • 特性六：“去中心化”地管理數據
  • 特性七：“基礎設施”自動化
  • 特性八：“容錯”設計
  • 特性九：“演進式”設計

• 未來的方向是“微服務”嗎？

“微服務”——這是在“軟件架構”這條熙熙攘攘的大街上出現的又一個新詞語。我們很容易對它不屑一顧，但是這個小小的術語卻描述了一種引人入勝的軟件系統風格。在近幾年中，我們越來越多的看到許多項目使用了這種風格，而且就目前來說結果都是不錯的，以至于許多ThoughtWorker都把它看作構建企業應用系統的默認風格。然而，很不幸的是，我們找不到有關它的概要信息，即什么是微服務風格，以及如何設計微服務風格的架構。

簡而言之，微服務架構風格[1]這種開發方法，是以開發一組小型服務的方式來開發一個獨立的應用系統。其中每個小型服務都運行在自己的進程中，并經常采用HTTP資源API這樣輕量的機制來相互通信。這些服務圍繞業務功能進行構建，并能通過全自動的部署機制來進行獨立部署。這些微服務可以使用不同的語言來編寫，并且可以使用不同的數據存儲技術。對這些微服務，我們僅做最低限度的集中管理。

在開始介紹微服務風格之前，將其與單塊（monolithic）風格進行對比還是很有意義的：一個單塊應用系統是以一個單個單元的方式來構建的。企業應用系統經常包含三個主要部分：客戶端用戶界面、數據庫和服務端應用系統。客戶端用戶界面包括HTML頁面和運行在用戶機器的瀏覽器中的JavaScript。數據庫中包括許多表，這些表被插入一個公共的且通常為關系型的數據庫管理系統中。這個服務端的應用系統就是一個單塊應用——一個單個可執行的邏輯程序[2]。對于該系統的任何改變，都會涉及構建和部署上述服務端應用系統的一個新版本。

這樣的單塊服務器是構建上述系統的一種自然的方式。處理用戶請求的所有邏輯都運行在一個單個的進程內，因此能使用編程語言的基本特性，來把應用系統劃分為類、函數和命名空間。通過精心設計，得以在開發人員的筆記本電腦上運行和測試這樣的應用系統，并且使用一個部署流水線來確保變更被很好地進行了測試，并被部署到生產環境中。通過負載均衡器運行許多實例，來將這個單塊應用進行橫向擴展。

單塊應用系統可以被成功地實現，但是漸漸地，特別是隨著越來越多的應用系統正被部署到云端，人們對它們開始表現出不滿。軟件變更受到了很大的限制，應用系統中一個很小部分的一處變更，也需要將整個單塊應用系統進行重新構建和部署。隨著時間的推移，單塊應用逐漸難以保持一個良好的模塊化結構，這使得它變得越來越難以將一個模塊的變更所產生的影響控制在該模塊內。當對系統進行擴展時，不得不擴展整個應用系統，而不能僅擴展該系統中需要更多資源的那些部分。

圖1: 單塊應用和微服務

這些不滿催生出了微服務架構風格：以構建一組小型服務的方式來構建應用系統。除了這些服務能被獨立地部署和擴展之外，每一個服務還能提供一個穩固的模塊邊界，甚至能允許使用不同的編程語言來編寫不同的服務。這些服務也能被不同的團隊來管理。

我們并不認為微服務風格是一個新穎或創新的概念，它的起源至少可以追溯到Unix的設計原則。但是我們覺得，考慮微服務架構的人還不夠多，并且如果對其加以使用，許多軟件的開發工作能變得更好。

微服務架構的九大特性

雖然不能說存在微服務架構風格的正式定義，但是可以嘗試描述我們所見到的、能夠被貼上“微服務”標簽的那些架構的共性。下面所描述的這些共性，并不是所有的微服務架構都完全具備，但是我們確實期望大多數微服務架構都具備這些共性中的大多數特性。盡管我們兩位作者已經成為這個相當松散的社區中的活躍成員，但我們的本意還是描述我們兩人在自己所在和所了解的團隊工作中所看到的情況。特別要指出，我們不會制定大家需要遵循的微服務的定義。

特性一：“組件化”與“多服務”

自我們從事軟件行業以來，發現大家都有“把組件插在一起來構建系統”的愿望，就像在物理世界中所看到的那樣。在過去幾十年中，我們已經看到，在公共軟件庫方面已經取得了相當大的進展，這些軟件庫是大多數編程語言平臺的組成部分。

當談到組件時，會碰到一個有關定義的難題，即什么是組件？我們的定義是：一個組件就是一個可以獨立更換和升級的軟件單元。

微服務架構也會使用軟件庫，但其將自身軟件進行組件化的主要方法是將軟件分解為諸多服務。我們將軟件庫(libraries)定義為這樣的組件，即它能被鏈接到一段程序，且能通過內存中的函數來進行調用。然而，服務(services)是進程外的組件，它們通過諸如web service請求或遠程過程調用這樣的機制來進行通信（這不同于許多面向對象的程序中的service object概念[3]）。

以使用服務（而不是以軟件庫）的方式來實現組件化的一個主要原因是，服務可被獨立部署。如果一個應用系統[4]由在單個進程中的多個軟件庫所組成，那么對任一組件做一處修改，都不得不重新部署整個應用系統。但是如果該應用系統被分解為多個服務，那么對于一個服務的多處修改，僅需要重新部署這一個服務。當然這也不是絕對的，一些變更服務接口的修改會導致多個服務之間的協同修改。但是一個良好的微服務架構的目的，是通過內聚的服務邊界和服務協議方面的演進機制，來將這樣的修改變得最小化。

以服務的方式來實現組件化的另一個結果，是能獲得更加顯式的（explicit）組件接口。大多數編程語言并沒有一個良好的機制來定義顯式的發布接口。通常情況下，這樣的接口僅僅是文檔聲明和團隊紀律，來避免客戶端破壞組件的封裝，從而導致組件間出現過度緊密的耦合。通過使用顯式的遠程調用機制，服務能更容易地規避這種情況。

如此使用服務，也會有不足之處。比起進程內調用，遠程調用更加昂貴。所以遠程調用API接口必須是粗粒度的，而這往往更加難以使用。如果需要修改組件間的職責分配，那么當跨越進程邊界時，這種組件行為的改動會更加難以實現。

近似地，我們可以把一個個服務映射為一個個運行時的進程，但這僅僅是一個近似。一個服務可能包括總是在一起被開發和部署的多個進程，比如一個應用系統的進程和僅被該服務使用的數據庫。

特性二：圍繞“業務功能”組織團隊

當在尋求將一個大型應用系統分解成幾部分時，公司管理層往往會聚焦在技術層面上，這就意味著要組建用戶界面團隊、服務器端團隊和數據庫團隊。當團隊沿著這些技術線分開后，即使要實現軟件中一個簡單的變更，也會發生跨團隊的項目時延和預算審批。在這種情況下，聰明的團隊會進行局部優化，“兩害相權取其輕”，來直接把代碼邏輯塞到他們能訪問到的任意應用系統中。換句話說，這種情況會導致代碼邏輯散布在系統各處。這就是康威定律[5]的鮮活實例。

任何設計（廣義上的）系統的組織，都會產生這樣一個設計，即該設計的結構與該組織的溝通結構相一致。——梅爾文?康威（Melvyn Conway）, 1967年

圖2：康威定律在起作用

微服務使用不同的方法來分解系統，即根據業務功能（business capability）來將系統分解為若干服務。這些服務針對該業務領域提供多層次、廣泛的軟件實現，包括用戶界面、持久性存儲以及任何對外的協作性操作。因此，團隊是跨職能的，它擁有軟件開發所需的全方位的技能：用戶體驗、數據庫和項目管理。

圖3：被團隊邊界所強化的服務邊界

以上述方式來組織團隊的公司是www.comparethemarket.com。跨職能團隊負責構建和運維每個產品，而每個產品被拆分為多個獨立的服務，彼此通過一個消息總線來通信。

一個微服務應該有多大？

盡管許多人已經習慣于用“微服務”來概括描述這種這種架構風格，但是這個名字確實會不幸地引發大家對服務規模的關注，并且產生有關什么是“微”的爭論。在與微服務從業者的交談中，我們看到了有關服務的一系列規模。所聽到的最大的一個服務規模，是遵循了亞馬遜的“兩個比薩團隊”（即一個團隊可以被兩個比薩所喂飽）的理念所形成的，這意味著這個團隊不會多于12人。對于規模較小的服務，我們已經看到一個6人的團隊在支持6個服務。

這引出了一個問題，即“每12人做一個服務”和“每人做一個服務”這樣有關服務規模的差距，是否已經大到不能將兩者都納入微服務之下？此時，我們認為最好還是把它們歸為一類，但是隨著探索的深入，我們將來極有可能會改變主意。

大型單塊應用系統也可以始終根據業務功能來進行模塊化設計，雖然這并不常見。當然，我們會敦促構建單塊應用系統的大型團隊根據業務線來將自己分解為若干小團隊。在這方面，我們已經看到的主要問題是，他們往往是一個團隊包含了太多的業務功能。如果這個“單塊”跨越了許多模塊的邊界，那么這個團隊的每一個成員都難以記住所有模塊的業務功能。此外，我們看到這些模塊的邊界需要大量的團隊紀律來強制維持。而實現組件化的服務所必要的更加顯式的邊界，能更加容易地保持團隊邊界的清晰性。

特性三：“做產品”而不是“做項目”

我們所看的大部分應用系統的開發工作都使用項目模型：目標是交付某一塊軟件，之后就認為完工了。一旦完工后，軟件就被移交給維護團隊，接著那個構建該軟件的項目團隊就會被解散。

微服務的支持者們傾向于避免使用上述模型，而寧愿采納“一個團隊在一個產品的整個生命周期中都應該保持對其擁有”的理念。通常認為這一點源自亞馬遜的“誰構建，誰運行”的理念，即一個開發團隊對一個在生產環境下運行的軟件負全責。這會使開發人員每天都關注軟件是如何在生產環境下運行的，并且增進他們與用戶的聯系，因為他們必須承擔某些支持工作。

這樣的“產品”理念，是與業務功能的聯動綁定在一起的。它不會將軟件看作是一個待完成的功能集合，而是認為存在這樣一個持續的關系，即軟件如何能助其客戶來持續增進業務功能。

當然，單塊應用系統的開發工作也可以遵循上述“產品”理念，但是更細粒度的服務，能讓服務的開發者與其用戶之間的個人關系的創建變得更加容易。

特性四：“智能端點”與“傻瓜管道”

當在不同的進程之間構建各種通信結構時，我們已經看到許多產品和方法，來強調將大量的智能特性納入通信機制本身。其中一個典型例子，就是“企業服務總線”(Enterprise Service Bus, ESB)。ESB產品經常包括高度智能的設施，來進行消息的路由、編制(choreography)、轉換，并應用業務規則。

微服務社區主張采用另一種做法：智能端點(smart endpoints)和傻瓜管道(dumb pipes)。使用微服務所構建的各個應用的目標，都是盡可能地實現“高內聚和低耦合”——他們擁有自己的領域邏輯，并且更像是經典Unix的“過濾器”(filter)那樣來工作——即接收一個請求，酌情對其應用業務邏輯，并產生一個響應。這些應用通過使用一些簡單的REST風格的協議來進行編制，而不去使用諸如下面這些復雜的協議，即"WS-編制"(WS-Choreography)、BPEL或通過位于中心的工具來進行編排(orchestration)。

微服務最常用的兩種協議是：帶有資源API的HTTP“請求－響應”協議，和輕量級的消息發送協議[6]。對于前一種協議的最佳表述是：

成為Web，而不是躲著Web (Be of the web, not behind the web)——Ian Robinson

這些微服務團隊在開發中，使用在構建萬維網(world wide web)時所使用的原則和協議（并且在很大程度上，這些原則和協議也是在構建Unix系統時所使用的）。那些被使用過的HTTP資源，通常能被開發或運維人員輕易地緩存起來。

最常用的第二種協議，是通過一個輕量級的消息總線來進行消息發送。此時所選擇的基礎設施，通常是“傻瓜”(dumb)型的(僅僅像消息路由器所做的事情那樣傻瓜)——像RabbitMQ或ZeroMQ那樣的簡單實現，即除了提供可靠的異步機制(fabric)以外不做其他任何事情——智能功能存在于那些生產和消費諸多消息的各個端點中，即存在于各個服務中。

在一個單塊系統中，各個組件在同一個進程中運行。它們相互之間的通信，要么通過方法調用，要么通過函數調用來進行。將一個單塊系統改造為若干微服務的最大問題，在于對通信模式的改變。僅僅將內存中的方法調用轉換為RPC調用這樣天真的做法，會導致微服務之間產生繁瑣的通信，使得系統表現變糟。取而代之的是，需要用更粗粒度的協議來替代細粒度的服務間通信。

特性五：“去中心化”的治理技術

使用中心化的方式來對開發進行治理，其中一個后果，就是趨向于在單一技術平臺上制定標準。經驗表明，這種做法會帶來局限性——不是每一個問題都是釘子，不是每一個方案都是錘子。我們更喜歡根據工作的不同來選用合理的工具。盡管那些單塊應用系統能在一定程度上利用不同的編程語言，但是這并不常見。

如果能將單塊應用的那些組件拆分成多個服務，那么在構建每個服務時，就可以有選擇不同技術棧的機會。想要使用Node.js來搞出一個簡單的報表頁面？盡管去搞。想用C++來做一個特別出彩的近乎實時的組件？沒有問題。想要換一種不同風格的數據庫，來更好地適應一個組件的讀取數據的行為？可以重建。

微服務和SOA

當我們談起微服務時，一個常見的問題就會出現：是否微服務僅僅是十多年前所看到的“面向服務的架構”(Service Oriented Architecture, SOA)？這樣問是有道理的，因為微服務風格非常類似于一些支持SOA的人所贊成的觀點。然而，問題在于SOA這個詞兒意味著太多不同的東西。而且大多數時候，我們所遇到的某些被稱作"SOA"的事物，明顯不同于本文所描述的風格。這通常由于它們專注于ESB，來集成各個單塊應用。

特別地，我們已經看到如此之多的面向服務的拙劣實現——從將系統復雜性隱藏于ESB中的趨勢[7]，到花費數百萬進行多年卻沒有交付任何價值的失敗項目，到頑固抑制變化發生的中心化技術治理模型——以至于有時覺得其所造成的種種問題真的不堪回首。

當然，在微服務社區投入使用的許多技術，源自各個開發人員將各種服務集成到各個大型組織的經驗。“容錯讀取”(Tolerant Reader)模式就是這樣一個例子。對于Web的廣泛使用，使得人們不再使用一些中心化的標準，而使用一些簡單的協議。坦率地說，這些中心化的標準，其復雜性已經達到令人吃驚的程度。（任何時候，如果需要一個本體來管理其他各個本體，那么麻煩就大了。）

這種常見的SOA表現，已使得一些微服務的倡導者完全拒絕將自己貼上SOA的標簽。盡管其他人會將微服務看作是SOA的一種形式[8]，也許微服務就是以正確的形式來實現面向服務的SOA。不管是哪種情況，SOA意味著如此之多的不同事物，這表明用一個更加干凈利落的術語來命名這種架構風格是很有價值的。

當然，僅僅能做事情，并不意味著這些事情就應該被做——不過用微服務的方法把系統進行拆分后，就擁有了技術選型的機會。

相比選用業界一般常用的技術，構建微服務的那些團隊更喜歡采用不同的方法。與其選用一組寫在紙上已經定義好的標準，他們更喜歡編寫一些有用的工具，來讓其他開發者能夠使用，以便解決那些和他們所面臨的問題相似的問題。這些工具通常源自他們的微服務實施過程，并且被分享到更大規模的組織中，這種分享有時會使用內部開源的模式來進行。事實上，現在git和github已經成為首選版本控制系統。在企業內部，開源的做法正在變得越來越普遍。

Netflix公司是遵循上述理念的好例子。將實用且經過實戰檢驗的代碼以軟件庫的形式共享出來，能鼓勵其他開發人員以相似的方式來解決相似的問題，當然也為在需要的時候選用不同的方案留了一扇門。共享軟件庫往往聚焦于解決這樣的常見問題，即數據存儲、進程間的通信和下面要進一步討論的基礎設施的自動化。

對于微服務社區來說，日常管理開銷這一點不是特別吸引人。這并不是說這個社區并不重視服務契約。恰恰相反，它們在社區里出現得更多。這正說明這個社區正在尋找對其進行管理的各種方法。像“容錯讀取”和“消費者驅動的契約”(Consumer-Driven Contracts)這樣的模式，經常被運用到微服務中。這些都有助于服務契約進行獨立演進。將執行“消費者驅動的契約”做為軟件構建的一部分，能增強開發團隊的信心，并提供所依賴的服務是否正常工作的快速反饋。實際上，我們了解到一個在澳洲的團隊就是使用“消費者驅動的契約”來驅動構建多個新服務的。他們使用了一些簡單的工具，來針對每一個服務定義契約。甚至在新服務的代碼編寫之前，這件事就已經成為自動化構建的一部分了。接下來服務僅被構建到剛好能滿足契約的程度——這是一個在構建新軟件時避免YAGNI[9]困境的優雅方法。這些技術和工具在契約周邊生長出來，由于減少了服務之間在時域(temporal)上的耦合，從而抑制了對中心契約管理的需求。

多種編程語言，多種選擇可能

做為一個平臺，JVM的發展僅僅是一個將各種編程語言混合到一個通用平臺的最新例證。近十年以來，通過在平臺外層實現更高層次的編程語言，來利用更高層次的抽象，已經成為一個普遍做法。同樣，在平臺底層以更低層次的編程語言編寫性能敏感的代碼也很普遍。然而，許多單塊系統并不需要這種級別的性能優化，另外DSL和更高層次的抽象也不常用（這令我們感到失望）。相反，許多單塊應用通常就使用單一編程語言，并且有對所使用的技術數量進行限制的趨勢[10]。

或許去中心化地治理技術的極盛時期，就是亞馬遜的“誰構建，誰運行”的理念開始普及的時候。各個團隊負責其所構建的軟件的所有工作，其中包括7x24地對軟件進行運維。“將運維這一級別的職責下放到團隊”這種做法，目前絕對不是主流。但是我們確實看到越來越多的公司，將運維的職責交給各個開發團隊。Netflix就是已經形成這種風氣的另一個組織[11]。避免每天凌晨3點被枕邊的尋呼機叫醒，無疑是在程序員編寫代碼時令其專注質量的強大動力。而這些想法，與那些傳統的中心化技術治理的模式具有天壤之別。

特性六：“去中心化”地管理數據

去中心化地管理數據，其表現形式多種多樣。從最抽象的層面看，這意味著各個系統對客觀世界所構建的概念模型各不相同。當在一個大型的企業中進行系統集成時，這是一個常見的問題。比如對于“客戶”這個概念，從銷售人員的視角看，就與從支持人員的視角看有所不同。從銷售人員的視角所看到的一些被稱之為“客戶”的事物，或許在支持人員的視角中根本找不到。而那些在兩個視角中都能看到的事物，或許各自具有不同的屬性。更糟糕的是，那些在兩個視角中具有相同屬性的事物，或許在語義上有微妙的不同。

上述問題在不同的應用程序之間經常出現，同時也會出現在這些應用程序內部，特別是當一個應用程序被分成不同組件時就會出現。思考這類問題的一個有效方法，就是使用領域驅動設計（Domain-Driven Design, DDD）中的“限界上下文”（Bounded Context）的概念。DDD將一個復雜的領域劃分為多個限界上下文，并且將其相互之間的關系用圖畫出來。這一劃分過程對于單塊和微服務架構兩者都是有用的，而且就像前面有關“業務功能”一節中所討論的那樣，在服務和各個限界上下文之間所存在的自然的聯動關系，有助于澄清和強化這種劃分。

“實戰檢驗”的標準與“強制執行”的標準

微服務的下述做法有點涇渭分明的味道，即他們趨向于避開被那些企業架構組織所制定的硬性實施標準，而愉快地使用甚至傳播一些開放標準，比如HTTP、ATOM和其他微格式的協議。

這里的關鍵區別是，這些標準是如何被制定以及如何被實施的。像諸如IETF這樣的組織所管理的各種標準，只有達到下述條件才能稱為標準，即該標準在全球更廣闊的地區有一些正在運行的實現案例，而且這些標準經常源自一些成功的開源項目。

這些標準組成了一個世界，它區別于來自下述另一個世界的許多標準，即企業世界。企業世界中的標準，經常由這樣特點的組織來開發，即缺乏用較新技術進行編程的經驗，或受到供應商的過度影響。

如同在概念模型上進行去中心化的決策一樣，微服務也在數據存儲上進行去中心化的決策。盡管各個單塊應用更愿意在邏輯上各自使用一個單獨的數據庫來持久化數據，但是各家企業往往喜歡一系列單塊應用共用一個單獨的數據庫——許多這樣的決策是被供應商的各種版權商業模式所驅動出來的。微服務更喜歡讓每一個服務來管理其自有數據庫。其實現可以采用相同數據庫技術的不同數據庫實例，也可以采用完全不同的數據庫系統。這種方法被稱作“多語種持久化”(Polyglot Persistence)。在一個單塊系統中也能使用多語種持久化，但是看起來這種方法在微服務中出現得更加頻繁。

<span class="s1">圖4：微服務更喜歡讓每一個服務來管理其自有數據庫</span>

在各個微服務之間將數據的職責進行“去中心化”的管理，會影響軟件更新的管理。處理軟件更新的常用方法，是當更新多個資源的時候，使用事務來保證一致性。這種方法經常在單塊系統中被采用。

像這樣使用事務，有助于保持數據一致性。但是在時域上會引發明顯的耦合，這樣一來，在多個服務之間處理事務時會出現一致性問題。分布式事務實現難度之大是不必多言的。為此，微服務架構更強調在各個服務之間進行“無事務”的協調。這源自微服務社區明確地認識到下述兩點，即數據一致性可能只要求數據在最終達到一致，并且一致性問題能夠通過補償操作來進行處理。

對于許多開發團隊來說，選擇這種方式來管理數據的“非一致性”，是一個新的挑戰。但這通常也符合在商業上的實踐做法。通常情況下，為了快速響應需求，商家們都會處理一定程度上的數據“非一致性”，通過做某種反向過程來進行錯誤處理。只要修復錯誤的成本低于“保持更大的數據一致性卻導致丟了生意所產生”的成本相比，那么進行這種“非一致性”地數據管理就是值得的。

特性七：“基礎設施”自動化

基礎設施自動化技術在過去幾年里已經得到長足的發展。云的演進，特別是AWS的發展，已經降低了構建、部署和運維微服務的操作復雜性。

許多使用微服務構建的產品和系統，正在被這樣的團隊所構建，即他們都具備極其豐富的“持續交付”和其前身“持續集成”的經驗。用這種方法構建軟件的各個團隊，廣泛采用了基礎設施的自動化技術。如下圖的構建流水線所示：

圖5：基本的構建流水線

由于本文并不是一篇有關持續交付的文章，所以下面僅提請大家注意兩個持續交付的關鍵特點。為了盡可能地獲得對正在運行的軟件的信心，需要運行大量的自動化測試。讓可工作的軟件達到“晉級”(Promotion)狀態、從而“推上”流水線，就意味著可以在每一個新的環境中，對軟件進行自動化部署。

一個單塊應用程序，能夠相當愉快地在上述各個環境中，被構建、測試和推送。其結果是，一旦在下述工作中進行了投入，即針對一個單塊系統將其通往生產環境的通道進行自動化，那么部署更多的應用系統似乎就不再可怕。記住，持續交付的目的之一，是讓“部署”工作變得“無聊”。所以不管是一個還是三個應用系統，只要部署工作依舊很“無聊”，那么就沒什么可擔心的了[12]。

讓“沿著正確的方向做事”更容易

那些因實現持續交付和持續集成所增加的自動化工作的副產品，是一些對開發和運維人員有用的工具。現在，能完成下述工作的工具已經相當常見了，即創建工件(artefacts)、管理代碼庫、啟動一些簡單的服務、或增加標準的監控和日志功能。Web上最好的例子可能是Netflix提供的一套開源工具集，但也有其他一些好工具，包括我們已經廣泛使用的Dropwizard。

我們所看到的各個團隊在廣泛使用基礎設施自動化實踐的另一個領域，是在生產環境中管理各個微服務。與前面我們對比單塊系統和微服務所說的正相反，只要部署工作很無聊，那么在這一點上單塊系統和微服務就沒什么區別。然而，兩者在運維領域的情況卻截然不同。

圖6：兩者的模塊部署經常會有差異

特性八：“容錯”設計

使用各個微服務來替代組件，其結果是各個應用程序需要被設計的能夠容忍這些服務所出現的故障。如果服務提供方不可用，那么任何對該服務的調用都會出現故障。客戶端要盡可能優雅地應對這種情況。與一個單塊設計相比，這是一個劣勢。因為在處理這種情況時會引入額外的復雜性。為此，各個微服務團隊在不斷地反思：這些服務故障是如何影響用戶體驗的。Netflix公司所研發的開源測試工具Simian Army，能夠誘導服務發生故障，甚至能誘導一個數據中心在工作日發生故障，來測試該應用的彈性和監控能力。

這種在生產環境中所進行的自動化測試，足以讓大多數運維組織興奮得渾身顫栗，就像即將迎來一周的長假那樣。這并不是說單塊架構風格不能構建先進的監控系統——只是根據我們的經驗，這在單塊系統中并不常見罷了。

"斷路器"與“可隨時上線的代碼”

“斷路器”(Circuit Breaker)一詞與其他一些模式一起出現在《Release It!》一書中，例如隔板(Bulkhead)和超時(Timeout)。當構建彼此通信的應用系統時，將這些模式加以綜合運用就變得至關重要。Netflix公司的這篇很精彩的博客解釋了這些模式是如何應用的。

因為各個服務可以在任何時候發生故障，所以下面兩件事就變得很重要，即能夠快速地檢測出故障，而且在可能的情況下能夠自動恢復服務。各個微服務的應用都將大量的精力放到了應用程序的實時監控上，來檢查“架構元素指標”（例如數據庫每秒收到多少請求）和“業務相關指標”（例如系統每分鐘收到多少訂單）。當系統某個地方出現問題，語義監控系統能提供一個預警，來觸發開發團隊進行后續的跟進和調查工作。

這對于一個微服務架構是尤其重要的，因為微服務對于服務編制(choreography)和事件協作的偏好，會導致“突發行為”。盡管許多權威人士對于偶發事件的價值持積極態度，但事實上，“突發行為”有時是一件壞事。在能夠快速發現有壞處的“突發行為”并進行修復方面，監控是至關重要的。

單塊系統也能構建的像微服務一樣來實現透明的監控系統——實際上，它們也應該如此。差別是，絕對需要知道那些運行在不同進程中的服務，在何時斷掉了。而如果在同一個進程內使用軟件庫的話，這種透明的監控系統就用處不大了。

“同步調用”有害

一旦在一些服務之間進行多個同步調用，就會遇到宕機的乘法效應。簡而言之，這意味著整個系統的宕機時間，是每一個單獨模塊各自宕機時間的乘積。此時面臨著一個選擇：是讓模塊之間調用異步，還是去管理宕機時間？在英國衛報網站，他們在新平臺上實現了一個簡單的規則——每一個用戶請求都對應一個同步調用。然而在Netflix公司，他們重新設計的平臺API將異步性構建到API的機制(fabric)中。

那些微服務團隊希望在每一個單獨的服務中，都能看到先進的監控和日志記錄裝置。例如顯示“運行/宕機”狀態的儀表盤，和各種運維、業務相關的指標。另外我們經常在工作中會碰到這樣一些細節，即斷路器的狀態、當前的吞吐率和延遲，以及其他一些例子。

特性九：“演進式”設計

那些微服務的從業者們，通常具有演進式設計的背景，而且通常將服務的分解，視作一個額外的工具，來讓應用開發人員能夠控制應用系統中的變化，而無須減少變化的發生。控制變化并不一定意味著要減少變化——在正確的態度和工具的幫助下，軟件中的變化也可以發生得頻繁、快速且得到良好的控制。

每當要試圖將軟件系統分解為各個組件時，就會面臨這樣的決策，即如何進行切分——我們決定切分應用系統時應該遵循的原則是什么？一個組件的關鍵屬性，是具有獨立更換和升級的特點[13]——這意味著，需要尋找這些點，即想象著能否在其中一個點上重寫該組件，而無須影響該組件的其他合作組件。事實上，許多做微服務的團隊會更進一步，他們明確地預期許多服務將來會報廢，而不是守著這些服務做長期演進。

英國衛報網站是一個好例子。原先該網站是一個以單塊系統的方式來設計和構建的應用系統，然而它已經開始向微服務方向進行演進了。原先的單塊系統依舊是該網站的核心，但是在添加新特性時他們愿意以構建一些微服務的方式來進行添加，而這些微服務會去調用原先那個單塊系統的API。當開發那些本身就帶有臨時性特點的新特性時，這種方法就特別方便，例如開發報道一個體育賽事的專門頁面。當使用一些快速的開發語言時，這樣的網站頁面就能被快速地整合起來。而一旦賽事結束，這樣頁面就可以被刪除。在一個金融機構中，我們已經看到了一些相似的做法，即針對一個市場機會，一些新的服務可以被添加進來。然后在幾個月甚至幾周之后，這些新服務就作廢了。

這種強調“可更換性”的特點，是模塊化設計一般性原則的一個特例，通過“變化模式”(pattern of change)[14]來驅動模塊化的實現。大家都愿意將那些能在同時發生變化的東西，放到同一個模塊中。系統中那些很少發生變化的部分，應該被放到不同的服務中，以區別于那些正在經歷大量變動(churn)的部分。當發現兩個服務需要被同時、反復變更，就意味著它們兩個需要被合并。

把一個個組件放入一個個服務中，提高了軟件發布精細化的程度。對于一個單塊系統，任何變化都需要做一次整個應用系統的全量構建和部署。然而，對于一個個微服務來說，只需要重新部署修改過的那些服務就夠了。這能簡化并加快發布過程。但缺點是：必須要考慮當一個服務發生變化時，依賴它并對其進行消費的其他服務將無法工作。傳統的集成方法是使用版本化來解決這個問題。但在微服務世界中，大家更喜歡將版本化作為最后萬不得已的手段來使用。我們可以通過下述方法來避免許多版本化的工作，即把各個服務設計得盡量能夠容錯，來應對其所依賴的服務所發生的變化。

未來的方向是“微服務”嗎？

我們寫這篇文章的主要目的，是解釋有關微服務的主要思路和原則。在花了一點時間做了這件事后，我們清楚地認識到，微服務架構風格是一個重要的理念——在研發企業應用系統時，值得對它進行認真考慮。我們最近已經使用這種風格構建了一些系統，并且了解到其他一些團隊也贊同并正在使用這種方法。

我們所了解到的那些在某種程度上可以被稱作這種架構風格的實踐先驅包括：亞馬遜、Netflix、英國衛報、英國政府數字化服務中心、realestate.com.au、Forward和comparethemarket.com。2013年的技術大會圈子充滿了各種各樣的、正在轉向可歸類為微服務的公司案例——包括Travis CI。另外還有大量的組織，它們長期以來一直在做著我們認為可以歸類為微服務的產品，卻從未使用過這個名字（這通常被標記為SOA——盡管正如我們所說，SOA會表現出各種自相矛盾的形式[15]）。

盡管有這些正面的經驗，但這并不意味著我們確信微服務是軟件架構未來的方向。盡管到目前為止，與單塊應用系統相比，我們對于所經歷過的微服務的評價是積極的，但是我們也意識到這樣的事實，即能供我們做出完整判斷的時間還不夠長。

通常，架構決策所產生的真正效果，只有在該決策做出若干年后才能真正顯現。我們已經看到由帶著強烈的模塊化愿望的優秀團隊所做的一些項目，最終構建出一個單塊架構，并在幾年之內不斷腐化。許多人認為，如果使用微服務就不大可能出現這種腐化，因為服務的邊界是明確的，而且難以隨意搞亂。然而，對于那些開發時間足夠長的各種系統，除非我們已經見識得足夠多，否則我們無法真正評價微服務架構是如何成熟的。

我們的同事Sam Newman花了2014年的大部分時間撰寫了一本書，來記述我們構建微服務的經驗。如果想對這個話題進行更深入的了解，下一步就應該是閱讀這本書。

有人覺得微服務或許很難成熟起來，這當然是有原因的。在組件化上所做的任何工作的成功度，取決于軟件與組件的匹配程度。準確地搞清楚某個組件的邊界位置應該出現在哪里，是一件困難的工作。演進式設計承認難以對邊界進行正確定位，所以它將工作的重點放到了易于對邊界進行重構之上。但是當各個組件成為各個進行遠程通信的服務后，比起在單一進程內調用各個軟件庫，此時的重構就變得更加困難。跨越服務邊界的代碼移動就變得困難起來。接口的任何變化，都需要在其各個參與者之間進行協調。向后兼容的層次也需要被添加進來。測試也會變得更加復雜。

另一個問題是，如果這些組件不能干凈利落地組合成一個系統，那么所做的一切工作，僅僅是將組件內的復雜性轉移到組件之間的連接之上。這樣做的后果，不僅僅是將復雜性搬了家，它還將復雜性轉移到那些不再明確且難以控制的邊界之上。在觀察一個小型且簡單的組件內部時，人們很容易覺得事情已經變得更好了，然而他們卻忽視了服務之間雜亂的連接。

最后，還要考慮團隊成員的技能水平。新技術往往會被技術更硬的團隊所采用。對于技術更加過硬的團隊而更有效的一項技術，不一定適用于技術略遜一籌的團隊。我們已經看到大量這樣的案例，那些技術略遜一籌的團隊構建出了雜亂的單塊架構。當這種雜亂發生到微服務身上時，會出現什么情況？這需要花時間來觀察。一個糟糕的團隊，總會構建一個糟糕的系統——在這種情況下，很難講微服務究竟是減少了雜亂，還是讓事情變得更糟。

我們聽到一個合理的說法：不要一上來就以微服務架構做為起點。相反，要用一個單塊系統做為起點，并保持其模塊化。當這個單塊系統出現了問題后，再將其分解為微服務。（盡管這個建議并不理想，因為一個良好的單一進程內的接口，通常不是一個良好的服務接口。）

因此，我們持謹慎樂觀的態度來撰寫此文。到目前為止，我們已經看到足夠多的有關微服務風格的內容，并且覺得這是一條值得去跋涉的道路。我們不能肯定地說，道路的盡頭在哪里。但是，軟件開發的挑戰之一，就是只能基于“目前手上擁有但還不夠完善”的信息來做出決策。

若欲獲取最新參考資料列表以得到更多信息，請參見微服務資源指南：http://martinfowler.com/microservices/。

注：

[1]. 2011年5月在威尼斯附近的一個軟件架構工作坊中，大家開始討論“微服務”這個術語，因為這個詞可以描述參會者們在架構領域進行探索時所見到的一種通用的架構風格。2012年5月，這群參會者決定將“微服務”作為描述這種架構風格的最貼切的名字。在2012年3月波蘭的克拉科夫市舉辦的“33rd Degree”技術大會上，本文作者之一James在其“Microservices - Java, the Unix Way”演講中以案例的形式談到了這些微服務的觀點，與此同時，Fred George也表達了同樣的觀點。Netflix公司的Adrian Cockcroft將這種方法描述為“細粒度的SOA”，并且作為先行者和本文下面所提到的眾人已經著手在Web領域進行了實踐——Joe Walnes, Dan North, Evan Botcher 和 Graham Tackley。

[2]. "單塊"(monolith)這個術語已經被Unix社區使用一段時間了。它出現在The Art of Unix Programming一書中，來描述那些變得龐大的系統。

[3]. 許多面向對象的設計者，包括我們自己，都使用領域驅動設計中“service object”這個術語，來描述那種執行一段未被綁定到一個entity對象上的重要邏輯過程的對象。這不同于本文所討論的"service"的概念。可悲的是，service這個術語同時具有這兩個含義，我們必須忍受這樣的多義詞。

[4]. 我們認為一個應用系統是一個社會性的構建單元，來將一個代碼庫、功能組和資金體（body of funding）結合起來。

[5]. 原始論文參見梅爾文?康威的網站：http://www.melconway.com/Home/Committees_Paper.html

[6]. 在極度強調高效性(Scale)的情況下，一些組織經常會使用一些二進制的消息發送協議——例如protobuf。即使是這樣，這些系統仍然會呈現出“智能端點和傻瓜管道”的特點——來在易讀性(transparency)與高效性之間取得平衡。當然，大多數Web屬性和絕大多數企業并不需要作出這樣的權衡——獲得易讀性就已經是一個很大的勝利了。

[7]. 忍不住要提一下Jim Webber的說法：ESB表示Egregious Spaghetti Box（一盒極爛的意大利面條）。

[8]. Netflix讓SOA與微服務之間的聯系更加明確——直到最近這家公司還將他們的架構風格稱為“細粒度的SOA”。

[9]. "YAGNI" 或者 "You Aren't Going To Need It"（你不會需要它）是極限編程的一條原則和勸誡，指的是“除非到了需要的時候，否則不要添加新功能”。

[10]. 單塊系統使用單一編程語言，這樣講有點言不由衷——為了在今天的Web上構建各種系統，可能要了解JavaScript、XHTML、CSS、服務器端的編程語言、SQL和一種ORM的方言。很難說只有一種單一編程語言，但是我們的意思你是懂得的。

[11]. Adrian Cockcroft在他2013年11月于Flowcon技術大會所做的一次精彩的演講中，特別提到了“開發人員自服務”和“開發人員運行他們寫的東西”（原文如此）。

[12]. 這里我們又有點言不由衷了。 很明顯，在更復雜的網絡拓撲里，部署更多的服務，會比部署一個單獨的單塊系統要更加困難。幸運的是，有一些模式能夠減少其中的復雜性——但對于工具的投資還是必須的。

[13]. 事實上，Dan North將這種架構風格稱作“可更換的組件架構”，而不是微服務。因為這看起來似乎是在談微服務特性的一個子集，所以我們選擇將其歸類為微服務。

[14]. Kent Beck在《實現模式》(Implementation Patterns)一書中，將其作為他的一條設計原則而強調出來。

[15]. 當SOA這個詞在本世紀初剛剛出現時，有人曾說：“我們很多年以來一直是這樣做的。”有一派觀點說，SOA這種風格，將企業級計算早期COBOL程序通過數據文件來進行通信的方式，視作自己的“根”。在另一個方向上，有人說“Erlang編程模型”與微服務是同一回事，只不過它被應用到一個企業應用的上下文中去了。

譯者：ThoughtWorks 伍斌