“微服務(wù)架構(gòu)”這一術(shù)語(yǔ)在前幾年橫空出世，用于描述這樣一種特定的軟件設(shè)計(jì)方法，即以若干組可獨(dú)立部署的服務(wù)的方式進(jìn)行軟件應(yīng)用系統(tǒng)的設(shè)計(jì)。盡管這種架構(gòu)風(fēng)格尚無(wú)明確的定義，但其在下述方面還是存在一定的共性，即圍繞業(yè)務(wù)功能的組織、自動(dòng)化部署、端點(diǎn)智能、以及在編程語(yǔ)言和數(shù)據(jù)方面進(jìn)行去中心化的控制。 

“微服務(wù)”——這是在“軟件架構(gòu)”這條熙熙攘攘的大街上出現(xiàn)的又一個(gè)新詞語(yǔ)。我們很容易對(duì)它不屑一顧，但是這個(gè)小小的術(shù)語(yǔ)卻描述了一種引人入勝的軟件系統(tǒng)風(fēng)格。在近幾年中，我們?cè)絹?lái)越多的看到許多項(xiàng)目使用了這種風(fēng)格，而且就目前來(lái)說(shuō)結(jié)果都是不錯(cuò)的，以至于許多ThoughtWorker都把它看作構(gòu)建企業(yè)應(yīng)用系統(tǒng)的默認(rèn)風(fēng)格。然而，很不幸的是，我們找不到有關(guān)它的概要信息，即什么是微服務(wù)風(fēng)格，以及如何設(shè)計(jì)微服務(wù)風(fēng)格的架構(gòu)。

簡(jiǎn)而言之，微服務(wù)架構(gòu)風(fēng)格這種開(kāi)發(fā)方法，是以開(kāi)發(fā)一組小型服務(wù)的方式來(lái)開(kāi)發(fā)一個(gè)獨(dú)立的應(yīng)用系統(tǒng)。其中每個(gè)小型服務(wù)都運(yùn)行在自己的進(jìn)程中，并經(jīng)常采用HTTP資源API這樣輕量的機(jī)制來(lái)相互通信。這些服務(wù)圍繞業(yè)務(wù)功能進(jìn)行構(gòu)建，并能通過(guò)全自動(dòng)的部署機(jī)制來(lái)進(jìn)行獨(dú)立部署。這些微服務(wù)可以使用不同的語(yǔ)言來(lái)編寫(xiě)，并且可以使用不同的數(shù)據(jù)存儲(chǔ)技術(shù)。對(duì)這些微服務(wù)，我們僅做***限度的集中管理。

在開(kāi)始介紹微服務(wù)風(fēng)格之前，將其與單塊(monolithic)風(fēng)格進(jìn)行對(duì)比還是很有意義的：一個(gè)單塊應(yīng)用系統(tǒng)是以一個(gè)單個(gè)單元的方式來(lái)構(gòu)建的。企業(yè)應(yīng)用系統(tǒng)經(jīng)常包含三個(gè)主要部分：客戶端用戶界面、數(shù)據(jù)庫(kù)和服務(wù)端應(yīng)用系統(tǒng)?？蛻舳擞脩艚缑姘℉TML頁(yè)面和運(yùn)行在用戶機(jī)器的瀏覽器中的JavaScript。數(shù)據(jù)庫(kù)中包括許多表，這些表被插入一個(gè)公共的且通常為關(guān)系型的數(shù)據(jù)庫(kù)管理系統(tǒng)中。這個(gè)服務(wù)端的應(yīng)用系統(tǒng)就是一個(gè)單塊應(yīng)用——一個(gè)單個(gè)可執(zhí)行的邏輯程序。對(duì)于該系統(tǒng)的任何改變，都會(huì)涉及構(gòu)建和部署上述服務(wù)端應(yīng)用系統(tǒng)的一個(gè)新版本。

這樣的單塊服務(wù)器是構(gòu)建上述系統(tǒng)的一種自然的方式。處理用戶請(qǐng)求的所有邏輯都運(yùn)行在一個(gè)單個(gè)的進(jìn)程內(nèi)，因此能使用編程語(yǔ)言的基本特性，來(lái)把應(yīng)用系統(tǒng)劃分為類、函數(shù)和命名空間。通過(guò)精心設(shè)計(jì)，得以在開(kāi)發(fā)人員的筆記本電腦上運(yùn)行和測(cè)試這樣的應(yīng)用系統(tǒng)，并且使用一個(gè)部署流水線來(lái)確保變更被很好地進(jìn)行了測(cè)試，并被部署到生產(chǎn)環(huán)境中。通過(guò)負(fù)載均衡器運(yùn)行許多實(shí)例，來(lái)將這個(gè)單塊應(yīng)用進(jìn)行橫向擴(kuò)展。

單塊應(yīng)用系統(tǒng)可以被成功地實(shí)現(xiàn)，但是漸漸地，特別是隨著越來(lái)越多的應(yīng)用系統(tǒng)正被部署到云端，人們對(duì)它們開(kāi)始表現(xiàn)出不滿。軟件變更受到了很大的限制，應(yīng)用系統(tǒng)中一個(gè)很小部分的一處變更，也需要將整個(gè)單塊應(yīng)用系統(tǒng)進(jìn)行重新構(gòu)建和部署。隨著時(shí)間的推移，單塊應(yīng)用逐漸難以保持一個(gè)良好的模塊化結(jié)構(gòu)，這使得它變得越來(lái)越難以將一個(gè)模塊的變更所產(chǎn)生的影響控制在該模塊內(nèi)。當(dāng)對(duì)系統(tǒng)進(jìn)行擴(kuò)展時(shí)，不得不擴(kuò)展整個(gè)應(yīng)用系統(tǒng)，而不能僅擴(kuò)展該系統(tǒng)中需要更多資源的那些部分。

圖1: 單塊應(yīng)用和微服務(wù)

這些不滿催生出了微服務(wù)架構(gòu)風(fēng)格：以構(gòu)建一組小型服務(wù)的方式來(lái)構(gòu)建應(yīng)用系統(tǒng)。除了這些服務(wù)能被獨(dú)立地部署和擴(kuò)展之外，每一個(gè)服務(wù)還能提供一個(gè)穩(wěn)固的模塊邊界，甚至能允許使用不同的編程語(yǔ)言來(lái)編寫(xiě)不同的服務(wù)。這些服務(wù)也能被不同的團(tuán)隊(duì)來(lái)管理。

我們并不認(rèn)為微服務(wù)風(fēng)格是一個(gè)新穎或創(chuàng)新的概念，它的起源至少可以追溯到Unix的設(shè)計(jì)原則。但是我們覺(jué)得，考慮微服務(wù)架構(gòu)的人還不夠多，并且如果對(duì)其加以使用，許多軟件的開(kāi)發(fā)工作能變得更好。

一、微服務(wù)架構(gòu)的九大特性

