[[170473]]

微服務架構這個術語在過去幾年漸成熱門，它把一種特定的軟件應用的設計方法描述為能夠獨立部署的服務的套件。盡管缺乏對這一架構類型的準確定義，但是在業務能力、自動化部署、智能端點、語言和數據的去中心化控制等方面，已經形成了某些普遍特征。

微服務，另一個在軟件架構領域津津樂道的新詞。盡管我們本能上傾向于對它不屑一顧，然而這一專業術語描述了一種目前越來越吸引人的軟件系統的風格。我們已經看到近年來有許多項目使用了此類型，結果很鼓舞人心;因而對于我的諸多同事來說，這也就成為他們構建企業級應用時候的***。然而，當前并沒有很多信息來描述什么是微服務，以及如何使用它。

簡而言之，微服務架構把一個應用作為一套微服務來開發，這些微服務能運行自己的進程，采用 HTTP Resource API 這樣的輕量級機制進行通信。這些微服務圍繞著業務能力構建，能夠通過完全自動化的部署體系獨立部署。這些服務僅有***限度的中心化管理，用不同的編程語言寫成，使用不同的數據存儲技術。

要說明微服務，與一體化應用做比較能有助于理解：一體化應用是被當作一個單元來構建的。企業級應用的構建通常包括三部分：客戶端用戶界面(由 HTML 頁面和運行在用戶機器上的瀏覽器里的 javascript 構成)、數據庫(由各種表格構成，這些表格被插入到一個通用的關系數據庫管理系統里)，以及服務器端應用。服務器端應用處理 HTTP 請求，執行域名邏輯、從數據庫提取并更新數據，以及選擇并填充要被發送到瀏覽器的 HTML 視圖。這個服務器端應用就是個龐然大物——邏輯單一、可執行。系統有任何修改，都需要重新構建并部署新版本的服務器端應用。

構建這樣的系統，一體化服務就是非常適合的方法。所有處理請求的邏輯都運行在單個進程中，能夠讓你使用語言的基本功能從而把應用劃分成不同門類、功能和命名空間。出于某種原因，你能夠在開發者的電腦上運行和測試應用，使用部署管道來確保各種修改被正確地測試并部署到生產中。借助負載均衡器，你能夠通過運行更多實例來橫向擴展這一巨型應用。

一體化應用獲得了成功，但是漸漸地，隨著更多的應用被部署到云平臺，人們的挫敗感漸增。更新周期被緊緊綁定——即便是應用中一個很小部分的改變，也需要整個應用的重構和部署。隨著時間推移，保持一個良好的模塊化架構也日益困難，牽一發而動全身。一旦要進行擴展，就必須整體擴展，而不能僅僅擴展其中到一部分模塊，也就需要更多的資源。

圖 1：一體化 vs 微服務

這種情況***進化為微服務架構：把應用作為一組服務來構建。這些服務能夠獨立部署和擴展，每個服務提供一個堅實的模型邊界，甚至可以用不同的程序語言來寫這些服務。當然他們也能被不同的團隊來管理。

我們無意鼓吹微服務是新事物或者具有創新性，它植根于 Unix 的設計主旨。不過我們相信并沒有很多人思考過微服務架構;如果許多軟件開發使用了微服務，那它們的境況就會更好。

微服務架構的特征 我們不能給微服務架構下準確的定義，但是我們可以嘗試總結一些通用特征。并不是所有的微服務架構完全符合下文列出的這些特征，不過我們可以預計大部分微服務架構能符合大多數。作為這個松散社區的活躍分子，我們(指兩位作者)將嘗試描繪我們在工作和我們熟悉的團隊中看到的情況。

通過服務實現組件化

我們已經在軟件行業浸淫多年，一直期望能夠通過拼插組件的方式來構建系統，而不是采用我們在物理世界里常見的方式。在過去的幾十年里，我們已經見證了多數語言平臺的公共庫的匯編已經取得了長足的進步。

