[[170473]]

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

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

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

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

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

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

圖 1：一體化 vs 微服務(wù)

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

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

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

通過服務(wù)實現(xiàn)組件化

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

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

微服務(wù)架構(gòu)也會用到庫，不過組件化軟件的方式是把軟件分解為服務(wù)。我們把庫定義為一個程序中互相連接的組件，調(diào)用內(nèi)存函數(shù)，同時這些服務(wù)是進(jìn)程外部的組件，通過網(wǎng)頁服務(wù)請求或者遠(yuǎn)程調(diào)用通信的方式進(jìn)行通信。(這與面向?qū)ο缶幊讨械姆?wù)對象的概念并不相同)

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

把服務(wù)當(dāng)作組件使用的另一成果就是更為明確的組件接口。大多數(shù)語言缺乏良好機制去定義一個準(zhǔn)確的發(fā)布接口。通常只有文檔和規(guī)則來阻止客戶端去中斷組件的封裝，結(jié)果導(dǎo)致組件的過度耦合。通過使用準(zhǔn)確的遠(yuǎn)程調(diào)用機制，服務(wù)能輕松避免這些問題。

使用服務(wù)也有不足之處。遠(yuǎn)程調(diào)用比進(jìn)程內(nèi)調(diào)用更昂貴，遠(yuǎn)程 API 也需要粗粒度，這往往更加難以使用。如果你需要更改組件之間的職責(zé)分配，那么在跨越進(jìn)程邊界時就很難進(jìn)行這樣的操作。

乍一看，我們能觀察到服務(wù)映射到運行時的過程，不過也僅僅是個大概。一個服務(wù)可能包含多個進(jìn)程，它們會永遠(yuǎn)被開發(fā)和部署在一起，那么這樣的應(yīng)用進(jìn)程和數(shù)據(jù)庫也就只能被這一服務(wù)使用。

圍繞業(yè)務(wù)能力組織

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

任何試圖設(shè)計一個系統(tǒng)(廣義定義)的組織將會衍生出一種設(shè)計，其結(jié)構(gòu)正是該組織的通信結(jié)構(gòu)的復(fù)刻。

— Melvyn Conway, 1967

圖 2: Conway 效應(yīng)在運行

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

圖 3：通過團隊界限強化服務(wù)界限

www.comparethemarket.com 就采用了這種組織方式?？绻δ艿膱F隊對構(gòu)建和運行每個產(chǎn)品負(fù)責(zé)，每個產(chǎn)品又被拆分為大量的單個服務(wù)，這些服務(wù)通過信息總線通信。

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

產(chǎn)品而非項目

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

微服務(wù)的支持者則易于避免此模式，傾向于「在產(chǎn)品的整個生命周期里，開發(fā)團隊?wèi)?yīng)該擁有此項目」。這一靈感來自于亞馬遜的「你構(gòu)建，你運行」概念。在亞馬遜，開發(fā)團隊對生產(chǎn)環(huán)境中的軟件負(fù)有全部責(zé)任。這讓開發(fā)者每日都能了解自己的軟件如何在生產(chǎn)環(huán)境運行，增強與用戶的接觸，也能承擔(dān)部分支持職責(zé)。

這種產(chǎn)品意識與業(yè)務(wù)能力緊緊聯(lián)系。與其把軟件看作一套需要完成的功能，不如把它們看作一段進(jìn)行中的關(guān)系，其中的關(guān)鍵問題是軟件如何幫助用戶增強業(yè)務(wù)能力。

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

智能終端和啞管道

要在不同進(jìn)程之間構(gòu)建通信結(jié)構(gòu)，我們已經(jīng)見過許多產(chǎn)品和方案，它們強調(diào)在通信機制內(nèi)部注入智能，其中優(yōu)秀案例如 ESB(企業(yè)服務(wù)總線)。ESB 產(chǎn)品包含復(fù)雜的設(shè)施，用于信息路由、編排、轉(zhuǎn)化，以及應(yīng)用業(yè)務(wù)規(guī)則。

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

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

成為 web ，不要隱藏其后

—— 伊恩·羅賓遜

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

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

在大型應(yīng)用里，組件聯(lián)機執(zhí)行，它們之間的通信或者采用方法調(diào)用，或者調(diào)用函數(shù)。在大型應(yīng)用到微服務(wù)的轉(zhuǎn)變中，***的問題就是通信模式的改變。從內(nèi)存調(diào)用函數(shù)的本地對話轉(zhuǎn)為 RPC，可能會變成性能不佳的聊天式通信。并且，你還需要用粗粒度的方法代替原來的精細(xì)通信。

去中心化治理

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

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

當(dāng)然，能做并不等于要那樣做——不過這種系統(tǒng)切割方法給了你選擇權(quán)。

構(gòu)建微服務(wù)的團隊也愿意使用別的方法達(dá)到標(biāo)準(zhǔn)。與其使用紙面上的現(xiàn)成標(biāo)準(zhǔn)，他們更愿意使開發(fā)有用的工具，從而別的開發(fā)者也能夠用來解決相似問題。這些工具通常通過實施收獲成果，以包括內(nèi)部開源模式在內(nèi)的方式更廣泛的群體中分享?，F(xiàn)在 git 和 github 已經(jīng)成為事實上的版本控制系統(tǒng)，開源實踐也在機構(gòu)內(nèi)部越來越常見。

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

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

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

去中心化數(shù)據(jù)管理

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

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

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

圖4：一體化設(shè)計：單一數(shù)據(jù)庫 vs 微服務(wù)：應(yīng)用數(shù)據(jù)庫

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

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

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