雖然不能說(shuō)存在微服務(wù)架構(gòu)風(fēng)格的正式定義，但是可以嘗試描述我們所見(jiàn)到的、能夠被貼上“微服務(wù)”標(biāo)簽的那些架構(gòu)的共性。下面所描述的這些共性，并不是所有的微服務(wù)架構(gòu)都完全具備，但是我們確實(shí)期望大多數(shù)微服務(wù)架構(gòu)都具備這些共性中的大多數(shù)特性。盡管我們兩位作者已經(jīng)成為這個(gè)相當(dāng)松散的社區(qū)中的活躍成員，但我們的本意還是描述我們兩人在自己所在和所了解的團(tuán)隊(duì)工作中所看到的情況。特別要指出，我們不會(huì)制定大家需要遵循的微服務(wù)的定義。

特性一：“組件化”與“多服務(wù)”

自我們從事軟件行業(yè)以來(lái)，發(fā)現(xiàn)大家都有“把組件插在一起來(lái)構(gòu)建系統(tǒng)”的愿望，就像在物理世界中所看到的那樣。在過(guò)去幾十年中，我們已經(jīng)看到，在公共軟件庫(kù)方面已經(jīng)取得了相當(dāng)大的進(jìn)展，這些軟件庫(kù)是大多數(shù)編程語(yǔ)言平臺(tái)的組成部分。

當(dāng)談到組件時(shí)，會(huì)碰到一個(gè)有關(guān)定義的難題，即什么是組件?我們的定義是：一個(gè)組件就是一個(gè)可以獨(dú)立更換和升級(jí)的軟件單元。

微服務(wù)架構(gòu)也會(huì)使用軟件庫(kù)，但其將自身軟件進(jìn)行組件化的主要方法是將軟件分解為諸多服務(wù)。我們將軟件庫(kù)(libraries)定義為這樣的組件，即它能被鏈接到一段程序，且能通過(guò)內(nèi)存中的函數(shù)來(lái)進(jìn)行調(diào)用。然而，服務(wù)(services)是進(jìn)程外的組件，它們通過(guò)諸如web service請(qǐng)求或遠(yuǎn)程過(guò)程調(diào)用這樣的機(jī)制來(lái)進(jìn)行通信(這不同于許多面向?qū)ο蟮某绦蛑械膕ervice object概念)。

以使用服務(wù)(而不是以軟件庫(kù))的方式來(lái)實(shí)現(xiàn)組件化的一個(gè)主要原因是，服務(wù)可被獨(dú)立部署。如果一個(gè)應(yīng)用系統(tǒng)由在單個(gè)進(jìn)程中的多個(gè)軟件庫(kù)所組成，那么對(duì)任一組件做一處修改，都不得不重新部署整個(gè)應(yīng)用系統(tǒng)。但是如果該應(yīng)用系統(tǒng)被分解為多個(gè)服務(wù)，那么對(duì)于一個(gè)服務(wù)的多處修改，僅需要重新部署這一個(gè)服務(wù)。當(dāng)然這也不是絕對(duì)的，一些變更服務(wù)接口的修改會(huì)導(dǎo)致多個(gè)服務(wù)之間的協(xié)同修改。但是一個(gè)良好的微服務(wù)架構(gòu)的目的，是通過(guò)內(nèi)聚的服務(wù)邊界和服務(wù)協(xié)議方面的演進(jìn)機(jī)制，來(lái)將這樣的修改變得最小化。

以服務(wù)的方式來(lái)實(shí)現(xiàn)組件化的另一個(gè)結(jié)果，是能獲得更加顯式的(explicit)組件接口。大多數(shù)編程語(yǔ)言并沒(méi)有一個(gè)良好的機(jī)制來(lái)定義顯式的發(fā)布接口。通常情況下，這樣的接口僅僅是文檔聲明和團(tuán)隊(duì)紀(jì)律，來(lái)避免客戶端破壞組件的封裝，從而導(dǎo)致組件間出現(xiàn)過(guò)度緊密的耦合。通過(guò)使用顯式的遠(yuǎn)程調(diào)用機(jī)制，服務(wù)能更容易地規(guī)避這種情況。

如此使用服務(wù)，也會(huì)有不足之處。比起進(jìn)程內(nèi)調(diào)用，遠(yuǎn)程調(diào)用更加昂貴。所以遠(yuǎn)程調(diào)用API接口必須是粗粒度的，而這往往更加難以使用。如果需要修改組件間的職責(zé)分配，那么當(dāng)跨越進(jìn)程邊界時(shí)，這種組件行為的改動(dòng)會(huì)更加難以實(shí)現(xiàn)。

近似地，我們可以把一個(gè)個(gè)服務(wù)映射為一個(gè)個(gè)運(yùn)行時(shí)的進(jìn)程，但這僅僅是一個(gè)近似。一個(gè)服務(wù)可能包括總是在一起被開(kāi)發(fā)和部署的多個(gè)進(jìn)程，比如一個(gè)應(yīng)用系統(tǒng)的進(jìn)程和僅被該服務(wù)使用的數(shù)據(jù)庫(kù)。

特性二：圍繞“業(yè)務(wù)功能”組織團(tuán)隊(duì)

當(dāng)在尋求將一個(gè)大型應(yīng)用系統(tǒng)分解成幾部分時(shí)，公司管理層往往會(huì)聚焦在技術(shù)層面上，這就意味著要組建用戶界面團(tuán)隊(duì)、服務(wù)器端團(tuán)隊(duì)和數(shù)據(jù)庫(kù)團(tuán)隊(duì)。當(dāng)團(tuán)隊(duì)沿著這些技術(shù)線分開(kāi)后，即使要實(shí)現(xiàn)軟件中一個(gè)簡(jiǎn)單的變更，也會(huì)發(fā)生跨團(tuán)隊(duì)的項(xiàng)目時(shí)延和預(yù)算審批。在這種情況下，聰明的團(tuán)隊(duì)會(huì)進(jìn)行局部?jī)?yōu)化，“兩害相權(quán)取其輕”，來(lái)直接把代碼邏輯塞到他們能訪問(wèn)到的任意應(yīng)用系統(tǒng)中。換句話說(shuō)，這種情況會(huì)導(dǎo)致代碼邏輯散布在系統(tǒng)各處。這就是康威定律的鮮活實(shí)例。

圖2：康威定律在起作用

微服務(wù)使用不同的方法來(lái)分解系統(tǒng)，即根據(jù)業(yè)務(wù)功能(business capability)來(lái)將系統(tǒng)分解為若干服務(wù)。這些服務(wù)針對(duì)該業(yè)務(wù)領(lǐng)域提供多層次、廣泛的軟件實(shí)現(xiàn)，包括用戶界面、持久性存儲(chǔ)以及任何對(duì)外的協(xié)作性操作。因此，團(tuán)隊(duì)是跨職能的，它擁有軟件開(kāi)發(fā)所需的全方位的技能：用戶體驗(yàn)、數(shù)據(jù)庫(kù)和項(xiàng)目管理。

圖3：被團(tuán)隊(duì)邊界所強(qiáng)化的服務(wù)邊界

以上述方式來(lái)組織團(tuán)隊(duì)的公司是www.comparethemarket.com?？缏毮軋F(tuán)隊(duì)負(fù)責(zé)構(gòu)建和運(yùn)維每個(gè)產(chǎn)品，而每個(gè)產(chǎn)品被拆分為多個(gè)獨(dú)立的服務(wù)，彼此通過(guò)一個(gè)消息總線來(lái)通信。

