[[170473]]

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

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

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

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

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

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

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

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

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

微服務(wù)架構(gòu)的特征 我們不能給微服務(wù)架構(gòu)下準(zhǔn)確的定義，但是我們可以嘗試總結(jié)一些通用特征。并不是所有的微服務(wù)架構(gòu)完全符合下文列出的這些特征，不過(guò)我們可以預(yù)計(jì)大部分微服務(wù)架構(gòu)能符合大多數(shù)。作為這個(gè)松散社區(qū)的活躍分子，我們(指兩位作者)將嘗試描繪我們?cè)诠ぷ骱臀覀兪煜さ膱F(tuán)隊(duì)中看到的情況。

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

我們已經(jīng)在軟件行業(yè)浸淫多年，一直期望能夠通過(guò)拼插組件的方式來(lái)構(gòu)建系統(tǒng)，而不是采用我們?cè)谖锢硎澜缋锍Ｒ?jiàn)的方式。在過(guò)去的幾十年里，我們已經(jīng)見(jiàn)證了多數(shù)語(yǔ)言平臺(tái)的公共庫(kù)的匯編已經(jīng)取得了長(zhǎng)足的進(jìn)步。

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

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

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

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

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

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

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

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

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

— Melvyn Conway, 1967

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

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

圖 3：通過(guò)團(tuán)隊(duì)界限強(qiáng)化服務(wù)界限

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

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

產(chǎn)品而非項(xiàng)目

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

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

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

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

智能終端和啞管道

要在不同進(jìn)程之間構(gòu)建通信結(jié)構(gòu)，我們已經(jīng)見(jiàn)過(guò)許多產(chǎn)品和方案，它們強(qiáng)調(diào)在通信機(jī)制內(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)用致力于在盡可能地解耦合的同時(shí)保持關(guān)聯(lián)性——他們擁有自己的域名邏輯，從經(jīng)典 Unix 的視角看來(lái)更像過(guò)濾器——接收請(qǐng)求，恰當(dāng)?shù)貞?yīng)用邏輯，生成反應(yīng)。這些編排使用了簡(jiǎn)單的 REST 協(xié)議而非 WS-Choreography 或者 BPEL ，也沒(méi)有采用使用中心化工具進(jìn)行編配。

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

成為 web ，不要隱藏其后

—— 伊恩·羅賓遜

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

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

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

去中心化治理

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

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

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

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

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

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

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

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

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

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

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

圖4：一體化設(shè)計(jì)：?jiǎn)我粩?shù)據(jù)庫(kù) vs 微服務(wù)：應(yīng)用數(shù)據(jù)庫(kù)

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

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

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

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

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

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

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

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

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

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

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

為故障而生

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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