談及組件，要給它下定義并非易事。我們認為，一個組件就是軟件的一個單元，能夠被獨立替換和升級。

微服務架構也會用到庫，不過組件化軟件的方式是把軟件分解為服務。我們把庫定義為一個程序中互相連接的組件，調用內存函數，同時這些服務是進程外部的組件，通過網頁服務請求或者遠程調用通信的方式進行通信。(這與面向對象編程中的服務對象的概念并不相同)

把服務當作組件(而非庫)來使用的一大原因在于服務能夠獨立部署。如果你的應用在單個進程中包含多個庫，那對其中任何一部分的改動都會導致重新部署整個應用。如果該應用分解為多個服務，那么可以預計，單個服務改變后可能只需要重新部署該服務即可。當然事無絕對，某些改動可能會改變服務接口，需要進行某些協調。但是，好的微服務架構的目標在于通過緊密結合的服務邊界和進化機制，盡可能降低這些影響。

把服務當作組件使用的另一成果就是更為明確的組件接口。大多數語言缺乏良好機制去定義一個準確的發布接口。通常只有文檔和規則來阻止客戶端去中斷組件的封裝，結果導致組件的過度耦合。通過使用準確的遠程調用機制，服務能輕松避免這些問題。

使用服務也有不足之處。遠程調用比進程內調用更昂貴，遠程 API 也需要粗粒度，這往往更加難以使用。如果你需要更改組件之間的職責分配，那么在跨越進程邊界時就很難進行這樣的操作。

乍一看，我們能觀察到服務映射到運行時的過程，不過也僅僅是個大概。一個服務可能包含多個進程，它們會永遠被開發和部署在一起，那么這樣的應用進程和數據庫也就只能被這一服務使用。

圍繞業務能力組織

要把大型應用拆分為零件，管理人員通常聚焦在技術層面，拆分成 UI 組、服務器端邏輯組和數據庫團組。當這些組被這樣垂直分割，非常簡單的改動就會導致跨組項目，而這需要時間和預算批準。聰明的團隊會圍繞這點進行優化，兩害相權取其輕——強化邏輯到任意有訪問權限的應用。

任何試圖設計一個系統(廣義定義)的組織將會衍生出一種設計，其結構正是該組織的通信結構的復刻。

— Melvyn Conway, 1967

圖 2: Conway 效應在運行

而微服務采用的方法則大不一樣，圍繞著業務能力拆分并組合。這些服務使用與業務范圍相符的軟件而實現廣泛的技術棧，包括用戶界面、持續存儲，以及任意的外部協作。因此這些組之間是跨功能的，包括開發所要求的所有技能：用戶體驗、數據庫和項目管理。

圖 3：通過團隊界限強化服務界限

www.comparethemarket.com 就采用了這種組織方式。跨功能的團隊對構建和運行每個產品負責，每個產品又被拆分為大量的單個服務，這些服務通過信息總線通信。

大型的一體化應用也能夠圍繞業務能力模塊化，然而并不常見。當然我們會敦促這些構建一體化應用的大型團隊按照業務線來進行分工。然而問題在于，這些業務線傾向于根據諸多環境進行組織。一旦大型應用橫跨許多模塊，那么對于團隊中的個體而言，很難融入他們的工作記憶中。此外我們也看到，這些模塊線需要大量的訓練去執行。服務組件所需的更為精細的分割也能讓團隊邊界更清晰。

產品而非項目

大多數我們常見的應用開發會使用項目模式：交付軟件的部分然后再考慮組合完整。完成后的軟件被交付到維護機構，構建此項目的團隊不被解散。

微服務的支持者則易于避免此模式，傾向于「在產品的整個生命周期里，開發團隊應該擁有此項目」。這一靈感來自于亞馬遜的「你構建，你運行」概念。在亞馬遜，開發團隊對生產環境中的軟件負有全部責任。這讓開發者每日都能了解自己的軟件如何在生產環境運行，增強與用戶的接觸，也能承擔部分支持職責。