一個(gè)微服務(wù)應(yīng)該有多大?

盡管許多人已經(jīng)習(xí)慣于用“微服務(wù)”來(lái)概括描述這種這種架構(gòu)風(fēng)格，但是這個(gè)名字確實(shí)會(huì)不幸地引發(fā)大家對(duì)服務(wù)規(guī)模的關(guān)注，并且產(chǎn)生有關(guān)什么是“微”的爭(zhēng)論。在與微服務(wù)從業(yè)者的交談中，我們看到了有關(guān)服務(wù)的一系列規(guī)模。所聽(tīng)到的***的一個(gè)服務(wù)規(guī)模，是遵循了亞馬遜的“兩個(gè)比薩團(tuán)隊(duì)”(即一個(gè)團(tuán)隊(duì)可以被兩個(gè)比薩所喂飽)的理念所形成的，這意味著這個(gè)團(tuán)隊(duì)不會(huì)多于12人。對(duì)于規(guī)模較小的服務(wù)，我們已經(jīng)看到一個(gè)6人的團(tuán)隊(duì)在支持6個(gè)服務(wù)。

這引出了一個(gè)問(wèn)題，即“每12人做一個(gè)服務(wù)”和“每人做一個(gè)服務(wù)”這樣有關(guān)服務(wù)規(guī)模的差距，是否已經(jīng)大到不能將兩者都納入微服務(wù)之下?此時(shí)，我們認(rèn)為***還是把它們歸為一類，但是隨著探索的深入，我們將來(lái)極有可能會(huì)改變主意。

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

特性三：“做產(chǎn)品”而不是“做項(xiàng)目”

我們所看的大部分應(yīng)用系統(tǒng)的開(kāi)發(fā)工作都使用項(xiàng)目模型：目標(biāo)是交付某一塊軟件，之后就認(rèn)為完工了。一旦完工后，軟件就被移交給維護(hù)團(tuán)隊(duì)，接著那個(gè)構(gòu)建該軟件的項(xiàng)目團(tuán)隊(duì)就會(huì)被解散。

微服務(wù)的支持者們傾向于避免使用上述模型，而寧愿采納“一個(gè)團(tuán)隊(duì)在一個(gè)產(chǎn)品的整個(gè)生命周期中都應(yīng)該保持對(duì)其擁有”的理念。通常認(rèn)為這一點(diǎn)源自亞馬遜的“誰(shuí)構(gòu)建，誰(shuí)運(yùn)行”的理念，即一個(gè)開(kāi)發(fā)團(tuán)隊(duì)對(duì)一個(gè)在生產(chǎn)環(huán)境下運(yùn)行的軟件負(fù)全責(zé)。這會(huì)使開(kāi)發(fā)人員每天都關(guān)注軟件是如何在生產(chǎn)環(huán)境下運(yùn)行的，并且增進(jìn)他們與用戶的聯(lián)系，因?yàn)樗麄儽仨毘袚?dān)某些支持工作。

這樣的“產(chǎn)品”理念，是與業(yè)務(wù)功能的聯(lián)動(dòng)綁定在一起的。它不會(huì)將軟件看作是一個(gè)待完成的功能集合，而是認(rèn)為存在這樣一個(gè)持續(xù)的關(guān)系，即軟件如何能助其客戶來(lái)持續(xù)增進(jìn)業(yè)務(wù)功能。

當(dāng)然，單塊應(yīng)用系統(tǒng)的開(kāi)發(fā)工作也可以遵循上述“產(chǎn)品”理念，但是更細(xì)粒度的服務(wù)，能讓服務(wù)的開(kāi)發(fā)者與其用戶之間的個(gè)人關(guān)系的創(chuàng)建變得更加容易。

特性四：“智能端點(diǎn)”與“傻瓜管道”

當(dāng)在不同的進(jìn)程之間構(gòu)建各種通信結(jié)構(gòu)時(shí)，我們已經(jīng)看到許多產(chǎn)品和方法，來(lái)強(qiáng)調(diào)將大量的智能特性納入通信機(jī)制本身。其中一個(gè)典型例子，就是“企業(yè)服務(wù)總線”(Enterprise Service Bus, ESB)。ESB產(chǎn)品經(jīng)常包括高度智能的設(shè)施，來(lái)進(jìn)行消息的路由、編制(choreography)、轉(zhuǎn)換，并應(yīng)用業(yè)務(wù)規(guī)則。

微服務(wù)社區(qū)主張采用另一種做法：智能端點(diǎn)(smart endpoints)和傻瓜管道(dumb pipes)。使用微服務(wù)所構(gòu)建的各個(gè)應(yīng)用的目標(biāo)，都是盡可能地實(shí)現(xiàn)“高內(nèi)聚和低耦合”——他們擁有自己的領(lǐng)域邏輯，并且更像是經(jīng)典Unix的“過(guò)濾器”(filter)那樣來(lái)工作——即接收一個(gè)請(qǐng)求，酌情對(duì)其應(yīng)用業(yè)務(wù)邏輯，并產(chǎn)生一個(gè)響應(yīng)。這些應(yīng)用通過(guò)使用一些簡(jiǎn)單的REST風(fēng)格的協(xié)議來(lái)進(jìn)行編制，而不去使用諸如下面這些復(fù)雜的協(xié)議，即"WS-編制"(WS-Choreography)、BPEL或通過(guò)位于中心的工具來(lái)進(jìn)行編排(orchestration)。

微服務(wù)最常用的兩種協(xié)議是：帶有資源API的HTTP“請(qǐng)求-響應(yīng)”協(xié)議，和輕量級(jí)的消息發(fā)送協(xié)議。對(duì)于前一種協(xié)議的***表述是：

這些微服務(wù)團(tuán)隊(duì)在開(kāi)發(fā)中，使用在構(gòu)建萬(wàn)維網(wǎng)(world wide web)時(shí)所使用的原則和協(xié)議(并且在很大程度上，這些原則和協(xié)議也是在構(gòu)建Unix系統(tǒng)時(shí)所使用的)。那些被使用過(guò)的HTTP資源，通常能被開(kāi)發(fā)或運(yùn)維人員輕易地緩存起來(lái)。

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

在一個(gè)單塊系統(tǒng)中，各個(gè)組件在同一個(gè)進(jìn)程中運(yùn)行。它們相互之間的通信，要么通過(guò)方法調(diào)用，要么通過(guò)函數(shù)調(diào)用來(lái)進(jìn)行。將一個(gè)單塊系統(tǒng)改造為若干微服務(wù)的***問(wèn)題，在于對(duì)通信模式的改變。僅僅將內(nèi)存中的方法調(diào)用轉(zhuǎn)換為RPC調(diào)用這樣天真的做法，會(huì)導(dǎo)致微服務(wù)之間產(chǎn)生繁瑣的通信，使得系統(tǒng)表現(xiàn)變?cè)恪Ｈ《氖?，需要用更粗粒度的協(xié)議來(lái)替代細(xì)粒度的服務(wù)間通信。

特性五：“去中心化”的治理技術(shù)