基礎(chǔ)設(shè)施自動化

基礎(chǔ)設(shè)施自動化已經(jīng)在過去的幾年里取得了巨大的進(jìn)步。云特別是 AWS 的進(jìn)化格外地降低了構(gòu)建、部署和運行微服務(wù)時的復(fù)雜度。

許多采用微服務(wù)構(gòu)建的產(chǎn)品或系統(tǒng)是由在持續(xù)交付和其前身——持續(xù)集成方面經(jīng)驗豐富的團隊構(gòu)建的。使用這種方法構(gòu)建軟件的團隊需要大量使用基礎(chǔ)設(shè)施自動化技術(shù)。下圖展示了構(gòu)建流程。

圖5：基本的構(gòu)建流程

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

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

另一個常見的使用大規(guī)?；A(chǔ)設(shè)施自動化的領(lǐng)域就是在生產(chǎn)環(huán)境中管理微服務(wù)。前文我們認(rèn)為只要部署一如既往地單調(diào)，那在一體化和微服務(wù)之間相差不會太大;恰恰與此相反，在運行階段，二者卻是相去甚遠(yuǎn)。

圖6：模塊部署經(jīng)常不同

為故障而生

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

這種生產(chǎn)環(huán)境中的自動化測試足以讓大多數(shù)的運營團隊望而生畏，通常后者需要提前一周的時間。這并非說一體化架構(gòu)風(fēng)格不能盡興這種精密的監(jiān)控設(shè)置，只是不常見于我們的經(jīng)驗。

既然服務(wù)可能隨時發(fā)生故障，所以能夠快速監(jiān)測并盡可能地自動恢復(fù)服務(wù)就非常重要。微服務(wù)應(yīng)用側(cè)重于應(yīng)用的實時監(jiān)控，檢查架構(gòu)因素(數(shù)據(jù)庫每秒獲得多少請求)和業(yè)務(wù)相關(guān)指標(biāo)(每分鐘收到多少訂單)。語義監(jiān)控也可提供早期預(yù)警系統(tǒng)，一旦出錯就觸發(fā)開發(fā)團隊去跟進(jìn)和調(diào)查。

對于微服務(wù)架構(gòu)來說這尤為重要，因為微服務(wù)更偏好編配和事件協(xié)作導(dǎo)致的自發(fā)行為。盡管許多專家認(rèn)可偶發(fā)價值，事實上意外行為并非好事。監(jiān)控對于發(fā)現(xiàn)糟糕的意外行為至關(guān)重要，從而能夠盡快修復(fù)。

一體化也可以像微服務(wù)那樣透明構(gòu)建，事實上，他們也應(yīng)如此。區(qū)別在于你必須要了解運行在不同進(jìn)程的服務(wù)們是何時斷開的?？紤]到相同進(jìn)程內(nèi)的庫，這種透明度不太可能有用。

微服務(wù)團隊希望能為每個單獨的服務(wù)設(shè)置精密的監(jiān)控和記錄，這些服務(wù)包括在 dashboard 上顯示服務(wù)啟用/宕機狀態(tài)，以及各種相關(guān)的運營和業(yè)務(wù)指標(biāo)。與斷路器狀態(tài)、當(dāng)前吞吐量和延遲的詳情都是我們經(jīng)常遇到的其它例子。

進(jìn)化的設(shè)計

微服務(wù)從業(yè)者通常具有進(jìn)化設(shè)計的背景，把服務(wù)分解視作一個長遠(yuǎn)的工具，讓應(yīng)用開發(fā)者們能夠控制應(yīng)用內(nèi)的改動，無需讓改動慢下來。改動控制并不一定意味著減少——借助正確的態(tài)度和工具，你能夠經(jīng)常快速、有節(jié)制地修改軟件。

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

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

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

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

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

我們所知的微服務(wù)架構(gòu)的先驅(qū)包括亞馬遜(Amazon)、網(wǎng)飛(Negflix)、衛(wèi)報(Guardian)、英國政府?dāng)?shù)字化服務(wù)部門(UK Government Digital Service)、realestate.com.au、Forward 和 comparethemarket.com 等。

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

盡管有這些切實的經(jīng)驗，但是我們并不能堅決肯定微服務(wù)就是軟件架構(gòu)未來的發(fā)展方向。在微服務(wù)方面積累積極經(jīng)驗(與一體化應(yīng)用相比)的同時，我們?nèi)员３智逍?mdash;—微服務(wù)還沒有經(jīng)過足夠長時間的檢驗，因而還不能做出完整判斷。

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

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

當(dāng)然也有其它原因讓人們認(rèn)為微服務(wù)不夠成熟。在各種組件化的努力中，成功依賴于軟件與組件的相符程度。要弄清組件的邊界在哪里，這非常難。自我進(jìn)化的設(shè)計認(rèn)識到了讓邊界正確的難度，以及由此而來的讓重構(gòu)保持簡單的重要性。不過一旦你的組件是需要遠(yuǎn)程通訊的服務(wù)，那重構(gòu)要比采用聯(lián)機庫的服務(wù)更難?？绶?wù)邊界的代碼遷移也很困難，任何界面變化都需要在參與者之間協(xié)調(diào)，也要添加對后端兼容的層，測試也會更復(fù)雜。

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

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

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

我們以謹(jǐn)慎樂觀的態(tài)度寫下此文。到目前為止，我們已經(jīng)足夠了解微服務(wù)的風(fēng)格，也認(rèn)為值得踏上此路。我們不能肯定地說終點何在，不過軟件開發(fā)中的一大挑戰(zhàn)就是你只能基于當(dāng)下所掌握的不完整的信息做決定。