這種產品意識與業務能力緊緊聯系。與其把軟件看作一套需要完成的功能，不如把它們看作一段進行中的關系，其中的關鍵問題是軟件如何幫助用戶增強業務能力。

并沒有理由表明這一方法不能用于一體化應用，不過顆粒度更小的服務能夠更容易地在服務開發者和用戶之間建立起個人關系。

智能終端和啞管道

要在不同進程之間構建通信結構，我們已經見過許多產品和方案，它們強調在通信機制內部注入智能，其中優秀案例如 ESB(企業服務總線)。ESB 產品包含復雜的設施，用于信息路由、編排、轉化，以及應用業務規則。

微服務社區則喜歡另一種方案：智能終端和啞管道。使用微服務架構的應用致力于在盡可能地解耦合的同時保持關聯性——他們擁有自己的域名邏輯，從經典 Unix 的視角看來更像過濾器——接收請求，恰當地應用邏輯，生成反應。這些編排使用了簡單的 REST 協議而非 WS-Choreography 或者 BPEL ，也沒有采用使用中心化工具進行編配。

兩種廣為使用的協議分別是 HTTP 請求-反應與資源 API，以及輕量級消息。對于前者，***描述莫過于

成為 web ，不要隱藏其后

—— 伊恩·羅賓遜

微服務團隊使用萬維網(往大了說，Unix)依賴的原則和協議。開發者或者運維人員能夠以很小的代價緩存經常使用的資源。

第二種方法的通常用法是利用輕量級信息總線進行通知。選定的基礎設施是典型的 「啞管道」—— 就像 RabbitMQ 或 XeroMQ 這樣無需提供穩定的異步組織的簡單實施;而智能終端則在服務內生成并消耗消息。

在大型應用里，組件聯機執行，它們之間的通信或者采用方法調用，或者調用函數。在大型應用到微服務的轉變中，***的問題就是通信模式的改變。從內存調用函數的本地對話轉為 RPC，可能會變成性能不佳的聊天式通信。并且，你還需要用粗粒度的方法代替原來的精細通信。

去中心化治理

中心化治理的一大后果就是單一技術平臺的標準化傾向。經驗顯示這一方式非常狹隘——每個問題各有特色，而「馬斯洛的錘子」并非***。我們更喜歡針對工作使用正確的工具，在特定情境下，一體化應用能夠發揮不同語言的優勢。這并不常見。

把大型應用的組件拆分為服務，那么當我們構建每個部分時就有選擇。想用 Node.js 構建一個單個報告頁面?用起來!用 C++ 寫一個格外粗糙的近實時組件?沒問題。想交換不同數據庫類型，從而更好地適應某個組件的閱讀習慣?我們也有重構技術。

當然，能做并不等于要那樣做——不過這種系統切割方法給了你選擇權。

構建微服務的團隊也愿意使用別的方法達到標準。與其使用紙面上的現成標準，他們更愿意使開發有用的工具，從而別的開發者也能夠用來解決相似問題。這些工具通常通過實施收獲成果，以包括內部開源模式在內的方式更廣泛的群體中分享。現在 git 和 github 已經成為事實上的版本控制系統，開源實踐也在機構內部越來越常見。

Netflix 就是這一理念的***踐行者。通過庫的形式分享有用的、經過時間考驗的代碼，鼓勵別的開發者以相似方法解決相似問題，同時也給別的必要的方法留有機會。共享庫關注常用問題，比如數據存儲、進程間通信，以及下文將討論的基礎設施自動化。

對微服務社區來說，額外的開銷格外討厭。社區并非不重視服務協議;與之相反，他們使用不同的方式來管理這些協議。Tolerant Reader 和 Consumer-Driven Contracts 這樣的模型經常被用于微服務。他們幫助服務協議進行獨立進化。通過把執行消費者驅動協議作為構建的一部分，強化了信心，也能就其它微服務是否工作提供快速反饋。我們知道澳大利亞的一支團隊就使用消費者驅動協議來推動新服務的構建。他們使用能夠定義單個服務協議的簡單工具。在新服務的代碼寫好之前，就成為自動化構建的一部分。服務僅在滿足協議時被構建，以優雅的方式避免了「YANGI」( You Aren’t Going To Need It )悖論。這些技巧和工具圍繞著它們成長，降低了對中心化協議管理的需求，減少了服務之間的暫時耦合。