使用中心化的方式來(lái)對(duì)開(kāi)發(fā)進(jìn)行治理，其中一個(gè)后果，就是趨向于在單一技術(shù)平臺(tái)上制定標(biāo)準(zhǔn)。經(jīng)驗(yàn)表明，這種做法會(huì)帶來(lái)局限性——不是每一個(gè)問(wèn)題都是釘子，不是每一個(gè)方案都是錘子。我們更喜歡根據(jù)工作的不同來(lái)選用合理的工具。盡管那些單塊應(yīng)用系統(tǒng)能在一定程度上利用不同的編程語(yǔ)言，但是這并不常見(jiàn)。

如果能將單塊應(yīng)用的那些組件拆分成多個(gè)服務(wù)，那么在構(gòu)建每個(gè)服務(wù)時(shí)，就可以有選擇不同技術(shù)棧的機(jī)會(huì)。想要使用Node.js來(lái)搞出一個(gè)簡(jiǎn)單的報(bào)表頁(yè)面?盡管去搞。想用C++來(lái)做一個(gè)特別出彩的近乎實(shí)時(shí)的組件?沒(méi)有問(wèn)題。想要換一種不同風(fēng)格的數(shù)據(jù)庫(kù)，來(lái)更好地適應(yīng)一個(gè)組件的讀取數(shù)據(jù)的行為?可以重建。

(1) 微服務(wù)和SOA

當(dāng)我們談起微服務(wù)時(shí)，一個(gè)常見(jiàn)的問(wèn)題就會(huì)出現(xiàn)：是否微服務(wù)僅僅是十多年前所看到的“面向服務(wù)的架構(gòu)”(Service Oriented Architecture，SOA)?這樣問(wèn)是有道理的，因?yàn)槲⒎?wù)風(fēng)格非常類似于一些支持SOA的人所贊成的觀點(diǎn)。然而，問(wèn)題在于SOA這個(gè)詞兒意味著太多不同的東西。而且大多數(shù)時(shí)候，我們所遇到的某些被稱作"SOA"的事物，明顯不同于本文所描述的風(fēng)格。這通常由于它們專注于ESB，來(lái)集成各個(gè)單塊應(yīng)用。

特別地，我們已經(jīng)看到如此之多的面向服務(wù)的拙劣實(shí)現(xiàn)——從將系統(tǒng)復(fù)雜性隱藏于ESB中的趨勢(shì)，到花費(fèi)數(shù)百萬(wàn)進(jìn)行多年卻沒(méi)有交付任何價(jià)值的失敗項(xiàng)目，到頑固抑制變化發(fā)生的中心化技術(shù)治理模型——以至于有時(shí)覺(jué)得其所造成的種種問(wèn)題真的不堪回首。

當(dāng)然，在微服務(wù)社區(qū)投入使用的許多技術(shù)，源自各個(gè)開(kāi)發(fā)人員將各種服務(wù)集成到各個(gè)大型組織的經(jīng)驗(yàn)。“容錯(cuò)讀取”(Tolerant Reader)模式就是這樣一個(gè)例子。對(duì)于Web的廣泛使用，使得人們不再使用一些中心化的標(biāo)準(zhǔn)，而使用一些簡(jiǎn)單的協(xié)議。坦率地說(shuō)，這些中心化的標(biāo)準(zhǔn)，其復(fù)雜性已經(jīng)達(dá)到令人吃驚的程度。(任何時(shí)候，如果需要一個(gè)本體來(lái)管理其他各個(gè)本體，那么麻煩就大了。)

這種常見(jiàn)的SOA表現(xiàn)，已使得一些微服務(wù)的倡導(dǎo)者完全拒絕將自己貼上SOA的標(biāo)簽。盡管其他人會(huì)將微服務(wù)看作是SOA的一種形式，也許微服務(wù)就是以正確的形式來(lái)實(shí)現(xiàn)面向服務(wù)的SOA。不管是哪種情況，SOA意味著如此之多的不同事物，這表明用一個(gè)更加干凈利落的術(shù)語(yǔ)來(lái)命名這種架構(gòu)風(fēng)格是很有價(jià)值的。

當(dāng)然，僅僅能做事情，并不意味著這些事情就應(yīng)該被做——不過(guò)用微服務(wù)的方法把系統(tǒng)進(jìn)行拆分后，就擁有了技術(shù)選型的機(jī)會(huì)。

相比選用業(yè)界一般常用的技術(shù)，構(gòu)建微服務(wù)的那些團(tuán)隊(duì)更喜歡采用不同的方法。與其選用一組寫(xiě)在紙上已經(jīng)定義好的標(biāo)準(zhǔn)，他們更喜歡編寫(xiě)一些有用的工具，來(lái)讓其他開(kāi)發(fā)者能夠使用，以便解決那些和他們所面臨的問(wèn)題相似的問(wèn)題。這些工具通常源自他們的微服務(wù)實(shí)施過(guò)程，并且被分享到更大規(guī)模的組織中，這種分享有時(shí)會(huì)使用內(nèi)部開(kāi)源的模式來(lái)進(jìn)行。事實(shí)上，現(xiàn)在git和github已經(jīng)成為***版本控制系統(tǒng)。在企業(yè)內(nèi)部，開(kāi)源的做法正在變得越來(lái)越普遍。

Netflix公司是遵循上述理念的好例子。將實(shí)用且經(jīng)過(guò)實(shí)戰(zhàn)檢驗(yàn)的代碼以軟件庫(kù)的形式共享出來(lái)，能鼓勵(lì)其他開(kāi)發(fā)人員以相似的方式來(lái)解決相似的問(wèn)題，當(dāng)然也為在需要的時(shí)候選用不同的方案留了一扇門(mén)。共享軟件庫(kù)往往聚焦于解決這樣的常見(jiàn)問(wèn)題，即數(shù)據(jù)存儲(chǔ)、進(jìn)程間的通信和下面要進(jìn)一步討論的基礎(chǔ)設(shè)施的自動(dòng)化。

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

(2) 多種編程語(yǔ)言，多種選擇可能

做為一個(gè)平臺(tái)，JVM的發(fā)展僅僅是一個(gè)將各種編程語(yǔ)言混合到一個(gè)通用平臺(tái)的***例證。近十年以來(lái)，通過(guò)在平臺(tái)外層實(shí)現(xiàn)更高層次的編程語(yǔ)言，來(lái)利用更高層次的抽象，已經(jīng)成為一個(gè)普遍做法。同樣，在平臺(tái)底層以更低層次的編程語(yǔ)言編寫(xiě)性能敏感的代碼也很普遍。然而，許多單塊系統(tǒng)并不需要這種級(jí)別的性能優(yōu)化，另外DSL和更高層次的抽象也不常用(這令我們感到失望)。相反，許多單塊應(yīng)用通常就使用單一編程語(yǔ)言，并且有對(duì)所使用的技術(shù)數(shù)量進(jìn)行限制的趨勢(shì)。

或許去中心化地治理技術(shù)的極盛時(shí)期，就是亞馬遜的“誰(shuí)構(gòu)建，誰(shuí)運(yùn)行”的理念開(kāi)始普及的時(shí)候。各個(gè)團(tuán)隊(duì)負(fù)責(zé)其所構(gòu)建的軟件的所有工作，其中包括7x24地對(duì)軟件進(jìn)行運(yùn)維。“將運(yùn)維這一級(jí)別的職責(zé)下放到團(tuán)隊(duì)”這種做法，目前絕對(duì)不是主流。但是我們確實(shí)看到越來(lái)越多的公司，將運(yùn)維的職責(zé)交給各個(gè)開(kāi)發(fā)團(tuán)隊(duì)。Netflix就是已經(jīng)形成這種風(fēng)氣的另一個(gè)組織。避免每天凌晨3點(diǎn)被枕邊的尋呼機(jī)叫醒，無(wú)疑是在程序員編寫(xiě)代碼時(shí)令其專注質(zhì)量的強(qiáng)大動(dòng)力。而這些想法，與那些傳統(tǒng)的中心化技術(shù)治理的模式具有天壤之別。

特性六：“去中心化”地管理數(shù)據(jù)

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

上述問(wèn)題在不同的應(yīng)用程序之間經(jīng)常出現(xiàn)，同時(shí)也會(huì)出現(xiàn)在這些應(yīng)用程序內(nèi)部，特別是當(dāng)一個(gè)應(yīng)用程序被分成不同組件時(shí)就會(huì)出現(xiàn)。思考這類問(wèn)題的一個(gè)有效方法，就是使用領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)(Domain-Driven Design, DDD)中的“限界上下文”(Bounded Context)的概念。DDD將一個(gè)復(fù)雜的領(lǐng)域劃分為多個(gè)限界上下文，并且將其相互之間的關(guān)系用圖畫(huà)出來(lái)。這一劃分過(guò)程對(duì)于單塊和微服務(wù)架構(gòu)兩者都是有用的，而且就像前面有關(guān)“業(yè)務(wù)功能”一節(jié)中所討論的那樣，在服務(wù)和各個(gè)限界上下文之間所存在的自然的聯(lián)動(dòng)關(guān)系，有助于澄清和強(qiáng)化這種劃分。

(1) “實(shí)戰(zhàn)檢驗(yàn)”的標(biāo)準(zhǔn)與“強(qiáng)制執(zhí)行”的標(biāo)準(zhǔn)

微服務(wù)的下述做法有點(diǎn)涇渭分明的味道，即他們趨向于避開(kāi)被那些企業(yè)架構(gòu)組織所制定的硬性實(shí)施標(biāo)準(zhǔn)，而愉快地使用甚至傳播一些開(kāi)放標(biāo)準(zhǔn)，比如HTTP、ATOM和其他微格式的協(xié)議。

這里的關(guān)鍵區(qū)別是，這些標(biāo)準(zhǔn)是如何被制定以及如何被實(shí)施的。像諸如IETF這樣的組織所管理的各種標(biāo)準(zhǔn)，只有達(dá)到下述條件才能稱為標(biāo)準(zhǔn)，即該標(biāo)準(zhǔn)在全球更廣闊的地區(qū)有一些正在運(yùn)行的實(shí)現(xiàn)案例，而且這些標(biāo)準(zhǔn)經(jīng)常源自一些成功的開(kāi)源項(xiàng)目。

這些標(biāo)準(zhǔn)組成了一個(gè)世界，它區(qū)別于來(lái)自下述另一個(gè)世界的許多標(biāo)準(zhǔn)，即企業(yè)世界。企業(yè)世界中的標(biāo)準(zhǔn)，經(jīng)常由這樣特點(diǎn)的組織來(lái)開(kāi)發(fā)，即缺乏用較新技術(shù)進(jìn)行編程的經(jīng)驗(yàn)，或受到供應(yīng)商的過(guò)度影響。

如同在概念模型上進(jìn)行去中心化的決策一樣，微服務(wù)也在數(shù)據(jù)存儲(chǔ)上進(jìn)行去中心化的決策。盡管各個(gè)單塊應(yīng)用更愿意在邏輯上各自使用一個(gè)單獨(dú)的數(shù)據(jù)庫(kù)來(lái)持久化數(shù)據(jù)，但是各家企業(yè)往往喜歡一系列單塊應(yīng)用共用一個(gè)單獨(dú)的數(shù)據(jù)庫(kù)——許多這樣的決策是被供應(yīng)商的各種版權(quán)商業(yè)模式所驅(qū)動(dòng)出來(lái)的。微服務(wù)更喜歡讓每一個(gè)服務(wù)來(lái)管理其自有數(shù)據(jù)庫(kù)。其實(shí)現(xiàn)可以采用相同數(shù)據(jù)庫(kù)技術(shù)的不同數(shù)據(jù)庫(kù)實(shí)例，也可以采用完全不同的數(shù)據(jù)庫(kù)系統(tǒng)。這種方法被稱作“多語(yǔ)種持久化”(Polyglot Persistence)。在一個(gè)單塊系統(tǒng)中也能使用多語(yǔ)種持久化，但是看起來(lái)這種方法在微服務(wù)中出現(xiàn)得更加頻繁。

圖4：微服務(wù)更喜歡讓每一個(gè)服務(wù)來(lái)管理其自有數(shù)據(jù)庫(kù)

在各個(gè)微服務(wù)之間將數(shù)據(jù)的職責(zé)進(jìn)行“去中心化”的管理，會(huì)影響軟件更新的管理。處理軟件更新的常用方法，是當(dāng)更新多個(gè)資源的時(shí)候，使用事務(wù)來(lái)保證一致性。這種方法經(jīng)常在單塊系統(tǒng)中被采用。

像這樣使用事務(wù)，有助于保持?jǐn)?shù)據(jù)一致性。但是在時(shí)域上會(huì)引發(fā)明顯的耦合，這樣一來(lái)，在多個(gè)服務(wù)之間處理事務(wù)時(shí)會(huì)出現(xiàn)一致性問(wèn)題。分布式事務(wù)實(shí)現(xiàn)難度之大是不必多言的。為此，微服務(wù)架構(gòu)更強(qiáng)調(diào)在各個(gè)服務(wù)之間進(jìn)行“無(wú)事務(wù)”的協(xié)調(diào)。這源自微服務(wù)社區(qū)明確地認(rèn)識(shí)到下述兩點(diǎn)，即數(shù)據(jù)一致性可能只要求數(shù)據(jù)在最終達(dá)到一致，并且一致性問(wèn)題能夠通過(guò)補(bǔ)償操作來(lái)進(jìn)行處理。

對(duì)于許多開(kāi)發(fā)團(tuán)隊(duì)來(lái)說(shuō)，選擇這種方式來(lái)管理數(shù)據(jù)的“非一致性”，是一個(gè)新的挑戰(zhàn)。但這通常也符合在商業(yè)上的實(shí)踐做法。通常情況下，為了快速響應(yīng)需求，商家們都會(huì)處理一定程度上的數(shù)據(jù)“非一致性”，通過(guò)做某種反向過(guò)程來(lái)進(jìn)行錯(cuò)誤處理。只要修復(fù)錯(cuò)誤的成本低于“保持更大的數(shù)據(jù)一致性卻導(dǎo)致丟了生意所產(chǎn)生”的成本相比，那么進(jìn)行這種“非一致性”地?cái)?shù)據(jù)管理就是值得的。