或許去中心化治理的***點是流行于亞馬遜的誰構建誰運行的理念。每個團隊都為自己構建的應用的所有方面負責，包括 24*7 不間斷地運營軟件。 這種層次的責任轉變顯然不同尋常，然而我們看到越來越多的公司給開發團隊灌輸這種層次的責任心。Netflix 是另一家采用這種理念的公司。不要在每個凌晨三點被尋呼機吵醒，這絕對是開發者關注代碼質量的強大動力。這些理念已經與傳統的中心化治理模型相去甚遠。

去中心化數據管理

去中心化數據管理的方式多種多樣。在最為抽象的層級，這意味著各個系統之間關于世界的概念模型大相徑庭。在大型企業進行整合時，這一現象很常見。對客戶的看法，銷售人員的視角與支持人員的視角不同。銷售認為可稱為「客戶」的某些方面，支持人員卻并不認同。他們可能只是具有一些在語言描述上差異很細微的不同屬性。

這一現象在應用之間也很普通，也會發生在應用內，特別是當應用被拆分為單獨的組件時。 領域模型驅動設計(Domain-Driven Design) 的 Bounded Context 概念非常有助于思考這一問題。DDD 將一個大模型分解為幾個較小的模型，并且能夠投射出它們之間的關系。這一過程對于一體化架構和微服務架構都非常有益。不過在服務和 context 的邊界之間存在自然關系，當我們在描述業務能力單元、強化分離時，這一自然關系有助于明朗化。

除了下放有關模型概念的決策，微服務也下放了數據存儲的決策。由于一體化應用喜歡為持續性數據采用單一邏輯的數據庫，企業也往往在一系列應用中采用單一數據庫。這些決策大多數受廠商的授權商業模式驅動。微服務傾向于讓每個服務管理自己的數據庫，或者不同的數據庫系統，即 Polyglot Persistence。你也可以在一體化應用中使用 Polyglot Persistence，不過它更多見于微服務。

圖4：一體化設計：單一數據庫 vs 微服務：應用數據庫

把跨微服務的數據下放影響了對更新的管理。處理更新的常見方式是在更新多個資源時，通過使用事務來保證一致性。這種方式通常也被用于一體化應用內。

使用諸如這樣的事務有助于保持一致，但是帶來了顯著的短時耦合，對跨多個服務產生問題。分布式事務因難以實施而聞名，隨之而來，微服務架構強調了服務之間的事務和諧，明確了一致性只可能為最終一致性，各種問題通過補償運算來解決。

選擇通過該方法來管理不一致對于許多開發團隊來說是項新的挑戰，不過很符合商業慣例。通常商家為了快速響應需求會對不一致進行不同程度的處理，其中會存在一些處理錯誤導致的逆轉。只要修復錯誤的代價低于因為一致性而導致業務損失的成本，這種權衡就是值得的。

基礎設施自動化

基礎設施自動化已經在過去的幾年里取得了巨大的進步。云特別是 AWS 的進化格外地降低了構建、部署和運行微服務時的復雜度。

許多采用微服務構建的產品或系統是由在持續交付和其前身——持續集成方面經驗豐富的團隊構建的。使用這種方法構建軟件的團隊需要大量使用基礎設施自動化技術。下圖展示了構建流程。

圖5：基本的構建流程

考慮到本文并不針對持續交付，我們這里只提及幾個關鍵特性。我們需要大量信心來認可自己開發的軟件可行，因此會跑大量的自動化測試。要推廣可行的軟件到流程之上，意味著我們需要把部署每個新環境自動化。