特性七：“基礎(chǔ)設(shè)施”自動(dòng)化

基礎(chǔ)設(shè)施自動(dòng)化技術(shù)在過(guò)去幾年里已經(jīng)得到長(zhǎng)足的發(fā)展。云的演進(jìn)，特別是AWS的發(fā)展，已經(jīng)降低了構(gòu)建、部署和運(yùn)維微服務(wù)的操作復(fù)雜性。

許多使用微服務(wù)構(gòu)建的產(chǎn)品和系統(tǒng)，正在被這樣的團(tuán)隊(duì)所構(gòu)建，即他們都具備極其豐富的“持續(xù)交付”和其前身“持續(xù)集成”的經(jīng)驗(yàn)。用這種方法構(gòu)建軟件的各個(gè)團(tuán)隊(duì)，廣泛采用了基礎(chǔ)設(shè)施的自動(dòng)化技術(shù)。如下圖的構(gòu)建流水線所示：

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

由于本文并不是一篇有關(guān)持續(xù)交付的文章，所以下面僅提請(qǐng)大家注意兩個(gè)持續(xù)交付的關(guān)鍵特點(diǎn)。為了盡可能地獲得對(duì)正在運(yùn)行的軟件的信心，需要運(yùn)行大量的自動(dòng)化測(cè)試。讓可工作的軟件達(dá)到“晉級(jí)”(Promotion)狀態(tài)、從而“推上”流水線，就意味著可以在每一個(gè)新的環(huán)境中，對(duì)軟件進(jìn)行自動(dòng)化部署。

一個(gè)單塊應(yīng)用程序，能夠相當(dāng)愉快地在上述各個(gè)環(huán)境中，被構(gòu)建、測(cè)試和推送。其結(jié)果是，一旦在下述工作中進(jìn)行了投入，即針對(duì)一個(gè)單塊系統(tǒng)將其通往生產(chǎn)環(huán)境的通道進(jìn)行自動(dòng)化，那么部署更多的應(yīng)用系統(tǒng)似乎就不再可怕。記住，持續(xù)交付的目的之一，是讓“部署”工作變得“無(wú)聊”。所以不管是一個(gè)還是三個(gè)應(yīng)用系統(tǒng)，只要部署工作依舊很“無(wú)聊”，那么就沒(méi)什么可擔(dān)心的了。

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

那些因?qū)崿F(xiàn)持續(xù)交付和持續(xù)集成所增加的自動(dòng)化工作的副產(chǎn)品，是一些對(duì)開(kāi)發(fā)和運(yùn)維人員有用的工具?，F(xiàn)在，能完成下述工作的工具已經(jīng)相當(dāng)常見(jiàn)了，即創(chuàng)建工件(artefacts)、管理代碼庫(kù)、啟動(dòng)一些簡(jiǎn)單的服務(wù)、或增加標(biāo)準(zhǔn)的監(jiān)控和日志功能。Web上***的例子可能是Netflix提供的一套開(kāi)源工具集，但也有其他一些好工具，包括我們已經(jīng)廣泛使用的Dropwizard。

我們所看到的各個(gè)團(tuán)隊(duì)在廣泛使用基礎(chǔ)設(shè)施自動(dòng)化實(shí)踐的另一個(gè)領(lǐng)域，是在生產(chǎn)環(huán)境中管理各個(gè)微服務(wù)。與前面我們對(duì)比單塊系統(tǒng)和微服務(wù)所說(shuō)的正相反，只要部署工作很無(wú)聊，那么在這一點(diǎn)上單塊系統(tǒng)和微服務(wù)就沒(méi)什么區(qū)別。然而，兩者在運(yùn)維領(lǐng)域的情況卻截然不同。

圖6：兩者的模塊部署經(jīng)常會(huì)有差異

特性八：“容錯(cuò)”設(shè)計(jì)

使用各個(gè)微服務(wù)來(lái)替代組件，其結(jié)果是各個(gè)應(yīng)用程序需要被設(shè)計(jì)的能夠容忍這些服務(wù)所出現(xiàn)的故障。如果服務(wù)提供方不可用，那么任何對(duì)該服務(wù)的調(diào)用都會(huì)出現(xiàn)故障?？蛻舳艘M可能優(yōu)雅地應(yīng)對(duì)這種情況。與一個(gè)單塊設(shè)計(jì)相比，這是一個(gè)劣勢(shì)。因?yàn)樵谔幚磉@種情況時(shí)會(huì)引入額外的復(fù)雜性。為此，各個(gè)微服務(wù)團(tuán)隊(duì)在不斷地反思：這些服務(wù)故障是如何影響用戶體驗(yàn)的。Netflix公司所研發(fā)的開(kāi)源測(cè)試工具Simian Army，能夠誘導(dǎo)服務(wù)發(fā)生故障，甚至能誘導(dǎo)一個(gè)數(shù)據(jù)中心在工作日發(fā)生故障，來(lái)測(cè)試該應(yīng)用的彈性和監(jiān)控能力。

這種在生產(chǎn)環(huán)境中所進(jìn)行的自動(dòng)化測(cè)試，足以讓大多數(shù)運(yùn)維組織興奮得渾身顫栗，就像即將迎來(lái)一周的長(zhǎng)假那樣。這并不是說(shuō)單塊架構(gòu)風(fēng)格不能構(gòu)建先進(jìn)的監(jiān)控系統(tǒng)——只是根據(jù)我們的經(jīng)驗(yàn)，這在單塊系統(tǒng)中并不常見(jiàn)罷了。

(1) "斷路器"與“可隨時(shí)上線的代碼”

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

因?yàn)楦鱾€(gè)服務(wù)可以在任何時(shí)候發(fā)生故障，所以下面兩件事就變得很重要，即能夠快速地檢測(cè)出故障，而且在可能的情況下能夠自動(dòng)恢復(fù)服務(wù)。各個(gè)微服務(wù)的應(yīng)用都將大量的精力放到了應(yīng)用程序的實(shí)時(shí)監(jiān)控上，來(lái)檢查“架構(gòu)元素指標(biāo)”(例如數(shù)據(jù)庫(kù)每秒收到多少請(qǐng)求)和“業(yè)務(wù)相關(guān)指標(biāo)”(例如系統(tǒng)每分鐘收到多少訂單)。當(dāng)系統(tǒng)某個(gè)地方出現(xiàn)問(wèn)題，語(yǔ)義監(jiān)控系統(tǒng)能提供一個(gè)預(yù)警，來(lái)觸發(fā)開(kāi)發(fā)團(tuán)隊(duì)進(jìn)行后續(xù)的跟進(jìn)和調(diào)查工作。

這對(duì)于一個(gè)微服務(wù)架構(gòu)是尤其重要的，因?yàn)槲⒎?wù)對(duì)于服務(wù)編制(choreography)和事件協(xié)作的偏好，會(huì)導(dǎo)致“突發(fā)行為”。盡管許多權(quán)威人士對(duì)于偶發(fā)事件的價(jià)值持積極態(tài)度，但事實(shí)上，“突發(fā)行為”有時(shí)是一件壞事。在能夠快速發(fā)現(xiàn)有壞處的“突發(fā)行為”并進(jìn)行修復(fù)方面，監(jiān)控是至關(guān)重要的。