一體化應用能夠非常愉快地在這些環境中構建、測試和推送。事實證明，一旦你給一體化應用投入了自動化路徑，那部署更多應用也并不那么可怕了。謹記，持續交付的目的之一就是讓部署變得單調，所以不管是部署一個還是三個應用，只要依然單調就沒有關系。

另一個常見的使用大規模基礎設施自動化的領域就是在生產環境中管理微服務。前文我們認為只要部署一如既往地單調，那在一體化和微服務之間相差不會太大;恰恰與此相反，在運行階段，二者卻是相去甚遠。

圖6：模塊部署經常不同

為故障而生

把服務用作組件的一個結果是應用在設計之初就要能容忍技術故障。任何服務調用可能會由于供應商的不可用而失敗，而客戶端需要盡可能優雅地做出響應。與一體化設計相比，由于引入了額外的復雜性來處理，這是一大不足。其結果是微服務團隊不斷反省服務故障如何影響用戶體驗。 Netflix 的 Simian Army 通過測試應用的彈性和監控，減少了工作日的服務故障，甚至數據中心的故障。

這種生產環境中的自動化測試足以讓大多數的運營團隊望而生畏，通常后者需要提前一周的時間。這并非說一體化架構風格不能盡興這種精密的監控設置，只是不常見于我們的經驗。

既然服務可能隨時發生故障，所以能夠快速監測并盡可能地自動恢復服務就非常重要。微服務應用側重于應用的實時監控，檢查架構因素(數據庫每秒獲得多少請求)和業務相關指標(每分鐘收到多少訂單)。語義監控也可提供早期預警系統，一旦出錯就觸發開發團隊去跟進和調查。

對于微服務架構來說這尤為重要，因為微服務更偏好編配和事件協作導致的自發行為。盡管許多專家認可偶發價值，事實上意外行為并非好事。監控對于發現糟糕的意外行為至關重要，從而能夠盡快修復。

一體化也可以像微服務那樣透明構建，事實上，他們也應如此。區別在于你必須要了解運行在不同進程的服務們是何時斷開的。考慮到相同進程內的庫，這種透明度不太可能有用。

微服務團隊希望能為每個單獨的服務設置精密的監控和記錄，這些服務包括在 dashboard 上顯示服務啟用/宕機狀態，以及各種相關的運營和業務指標。與斷路器狀態、當前吞吐量和延遲的詳情都是我們經常遇到的其它例子。

進化的設計

微服務從業者通常具有進化設計的背景，把服務分解視作一個長遠的工具，讓應用開發者們能夠控制應用內的改動，無需讓改動慢下來。改動控制并不一定意味著減少——借助正確的態度和工具，你能夠經常快速、有節制地修改軟件。

當你試圖把一個軟件系統分為組件，你要作出如何劃分的決定——哪些是我們切分應用時需要遵守的原則?組件的關鍵屬性是獨立替換和升級的概念，也就意味著我們要找到一些立足點，當需要重寫某個組件時，也不會影響它的協作者。

按照一體化來設計并構建，卻演化為微服務，衛報網站給這樣的應用樹立了典范。網站的核心仍然是一體化，不過他們更愿意通過調用一體化應用的 API 來構建微服務，從而添加新功能。對于體育賽事的特定頁面這樣注定短暫的功能來說，這樣的方法非常方便。網站上的類似部分能夠通過快速開發語言而被迅速地組織起來，一旦賽事結束則可以快速移除。我們在一家金融機構也看到了類似辦法，增加新服務以對應新的市場機會，幾個月甚至幾周后就被放棄。

這種對替代性的強調，也是模塊化設計通用原則的一個特例，通常推動模塊性來實現改變的方式。你可能想保留同一模塊內同一時間的改變。系統內發生更改的部分很少在不同的當前大量流失的服務內。如果你發現自己重復在同時修改兩個應用，那表明它們應該被合并。