單塊系統(tǒng)也能構(gòu)建的像微服務(wù)一樣來(lái)實(shí)現(xiàn)透明的監(jiān)控系統(tǒng)——實(shí)際上，它們也應(yīng)該如此。差別是，絕對(duì)需要知道那些運(yùn)行在不同進(jìn)程中的服務(wù)，在何時(shí)斷掉了。而如果在同一個(gè)進(jìn)程內(nèi)使用軟件庫(kù)的話，這種透明的監(jiān)控系統(tǒng)就用處不大了。

(2) “同步調(diào)用”有害

一旦在一些服務(wù)之間進(jìn)行多個(gè)同步調(diào)用，就會(huì)遇到宕機(jī)的乘法效應(yīng)。簡(jiǎn)而言之，這意味著整個(gè)系統(tǒng)的宕機(jī)時(shí)間，是每一個(gè)單獨(dú)模塊各自宕機(jī)時(shí)間的乘積。此時(shí)面臨著一個(gè)選擇：是讓模塊之間調(diào)用異步，還是去管理宕機(jī)時(shí)間?在英國(guó)衛(wèi)報(bào)網(wǎng)站，他們?cè)谛缕脚_(tái)上實(shí)現(xiàn)了一個(gè)簡(jiǎn)單的規(guī)則——每一個(gè)用戶請(qǐng)求都對(duì)應(yīng)一個(gè)同步調(diào)用。然而在Netflix公司，他們重新設(shè)計(jì)的平臺(tái)API將異步性構(gòu)建到API的機(jī)制(fabric)中。

那些微服務(wù)團(tuán)隊(duì)希望在每一個(gè)單獨(dú)的服務(wù)中，都能看到先進(jìn)的監(jiān)控和日志記錄裝置。例如顯示“運(yùn)行/宕機(jī)”狀態(tài)的儀表盤(pán)，和各種運(yùn)維、業(yè)務(wù)相關(guān)的指標(biāo)。另外我們經(jīng)常在工作中會(huì)碰到這樣一些細(xì)節(jié)，即斷路器的狀態(tài)、當(dāng)前的吞吐率和延遲，以及其他一些例子。

特性九：“演進(jìn)式”設(shè)計(jì)

那些微服務(wù)的從業(yè)者們，通常具有演進(jìn)式設(shè)計(jì)的背景，而且通常將服務(wù)的分解，視作一個(gè)額外的工具，來(lái)讓?xiě)?yīng)用開(kāi)發(fā)人員能夠控制應(yīng)用系統(tǒng)中的變化，而無(wú)須減少變化的發(fā)生?？刂谱兓⒉灰欢ㄒ馕吨獪p少變化——在正確的態(tài)度和工具的幫助下，軟件中的變化也可以發(fā)生得頻繁、快速且得到良好的控制。

每當(dāng)要試圖將軟件系統(tǒng)分解為各個(gè)組件時(shí)，就會(huì)面臨這樣的決策，即如何進(jìn)行切分——我們決定切分應(yīng)用系統(tǒng)時(shí)應(yīng)該遵循的原則是什么?一個(gè)組件的關(guān)鍵屬性，是具有獨(dú)立更換和升級(jí)的特點(diǎn)——這意味著，需要尋找這些點(diǎn)，即想象著能否在其中一個(gè)點(diǎn)上重寫(xiě)該組件，而無(wú)須影響該組件的其他合作組件。事實(shí)上，許多做微服務(wù)的團(tuán)隊(duì)會(huì)更進(jìn)一步，他們明確地預(yù)期許多服務(wù)將來(lái)會(huì)報(bào)廢，而不是守著這些服務(wù)做長(zhǎng)期演進(jìn)。

英國(guó)衛(wèi)報(bào)網(wǎng)站是一個(gè)好例子。原先該網(wǎng)站是一個(gè)以單塊系統(tǒng)的方式來(lái)設(shè)計(jì)和構(gòu)建的應(yīng)用系統(tǒng)，然而它已經(jīng)開(kāi)始向微服務(wù)方向進(jìn)行演進(jìn)了。原先的單塊系統(tǒng)依舊是該網(wǎng)站的核心，但是在添加新特性時(shí)他們?cè)敢庖詷?gòu)建一些微服務(wù)的方式來(lái)進(jìn)行添加，而這些微服務(wù)會(huì)去調(diào)用原先那個(gè)單塊系統(tǒng)的API。當(dāng)開(kāi)發(fā)那些本身就帶有臨時(shí)性特點(diǎn)的新特性時(shí)，這種方法就特別方便，例如開(kāi)發(fā)報(bào)道一個(gè)體育賽事的專門(mén)頁(yè)面。當(dāng)使用一些快速的開(kāi)發(fā)語(yǔ)言時(shí)，這樣的網(wǎng)站頁(yè)面就能被快速地整合起來(lái)。而一旦賽事結(jié)束，這樣頁(yè)面就可以被刪除。在一個(gè)金融機(jī)構(gòu)中，我們已經(jīng)看到了一些相似的做法，即針對(duì)一個(gè)市場(chǎng)機(jī)會(huì)，一些新的服務(wù)可以被添加進(jìn)來(lái)。然后在幾個(gè)月甚至幾周之后，這些新服務(wù)就作廢了。

這種強(qiáng)調(diào)“可更換性”的特點(diǎn)，是模塊化設(shè)計(jì)一般性原則的一個(gè)特例，通過(guò)“變化模式”(pattern of change)來(lái)驅(qū)動(dòng)模塊化的實(shí)現(xiàn)。大家都愿意將那些能在同時(shí)發(fā)生變化的東西，放到同一個(gè)模塊中。系統(tǒng)中那些很少發(fā)生變化的部分，應(yīng)該被放到不同的服務(wù)中，以區(qū)別于那些正在經(jīng)歷大量變動(dòng)(churn)的部分。當(dāng)發(fā)現(xiàn)兩個(gè)服務(wù)需要被同時(shí)、反復(fù)變更，就意味著它們兩個(gè)需要被合并。

把一個(gè)個(gè)組件放入一個(gè)個(gè)服務(wù)中，提高了軟件發(fā)布精細(xì)化的程度。對(duì)于一個(gè)單塊系統(tǒng)，任何變化都需要做一次整個(gè)應(yīng)用系統(tǒng)的全量構(gòu)建和部署。然而，對(duì)于一個(gè)個(gè)微服務(wù)來(lái)說(shuō)，只需要重新部署修改過(guò)的那些服務(wù)就夠了。這能簡(jiǎn)化并加快發(fā)布過(guò)程。但缺點(diǎn)是：必須要考慮當(dāng)一個(gè)服務(wù)發(fā)生變化時(shí)，依賴它并對(duì)其進(jìn)行消費(fèi)的其他服務(wù)將無(wú)法工作。傳統(tǒng)的集成方法是使用版本化來(lái)解決這個(gè)問(wèn)題。但在微服務(wù)世界中，大家更喜歡將版本化作為***萬(wàn)不得已的手段來(lái)使用。我們可以通過(guò)下述方法來(lái)避免許多版本化的工作，即把各個(gè)服務(wù)設(shè)計(jì)得盡量能夠容錯(cuò)，來(lái)應(yīng)對(duì)其所依賴的服務(wù)所發(fā)生的變化。

二、未來(lái)的方向是“微服務(wù)”嗎?

我們寫(xiě)這篇文章的主要目的，是解釋有關(guān)微服務(wù)的主要思路和原則。在花了一點(diǎn)時(shí)間做了這件事后，我們清楚地認(rèn)識(shí)到，微服務(wù)架構(gòu)風(fēng)格是一個(gè)重要的理念——在研發(fā)企業(yè)應(yīng)用系統(tǒng)時(shí)，值得對(duì)它進(jìn)行認(rèn)真考慮。我們最近已經(jīng)使用這種風(fēng)格構(gòu)建了一些系統(tǒng)，并且了解到其他一些團(tuán)隊(duì)也贊同并正在使用這種方法。

我們所了解到的那些在某種程度上可以被稱作這種架構(gòu)風(fēng)格的實(shí)踐先驅(qū)包括：亞馬遜、Netflix、英國(guó)衛(wèi)報(bào)、英國(guó)政府?dāng)?shù)字化服務(wù)中心、realestate.com.au、Forward和comparethemarket.com。2013年的技術(shù)大會(huì)圈子充滿了各種各樣的、正在轉(zhuǎn)向可歸類為微服務(wù)的公司案例——包括Travis CI。另外還有大量的組織，它們長(zhǎng)期以來(lái)一直在做著我們認(rèn)為可以歸類為微服務(wù)的產(chǎn)品，卻從未使用過(guò)這個(gè)名字(這通常被標(biāo)記為SOA——盡管正如我們所說(shuō)，SOA會(huì)表現(xiàn)出各種自相矛盾的形式)。

盡管有這些正面的經(jīng)驗(yàn)，但這并不意味著我們確信微服務(wù)是軟件架構(gòu)未來(lái)的方向。盡管到目前為止，與單塊應(yīng)用系統(tǒng)相比，我們對(duì)于所經(jīng)歷過(guò)的微服務(wù)的評(píng)價(jià)是積極的，但是我們也意識(shí)到這樣的事實(shí)，即能供我們做出完整判斷的時(shí)間還不夠長(zhǎng)。

通常，架構(gòu)決策所產(chǎn)生的真正效果，只有在該決策做出若干年后才能真正顯現(xiàn)。我們已經(jīng)看到由帶著強(qiáng)烈的模塊化愿望的優(yōu)秀團(tuán)隊(duì)所做的一些項(xiàng)目，最終構(gòu)建出一個(gè)單塊架構(gòu)，并在幾年之內(nèi)不斷腐化。許多人認(rèn)為，如果使用微服務(wù)就不大可能出現(xiàn)這種腐化，因?yàn)榉?wù)的邊界是明確的，而且難以隨意搞亂。然而，對(duì)于那些開(kāi)發(fā)時(shí)間足夠長(zhǎng)的各種系統(tǒng)，除非我們已經(jīng)見(jiàn)識(shí)得足夠多，否則我們無(wú)法真正評(píng)價(jià)微服務(wù)架構(gòu)是如何成熟的。

我們的同事Sam Newman花了2014年的大部分時(shí)間撰寫(xiě)了一本書(shū)，來(lái)記述我們構(gòu)建微服務(wù)的經(jīng)驗(yàn)。如果想對(duì)這個(gè)話題進(jìn)行更深入的了解，下一步就應(yīng)該是閱讀這本書(shū)。

有人覺(jué)得微服務(wù)或許很難成熟起來(lái)，這當(dāng)然是有原因的。在組件化上所做的任何工作的成功度，取決于軟件與組件的匹配程度。準(zhǔn)確地搞清楚某個(gè)組件的邊界位置應(yīng)該出現(xiàn)在哪里，是一件困難的工作。演進(jìn)式設(shè)計(jì)承認(rèn)難以對(duì)邊界進(jìn)行正確定位，所以它將工作的重點(diǎn)放到了易于對(duì)邊界進(jìn)行重構(gòu)之上。但是當(dāng)各個(gè)組件成為各個(gè)進(jìn)行遠(yuǎn)程通信的服務(wù)后，比起在單一進(jìn)程內(nèi)調(diào)用各個(gè)軟件庫(kù)，此時(shí)的重構(gòu)就變得更加困難。跨越服務(wù)邊界的代碼移動(dòng)就變得困難起來(lái)。接口的任何變化，都需要在其各個(gè)參與者之間進(jìn)行協(xié)調(diào)。向后兼容的層次也需要被添加進(jìn)來(lái)。測(cè)試也會(huì)變得更加復(fù)雜。

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

***，還要考慮團(tuán)隊(duì)成員的技能水平。新技術(shù)往往會(huì)被技術(shù)更硬的團(tuán)隊(duì)所采用。對(duì)于技術(shù)更加過(guò)硬的團(tuán)隊(duì)而更有效的一項(xiàng)技術(shù)，不一定適用于技術(shù)略遜一籌的團(tuán)隊(duì)。我們已經(jīng)看到大量這樣的案例，那些技術(shù)略遜一籌的團(tuán)隊(duì)構(gòu)建出了雜亂的單塊架構(gòu)。當(dāng)這種雜亂發(fā)生到微服務(wù)身上時(shí)，會(huì)出現(xiàn)什么情況?這需要花時(shí)間來(lái)觀察。一個(gè)糟糕的團(tuán)隊(duì)，總會(huì)構(gòu)建一個(gè)糟糕的系統(tǒng)——在這種情況下，很難講微服務(wù)究竟是減少了雜亂，還是讓事情變得更糟。

我們聽(tīng)到一個(gè)合理的說(shuō)法：不要一上來(lái)就以微服務(wù)架構(gòu)做為起點(diǎn)。相反，要用一個(gè)單塊系統(tǒng)做為起點(diǎn)，并保持其模塊化。當(dāng)這個(gè)單塊系統(tǒng)出現(xiàn)了問(wèn)題后，再將其分解為微服務(wù)。(盡管這個(gè)建議并不理想，因?yàn)橐粋€(gè)良好的單一進(jìn)程內(nèi)的接口，通常不是一個(gè)良好的服務(wù)接口。)

因此，我們持謹(jǐn)慎樂(lè)觀的態(tài)度來(lái)撰寫(xiě)此文。到目前為止，我們已經(jīng)看到足夠多的有關(guān)微服務(wù)風(fēng)格的內(nèi)容，并且覺(jué)得這是一條值得去跋涉的道路。我們不能肯定地說(shuō)，道路的盡頭在哪里。但是，軟件開(kāi)發(fā)的挑戰(zhàn)之一，就是只能基于“目前手上擁有但還不夠完善”的信息來(lái)做出決策。

【本文是51CTO專欄作者“ThoughtWorks”的原創(chuàng)稿件，微信公眾號(hào)：思特沃克，轉(zhuǎn)載請(qǐng)聯(lián)系原作者】

戳這里，看該作者更多好文