把組件集成到服務，讓更精細的發布計劃大有可為。采用一體化，任何修改都需要對整個應用進行一次全面的構建和部署。采用微服務后只需要重新部署修改過的服務。這能夠簡化并加快發布過程。缺點是你得擔憂對一個服務的修改可能破壞它的用戶。傳統的集成方法是采用版本控制來處理錯誤，而在微服務的世界里，則把版本控制當作***的補救辦法。通過給服務設計得盡可能強的修改寬容度，我們能夠避免大量的版本控制。

微服務是未來嗎?我們撰寫此文的主要目的是解釋微服務的主要思路和原則。通過此篇論述，我們認為微服務的架構風格是一個重要概念，值得企業級應用去認真考慮。我們最近已經采用此風格構建了多個系統，也知道有人也使用并贊同此方法。

我們所知的微服務架構的先驅包括亞馬遜(Amazon)、網飛(Negflix)、衛報(Guardian)、英國政府數字化服務部門(UK Government Digital Service)、realestate.com.au、Forward 和 comparethemarket.com 等。

2013 年的 The Conference Circuit 大會充滿了各種公司案例，他們正在遷移到微服務類別的產品和服務，其中包括 Travis CI。此外也有大量機構一直在做類似微服務的事情，但是并未采用此名稱。(通常被標記為 SOA，不過 SOA 以各種矛盾的形態出現)

盡管有這些切實的經驗，但是我們并不能堅決肯定微服務就是軟件架構未來的發展方向。在微服務方面積累積極經驗(與一體化應用相比)的同時，我們仍保持清醒——微服務還沒有經過足夠長時間的檢驗，因而還不能做出完整判斷。

我們的同事 Sam Newman 2014年的時候花費了大量時間寫書，記錄了我們構建微服務的經歷。如果你想深入研究此主題，那你下一步也應該這么做。

微服務架構決定的實際效果需要多年后才能顯現。我們已經看到一些由對模塊化有強烈需求的優秀團隊構建的一體化架構的項目，在多年后衰退。由于服務邊界明確，且難以修補，許多人認為微服務不可能有此衰退。除非我們能看到足夠多上年頭的系統，否則還是不能完全評價微服務的成熟度。

當然也有其它原因讓人們認為微服務不夠成熟。在各種組件化的努力中，成功依賴于軟件與組件的相符程度。要弄清組件的邊界在哪里，這非常難。自我進化的設計認識到了讓邊界正確的難度，以及由此而來的讓重構保持簡單的重要性。不過一旦你的組件是需要遠程通訊的服務，那重構要比采用聯機庫的服務更難。跨服務邊界的代碼遷移也很困難，任何界面變化都需要在參與者之間協調，也要添加對后端兼容的層，測試也會更復雜。

另一個問題就是，假如組件不能干凈地組合，那么你所做的不過是把復雜性從組件內部轉移成組件之間的聯結。這樣做不僅僅是復雜性的遷移，同時也變得更不明確，也更難以控制。如果只是查看一個小而簡單的組件內部，而忽略服務之間混亂的聯結，那你很容易就覺得更好。

***，團隊技能也是一大因素。新技術很容易被技術熟練的團隊采用。不過一項對熟練團隊來說更有效的技術，可能并不適合稍遜一籌的團隊。我們已經見證了很多技術水平稍遜的團隊構建的凌亂的一體化架構;采用微服務會發生怎樣的混亂，也需要時間觀察。水平不佳的團隊會一直創建不太好的系統，在這種情況下，很難說微服務是會減少混亂，還是會讓情況更糟。

我們聽到的一個合理的說法是你不應該一開始就用微服務架構。相反，以一體化開始，保持模塊化，一旦一體化變得麻煩，就將其拆分為微服務。(不過這一建議不甚理想，因為一個好的聯機接口通常并不是一個好的服務接口)

我們以謹慎樂觀的態度寫下此文。到目前為止，我們已經足夠了解微服務的風格，也認為值得踏上此路。我們不能肯定地說終點何在，不過軟件開發中的一大挑戰就是你只能基于當下所掌握的不完整的信息做決定。