微服務(wù)(Microservices)

1、精品好資料學(xué)習(xí)推薦微服務(wù)(Microservices) 說在前面 好久沒寫博文了，心里癢癢（也許是換工作后，有點(diǎn)時(shí)間了吧）。最近好像談?wù)撐⒎?wù)的人比較多，也開始學(xué)習(xí)一下，但是都有E文，看起來半懂不懂的。 Martinfowler的微服務(wù)，也算是入門必讀了。有人翻譯過，但是只有一半。還是自己練練手吧。微服務(wù) “微服務(wù)架構(gòu)”一詞在過去幾年里廣泛的傳播，它用于描述一種獨(dú)立部署的軟件應(yīng)用設(shè)計(jì)方式。這種架構(gòu)方式并沒有非常準(zhǔn)確的定義，但是在業(yè)務(wù)能力、自動(dòng)部署、端對(duì)端的整合、對(duì)語言及數(shù)據(jù)的分散控制上，卻有著顯著特征。 “微服務(wù)”-只不過在滿大街充斥的軟件架構(gòu)中的一新名詞而已。盡管我們非常鄙視這樣的東西，但是

2、這玩意所描述的軟件風(fēng)格，越來越引起我們的注意。在過去幾年里，我們發(fā)現(xiàn)越來越多的項(xiàng)目開始使用這種風(fēng)格，以至于我們身邊的同事在構(gòu)建企業(yè)應(yīng)用時(shí)，把它理所當(dāng)然的認(rèn)為這是一種默認(rèn)開發(fā)形式。然而，很不幸，微服務(wù)風(fēng)格是什么，應(yīng)該怎么開發(fā)，關(guān)于這樣的理論描述卻很難找到。 簡(jiǎn)而言之，微服務(wù)架構(gòu)風(fēng)格，就像是把小的服務(wù)開發(fā)成單一應(yīng)用的形式，每個(gè)應(yīng)用運(yùn)行在單一的進(jìn)程中，并使用如HTTP這樣子的輕量級(jí)的API。這些服務(wù)滿足某需求，并使用自動(dòng)化部署工具進(jìn)行獨(dú)立發(fā)布。這些服務(wù)可以使用不同的開發(fā)語言以及不同數(shù)據(jù)存儲(chǔ)技術(shù)，并保持最低限制的集中式管理。 開始介微服務(wù)風(fēng)格前，先介紹整體風(fēng)格：即把一個(gè)完整的應(yīng)用當(dāng)成一開發(fā)單元。企業(yè)應(yīng)

3、用通常包含三個(gè)部分：客戶端界面（由HTML、Javascript組成，使用瀏覽器進(jìn)行訪問）、數(shù)據(jù)庫（由許多的表組件構(gòu)成一個(gè)通用的、相互關(guān)聯(lián)的數(shù)據(jù)管理系統(tǒng)）、服務(wù)端應(yīng)用。服務(wù)端應(yīng)用處理HTTP請(qǐng)求、執(zhí)行領(lǐng)域邏輯、檢索并更新數(shù)據(jù)庫中的數(shù)據(jù)、使用適當(dāng)?shù)腍TML視圖發(fā)送給客戶端。服務(wù)端應(yīng)用是完整的 - 由單一的邏輯層次執(zhí)行。系統(tǒng)中任務(wù)變更都會(huì)導(dǎo)到服務(wù)端的應(yīng)用重新編輯并發(fā)布一個(gè)新的版本。 這樣的整體服務(wù)是這樣的構(gòu)建系統(tǒng)的很自然的方式。雖然利用開發(fā)語基礎(chǔ)特性會(huì)把應(yīng)用封裝成類、函數(shù)、命名空間，但是業(yè)務(wù)中所有邏輯都要在單一的進(jìn)程中處理完成。在某些場(chǎng)景中，開發(fā)者可能在的筆計(jì)本中開發(fā)、測(cè)試應(yīng)用，然后利用部署通道來

4、保證經(jīng)過正常測(cè)試、發(fā)布的修改內(nèi)容正確的發(fā)布的產(chǎn)品中。也可以使用橫向擴(kuò)展，通過負(fù)載均橫系統(tǒng)將事個(gè)應(yīng)用部署到多臺(tái)服務(wù)器上。 整體風(fēng)格的應(yīng)用也是相當(dāng)成功的，但是越來越多的人感覺到有點(diǎn)不妥，特別是在云中進(jìn)行應(yīng)用的發(fā)布時(shí)。變更發(fā)布周期被綁定了 - 原來可以劃分成小的應(yīng)用、小的需要的變更，需要統(tǒng)一的進(jìn)行編譯和發(fā)布。隨著時(shí)間的推移，人們通常難于維護(hù)一種優(yōu)美的模塊化的結(jié)構(gòu)，使得一個(gè)模塊的變更很難不會(huì)影響到其它的模塊。進(jìn)行擴(kuò)展，也需要進(jìn)行整體的擴(kuò)展，而不能根據(jù)進(jìn)行部分的擴(kuò)展。圖1：整理架構(gòu)與微服務(wù)架構(gòu) 這些原因?qū)е铝宋⒎?wù)架構(gòu)風(fēng)格的出現(xiàn)：以服務(wù)構(gòu)建應(yīng)用。因?yàn)榉?wù)可以獨(dú)立部署、獨(dú)立擴(kuò)展，服務(wù)也可以提供模塊化的邊界

5、，并且不同的使用也可以使用不同的開發(fā)語言。服還可以以不同的周期進(jìn)行管理。 微服務(wù)風(fēng)格關(guān)不是我們發(fā)明的，也不是一個(gè)新的東西，它至少起源于Unix時(shí)代的設(shè)計(jì)原則。之所以這樣，我們認(rèn)為只是當(dāng)時(shí)很少人考慮過這種風(fēng)格，并認(rèn)識(shí)到把軟件使用這種的風(fēng)格可以帶來更多的好處。微服務(wù)風(fēng)格的特性 我們沒有辦法對(duì)微服務(wù)風(fēng)格進(jìn)行準(zhǔn)確的定義，但是我們可以償試著描述一下微服務(wù)風(fēng)格所應(yīng)該具有的覺特性，這樣就可以對(duì)它打上相應(yīng)的標(biāo)簽了。正如其它定義中對(duì)特性的描述一新，并不是所有的微服務(wù)風(fēng)格都要所有的特性，但是我們認(rèn)為常見的微服務(wù)都應(yīng)該有這些特性。盡管我們是相當(dāng)松散的社區(qū)核心成員，但是我們也計(jì)劃償試描述我們工作中或者在其它我們了解的

6、組件中所理解的微服務(wù)。當(dāng)然，我們并不依賴于那些已經(jīng)明確過的定義。組件與服務(wù) 自從我們從事軟件行業(yè)以來，一直希望能夠構(gòu)建由組件組成的系統(tǒng)，就像我們所看到的實(shí)現(xiàn)世界由物件構(gòu)成的一樣。在過去的幾十年里，我們已經(jīng)看到了大部分語言平臺(tái)的公共庫的進(jìn)行了精簡(jiǎn)，并取得可觀的進(jìn)展。 當(dāng)我們談?wù)摻M件的時(shí)候，有可能會(huì)因?yàn)榻M件的不同定義引起混亂。因此我們申明，這里談到的組件是指軟件中獨(dú)立的單元，它能獨(dú)立替代和獨(dú)立更新。 微服務(wù)架構(gòu)也使用組件庫，但是它把軟件拆分成服務(wù)，并認(rèn)為這是主要的組織形式。我們把組件庫定義為程序中相互關(guān)系、并使用內(nèi)存中調(diào)用的組件，把服務(wù)定義為進(jìn)程間使用如Web請(qǐng)求服務(wù)或者遠(yuǎn)程調(diào)用來相互通信的組件。

7、（這種定義的方式與其它面向?qū)ο蟪绦蛑蟹?wù)對(duì)象的概念是不一樣的。） 把服務(wù)當(dāng)成組件（而不是組件庫）一個(gè)主要的原因是服務(wù)可以獨(dú)立的部署。如果你的應(yīng)用由多個(gè)組件庫組成并跑在一個(gè)進(jìn)程中，那么任何組件的變更都將導(dǎo)致整體應(yīng)用的重新發(fā)布。但是如果由許多服務(wù)構(gòu)成的應(yīng)用，你可以想像的到每個(gè)服務(wù)的變更僅需要發(fā)布相應(yīng)的服務(wù)。當(dāng)然，這也不是絕對(duì)的，比如導(dǎo)致服務(wù)接口的變更的更新就需要相應(yīng)服務(wù)的變化，但優(yōu)秀微服務(wù)構(gòu)架，會(huì)盡量避免這種服務(wù)間的耦合并完善服務(wù)的交互接口。 把服務(wù)當(dāng)成組件的另一個(gè)考慮是這將擁有更新清晰的接口。許多開發(fā)語言并沒有良好的定義公共接口的機(jī)制。通常只有文檔和規(guī)范說明，讓用戶避免組件間會(huì)導(dǎo)致組件耦合的過度

8、的依賴。不過服務(wù)由是是通過明確的遠(yuǎn)程接口調(diào)用，這個(gè)問題就很容易解決了。 使用服務(wù)也有它的不足之處。遠(yuǎn)程調(diào)用比進(jìn)制內(nèi)部調(diào)用更消耗性能，而且遠(yuǎn)程的API比較粗糙，難以使用。如果由于對(duì)組件的職責(zé)進(jìn)行變更，影響到跨進(jìn)程間的交互，那么這操作起來也比較困難。 第一個(gè)可能的特性，我們看到每個(gè)服務(wù)是運(yùn)行在獨(dú)立的進(jìn)程上的。注意，這只是第一個(gè)可能的特性。服務(wù)也可以由多個(gè)進(jìn)程組成，它們是同時(shí)開發(fā)和部署的，例如服務(wù)可能用到一個(gè)應(yīng)用進(jìn)制和一種數(shù)據(jù)稟。圍繞業(yè)務(wù)功能進(jìn)行組織 當(dāng)尋找把一個(gè)大的應(yīng)用拆分成小的部分時(shí)，主管通常注意在技術(shù)層面，拆分成UI組、服務(wù)邏輯組和數(shù)據(jù)庫組。當(dāng)使用這種標(biāo)準(zhǔn)對(duì)團(tuán)隊(duì)進(jìn)行劃分時(shí)，甚至小小的更變都將導(dǎo)

9、致跨團(tuán)隊(duì)間項(xiàng)目協(xié)作，從而消耗時(shí)間和預(yù)算審批。一個(gè)高效的團(tuán)隊(duì)會(huì)針對(duì)這種情況進(jìn)行改善，關(guān)注它們所涉及的應(yīng)用邏輯，并從中做出較好的選擇。換句話說，邏輯無處不在。Conways Law的實(shí)踐就是一個(gè)例子。 plain view plain copy 任何組織設(shè)計(jì)一個(gè)系統(tǒng)（廣義上的系統(tǒng)）都會(huì)產(chǎn)生一種設(shè)計(jì)，其結(jié)構(gòu)為其組織通信結(jié)構(gòu)的復(fù)本。 - Melvyn Conway, 1967 圖2：Conways Law的實(shí)踐 微服務(wù)更傾向于圍繞業(yè)務(wù)功能對(duì)服務(wù)結(jié)構(gòu)進(jìn)行劃分、拆解。這樣的服務(wù)，是針對(duì)業(yè)務(wù)領(lǐng)域有著關(guān)完整實(shí)現(xiàn)的軟件，它包含使用接口、持久存儲(chǔ)、以及對(duì)旬的交互。因此團(tuán)隊(duì)?wèi)?yīng)該是跨職能的，包含完整的開發(fā)技術(shù)：用戶體

10、驗(yàn)、數(shù)據(jù)庫、以及項(xiàng)目管理。圖3：通過團(tuán)隊(duì)邊界強(qiáng)調(diào)服務(wù)邊界 就采用這種組織形式。不同職能的團(tuán)隊(duì)同時(shí)為各自的產(chǎn)品構(gòu)建和運(yùn)營負(fù)責(zé)，同時(shí)每個(gè)產(chǎn)品又拆分成多個(gè)通過消息引擎通信的單獨(dú)服務(wù)。 大型的整體型應(yīng)用也可以按照業(yè)務(wù)功能進(jìn)行模塊化的，盡管這種例子不常見。當(dāng)然，我們敦促一個(gè)大型的團(tuán)隊(duì)將一個(gè)構(gòu)建成整體型的應(yīng)用依照業(yè)務(wù)功能進(jìn)行拆分。我們能看到主要問題在于，這種組件形式會(huì)導(dǎo)致很多的上下文依賴。如果在大量的模塊邊界上都存在這種大量的調(diào)用，對(duì)于團(tuán)隊(duì)的每個(gè)成員來說，短期內(nèi)是很難記住的。此外，我們發(fā)現(xiàn)模塊化方式需要大量的規(guī)范去強(qiáng)制執(zhí)行，當(dāng)然，大量明確的拆分也讓服務(wù)組件在

11、團(tuán)隊(duì)的邊界中更加清晰。產(chǎn)品不是項(xiàng)目 大部分的軟件開發(fā)者都使用這樣的開發(fā)模式：至力于提供一些被認(rèn)為是完整的軟件。一旦開發(fā)完成，軟件將移交給維護(hù)部門，然后，開發(fā)組就可以解散掉了。 微服務(wù)的支持者認(rèn)為，這種做法是不可取的，并提議開發(fā)組應(yīng)該負(fù)責(zé)產(chǎn)品的整個(gè)生命周期。一個(gè)常見的證明是：Amazon的“你編譯，你運(yùn)維（you build, you run it）”的理念，它要求開發(fā)團(tuán)隊(duì)對(duì)軟件產(chǎn)品的整個(gè)生命周期負(fù)責(zé)。這要求開發(fā)者每天都關(guān)注軟件產(chǎn)品的運(yùn)行情況，并與用戶聯(lián)系的更緊密，同時(shí)承擔(dān)一些售后支持。 成熟的產(chǎn)品會(huì)與業(yè)務(wù)功能進(jìn)行綁定。除了把軟件看成既定功能的集合外，會(huì)進(jìn)一步關(guān)心“軟件如何幫助用戶實(shí)現(xiàn)業(yè)務(wù)功能”

12、這樣的問題。 采用整體型的架構(gòu)并不是沒有原因的，但是越小的服務(wù)粒度越容易促進(jìn)用戶與服務(wù)提供商之前的關(guān)系。強(qiáng)化終端及弱化通道 當(dāng)構(gòu)建不同的進(jìn)程間通信機(jī)制的時(shí)候，我們發(fā)現(xiàn)有許多的產(chǎn)品和方法能夠把更加有效方法強(qiáng)加入的通信機(jī)制中。比如企業(yè)服務(wù)總線（ESB），這樣的產(chǎn)品提供更有效的方式改進(jìn)通信過程中的路由、編碼、傳輸、以及業(yè)務(wù)處理規(guī)則。 微服務(wù)傾向于做如下的選擇：強(qiáng)化終端及弱化通道。微服務(wù)的應(yīng)用致力松耦合和高內(nèi)聚：采用單獨(dú)的業(yè)務(wù)邏輯，表現(xiàn)的更像經(jīng)典Unix意義上的過濾器一樣，接受請(qǐng)求、處理業(yè)務(wù)邏輯、返回響應(yīng)。它們更喜歡簡(jiǎn)單的REST風(fēng)格，而不是復(fù)雜的協(xié)議，如WS或者BPEL或者集中式框架。 有兩種協(xié)議最

13、經(jīng)常被使用到：包含資源API的HTTP的請(qǐng)求-響應(yīng)和輕量級(jí)消息通信協(xié)議。最為重要的建議為：plain view plain copy Be of the web, not behind the web(善于利用網(wǎng)絡(luò)，而不是限制使用網(wǎng)絡(luò)。) - Ian Robinson 微服務(wù)團(tuán)隊(duì)采用這樣的原則和規(guī)范：基于互聯(lián)網(wǎng)（廣義上，包含Unix系統(tǒng)）構(gòu)建系統(tǒng)。這樣經(jīng)常使用的資源幾乎不用什么的代價(jià)就可以被開發(fā)者或者運(yùn)行商緩存。 第二種做法是通過輕量級(jí)消息總線來發(fā)布消息。這種的通信協(xié)議非常的單一（單一到只負(fù)責(zé)消息路由），像RabbitMQ或者ZeroMQ這樣的簡(jiǎn)單的實(shí)現(xiàn)甚至像可靠的異步機(jī)制都沒提供，以至于需要

14、依賴產(chǎn)生或者消費(fèi)消息的終端或者服務(wù)來處理這類問題。 在整體工風(fēng)格中，組件在進(jìn)程內(nèi)執(zhí)行，進(jìn)程間的消息通信通常通過調(diào)用方法或者回調(diào)函數(shù)。從整體式風(fēng)格到微服務(wù)框架最大的問題在于通信方式的變更。從內(nèi)存內(nèi)部原始的調(diào)用變成遠(yuǎn)程調(diào)用，產(chǎn)生的大量的不可靠通信。因此，你需要把粗粒度的方法成更加細(xì)粒度的通信。分散治理 集中治理的一種好處是在單一平臺(tái)上進(jìn)行標(biāo)準(zhǔn)化。經(jīng)驗(yàn)表明這種趨勢(shì)的好處在縮小，因?yàn)椴⒉皇撬械膯栴}都相同，而且解決方案并不是萬能的。我們更加傾向于采用適當(dāng)?shù)墓ぞ呓鉀Q適當(dāng)?shù)膯栴}，整體式的應(yīng)用在一定程度上比多語言環(huán)境更有優(yōu)勢(shì)，但也適合所有的情況。 把整體式框架中的組件，拆分成不同的服務(wù)，我們?cè)跇?gòu)建它們時(shí)有更

15、多的選擇。你想用Node.js去開發(fā)報(bào)表頁面嗎？做吧。用C+來構(gòu)建時(shí)時(shí)性要求高的組件？很好。你想以在不同類型的數(shù)據(jù)庫中切換，來提高組件的讀取性能？我們現(xiàn)在有技術(shù)手段來實(shí)現(xiàn)它了。 當(dāng)然，你是可以做更多的選擇，但也不意味的你就可以這樣做，因?yàn)槟愕南到y(tǒng)使用這種方式進(jìn)行侵害意味著你已經(jīng)有的決定。 采用微服務(wù)的團(tuán)隊(duì)更喜歡不同的標(biāo)準(zhǔn)。他們不會(huì)把這些標(biāo)準(zhǔn)寫在紙上，而是喜歡這樣的思想：開發(fā)有用的工具來解決開發(fā)者遇到的相似的問題。這些工具通常從實(shí)現(xiàn)中成長起來，并進(jìn)行的廣泛范圍內(nèi)分享，當(dāng)然，它們有時(shí)，并不一定，會(huì)采用開源模式。現(xiàn)在開源的做法也變得越來越普遍，git或者github成為了它們事實(shí)上的版本控制系統(tǒng)。

16、Netfix就是這樣的一個(gè)組織，它是非常好的一個(gè)例子。分享有用的、尤其是經(jīng)過實(shí)踐的代碼庫激勵(lì)著其它的開發(fā)著也使用相似的方式來解決相似的問題，當(dāng)然，也保留著根據(jù)需要使用不同的方法的權(quán)力。共享庫更關(guān)注于數(shù)據(jù)存儲(chǔ)、進(jìn)程內(nèi)通信以及我們接下來做討論到的自動(dòng)化等這些問題上。 微服務(wù)社區(qū)中，開銷問題特別引人注意。這并不是說，社區(qū)不認(rèn)為服務(wù)交互的價(jià)值。相反，正是因?yàn)榘l(fā)現(xiàn)到它的價(jià)值。這使得他們?cè)趯ふ腋鞣N方法來解決它們。如Tolearant Reader和Consumer-DrivenContracts這樣的設(shè)計(jì)模式就經(jīng)常被微服務(wù)使用。這些模式解決了獨(dú)立服務(wù)在交互過程中的消耗問題。使用Consumer-Drive

17、n Contracts增加了你的信心，并實(shí)現(xiàn)了快速的反饋機(jī)制。事實(shí)上，我們知道澳大利亞的一個(gè)團(tuán)隊(duì)致力使用Consumer-Drvien Contracts開發(fā)新的服務(wù)。他們使用簡(jiǎn)單的工程，幫助他們定義服務(wù)的接口。使得在新服務(wù)的代碼開始編寫之前，這些接口就成為自動(dòng)化構(gòu)建的一個(gè)部分。構(gòu)建出來的服務(wù)，只需要指出這些接口適用的范圍，一個(gè)優(yōu)雅的方法避免了新軟件中的YAGNI 困境。這些技術(shù)和工具在使用過程中完善，通過減少服務(wù)間的耦合，限制了集中式管理的需求。 也許分散治理普及于亞馬遜“編譯它，運(yùn)維它”的理念。團(tuán)隊(duì)為他們開發(fā)的軟件負(fù)全部責(zé)任，也包含7*24小時(shí)的運(yùn)行。全責(zé)任的方式并不常見，但是我們確實(shí)發(fā)現(xiàn)

18、越來越多的公司在他們的團(tuán)隊(duì)中所推廣。Netfix是另外一個(gè)接受這種理念的組件。每天凌晨3點(diǎn)被鬧鐘吵醒，因?yàn)槟惴浅５年P(guān)注寫的代碼質(zhì)量。這在傳統(tǒng)的集中式治理中這是一樣多么不思議的事情呀。分散數(shù)據(jù)管理 對(duì)數(shù)據(jù)的分散管理有多種不同的表現(xiàn)形式。最為抽象層次，它意味著不同系統(tǒng)中的通用概念是不同的。這帶來的覺問題是大型的跨系統(tǒng)整合時(shí)，用戶使用不同的售后支持將得到不同的促銷信息。這種情況叫做并沒有給用戶顯示所有的促銷手段。不同的語法確實(shí)存在相同的詞義或者（更差）相同的詞義。 應(yīng)用之間這個(gè)問題很普遍，但應(yīng)用內(nèi)部這個(gè)問題也存在，特別是當(dāng)應(yīng)用拆分成不同的組件時(shí)。對(duì)待這個(gè)問題非常有用的方式為Bounded Conte

19、xt的領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)。DDD把復(fù)雜的領(lǐng)域拆分成不同上下文邊界以及它們之間的關(guān)系。這樣的過程對(duì)于整體架構(gòu)和微服務(wù)框架都很有用，但是服務(wù)間存在著明顯的關(guān)系，幫助我們對(duì)上下文邊界進(jìn)行區(qū)分，同時(shí)也像我們?cè)跇I(yè)務(wù)功能中談到的，強(qiáng)行拆分。 當(dāng)對(duì)概念模式下決心進(jìn)行分散管理時(shí)，微服務(wù)也決定著分散數(shù)據(jù)管理。當(dāng)整體式的應(yīng)用使用單一邏輯數(shù)據(jù)庫對(duì)數(shù)據(jù)持久化時(shí)，企業(yè)通常選擇在應(yīng)用的范圍內(nèi)使用一個(gè)數(shù)據(jù)庫，這些決定也受廠商的商業(yè)權(quán)限模式驅(qū)動(dòng)。微服務(wù)讓每個(gè)服務(wù)管理自己的數(shù)據(jù)庫：無論是相同數(shù)據(jù)庫的不同實(shí)例，或者是不同的數(shù)據(jù)庫系統(tǒng)。這種方法叫PolyglotPersistence。你可以把這種方法用在整體架構(gòu)中，但是它更常見于微服務(wù)

20、架構(gòu)中。圖4：Polyglot Persistence 微服務(wù)音分散數(shù)據(jù)現(xiàn)任意味著管理數(shù)據(jù)更新。處理數(shù)據(jù)更新的常用方法是使用事務(wù)來保證不同的資源修改數(shù)據(jù)庫的一致性。這種方法通常在整體架構(gòu)中使用。 使用事務(wù)是因?yàn)樗軌驇椭幚硪恢列詥栴}，但對(duì)時(shí)間的消耗是嚴(yán)重的，這給跨服務(wù)操作帶來難題。分布式事務(wù)非常難以實(shí)施，因此微服務(wù)架構(gòu)強(qiáng)調(diào)服務(wù)間事務(wù)的協(xié)調(diào)，并清楚的認(rèn)識(shí)一致性只能是最終一致性以及通過補(bǔ)償運(yùn)算處理問題。 選擇處理不一致問題對(duì)于開發(fā)團(tuán)隊(duì)來說是新的挑戰(zhàn)，但是也是一個(gè)常見的業(yè)務(wù)實(shí)踐模式。通常業(yè)務(wù)上允許一定的不一致以滿足快速響應(yīng)的需求，但同時(shí)也采用一些恢復(fù)的進(jìn)程來處理這種錯(cuò)誤。當(dāng)業(yè)務(wù)上處理強(qiáng)一致性消耗比

21、處理錯(cuò)誤的消耗少時(shí)，這種付出是值的的。基礎(chǔ)設(shè)施自動(dòng)化 基礎(chǔ)設(shè)施自動(dòng)化技術(shù)在過去幾年中得到了長足的發(fā)展：云計(jì)算，特別是AWS的發(fā)展，減少了構(gòu)建、發(fā)布、運(yùn)維微服務(wù)的復(fù)雜性。 許多使用微服務(wù)架構(gòu)的產(chǎn)品或者系統(tǒng)，它們的團(tuán)隊(duì)擁有豐富的持集部署以及它的前任持續(xù)集成的經(jīng)驗(yàn)。團(tuán)隊(duì)使用這種方式構(gòu)建軟件致使更廣泛的依賴基礎(chǔ)設(shè)施自動(dòng)化技術(shù)。下圖說明這種構(gòu)建的流程：圖5：基本的構(gòu)建流程 盡管這不是介紹自動(dòng)部署的文章，但我們也打算介紹一下它的主要特征。我們希望我們的軟件應(yīng)該這樣方便的工作，因此我們需要更多的自動(dòng)化測(cè)試。流程中工作的軟件改進(jìn)意味著我們能自動(dòng)的部署到各種新的環(huán)境中。 整體風(fēng)格的應(yīng)用相當(dāng)開心的在各種環(huán)境中構(gòu)建

22、、測(cè)試、發(fā)布。事實(shí)證明，一旦你打算投資一條整體架構(gòu)應(yīng)用自動(dòng)化的的生產(chǎn)線，那么你會(huì)發(fā)現(xiàn)發(fā)布更多的應(yīng)用似乎非不那么的可怕。記住，CD（持續(xù)部署）的一個(gè)目標(biāo)在于讓發(fā)布變得無趣，因此無論是一個(gè)還是三個(gè)應(yīng)用，它都一樣的無趣。 另一個(gè)方面，我們發(fā)現(xiàn)使用微服務(wù)的團(tuán)隊(duì)更加依賴于基礎(chǔ)設(shè)施的自動(dòng)化。相比之下，在整體架構(gòu)也微服務(wù)架構(gòu)中，盡管發(fā)布的場(chǎng)景不同，但發(fā)布工作的無趣并沒有多大的區(qū)別。圖6：模塊化部署的區(qū)別容錯(cuò)性設(shè)計(jì) 使用服務(wù)作為組件的一個(gè)結(jié)果在于應(yīng)用需要有能容忍服務(wù)的故障的設(shè)計(jì)。任務(wù)服務(wù)可能因?yàn)楣?yīng)商的不可靠而故障，客戶端需要盡可能的優(yōu)化這種場(chǎng)景的響應(yīng)。跟整體構(gòu)架相比，這是一個(gè)缺點(diǎn)，因?yàn)樗鼛淼念~外的復(fù)雜性。

23、這將讓微服務(wù)團(tuán)隊(duì)時(shí)刻的想到服務(wù)故障的情況下用戶的體驗(yàn)。Netflix的Simian Army可以為每個(gè)應(yīng)用的服務(wù)及數(shù)據(jù)中心提供日常故障檢測(cè)和恢復(fù)。 這種產(chǎn)品中的自動(dòng)化測(cè)試可以讓大部分的運(yùn)維團(tuán)隊(duì)正常的上下班。這并不意味著整體構(gòu)架的應(yīng)用沒有這么精巧的監(jiān)控配置，只是在我們的經(jīng)驗(yàn)中它并不常見。 由于服務(wù)可以隨時(shí)故障，快速故障檢測(cè)，乃至，自動(dòng)恢復(fù)變更非常重要。微服務(wù)應(yīng)用把實(shí)時(shí)的監(jiān)控放在應(yīng)用的各個(gè)階段中，檢測(cè)構(gòu)架元素（每秒數(shù)據(jù)庫的接收的請(qǐng)求數(shù)）和業(yè)務(wù)相關(guān)的指標(biāo)（把分鐘接收的定單數(shù)）。監(jiān)控系統(tǒng)可以提供一種早期故障告警系統(tǒng)，讓開發(fā)團(tuán)隊(duì)跟進(jìn)并調(diào)查。 對(duì)于微服務(wù)框架來說，這相當(dāng)重要，因?yàn)槲⒎?wù)相互的通信可能導(dǎo)致緊

24、急意外行為。許多專家車稱贊這種緊急事件的價(jià)值，但事實(shí)是這種緊急行為有時(shí)是災(zāi)難。監(jiān)控是至關(guān)重要的，它能快速發(fā)現(xiàn)這種緊急不良行為，讓我們迅速修復(fù)它。 整體架構(gòu)，跟微服務(wù)一樣，在構(gòu)建時(shí)是通明的，實(shí)情上，它們就是這樣子的。它們不同之處在于，你需要清楚的認(rèn)識(shí)到不同進(jìn)程間運(yùn)行的服務(wù)是不相關(guān)的。庫對(duì)于同一進(jìn)程是透明的，也因此不那么重要了。 微服務(wù)團(tuán)隊(duì)期望清楚的監(jiān)控和記錄每個(gè)服務(wù)的配置，比如使用儀表盤顯示上/下線狀態(tài)、各種運(yùn)維和業(yè)務(wù)相關(guān)的指標(biāo)。對(duì)斷路器（circuit breaker）狀態(tài)、目前的吞吐量和時(shí)延細(xì)節(jié)，我們也會(huì)經(jīng)常遇到。設(shè)計(jì)改進(jìn) 微服務(wù)實(shí)踐者，通常有不斷改進(jìn)設(shè)計(jì)的背景，他們把服務(wù)分解成進(jìn)一步的工具

25、。這些工具可以讓應(yīng)用開發(fā)者在不改變速度情況下，控制都他們的應(yīng)用的需求變更。變更控制不意味首減少變更，而是使用適當(dāng)?shù)姆绞胶凸ぞ?，讓它更加頻繁，至少，很好讓它變得可控。 不論如何，當(dāng)你試圖軟件系統(tǒng)拆分成組件時(shí)，你將面臨著如何拆分的問題。那么我們的決定拆分我們應(yīng)用的原則是什么呢？首要的因素，組件可以被獨(dú)立替換和更新的，這意味著我們尋找的關(guān)鍵在于，我們要想象著重寫一個(gè)組件而不影響它們之前的協(xié)作關(guān)系。事實(shí)上，許多的微服務(wù)小組給它進(jìn)一步的預(yù)期：服務(wù)應(yīng)該能夠報(bào)廢的，而不是要長久的發(fā)展的。 Guardian網(wǎng)站就是這方面的一個(gè)優(yōu)秀的例子，它初期被設(shè)計(jì)和構(gòu)建成一個(gè)整體架構(gòu)，但它已經(jīng)向微服務(wù)的發(fā)展了。整體構(gòu)架仍然

26、是它網(wǎng)站的核心，但是他們使用微服務(wù)來增加那些使用整體架構(gòu)API的新特性。這種方法增加這些臨時(shí)的特性非常方便，比如運(yùn)動(dòng)新聞的特稿。這樣站點(diǎn)的一個(gè)部分可以使用快速的開發(fā)語言迅速整合起來，當(dāng)它過時(shí)后可以一次性移除。我們發(fā)現(xiàn)一家金融機(jī)構(gòu)用相似的方法增加新的市場(chǎng)營銷活動(dòng)，數(shù)周或者幾個(gè)月后把它撤銷。 可代替是模塊化開發(fā)中的一個(gè)特例，它是用模塊來應(yīng)對(duì)需要變更的。你希望讓變更是相同模塊，相同周期中進(jìn)行變化而已。系統(tǒng)的某些很小做變更部分，也應(yīng)該放在不同的服務(wù)中，這樣它們更容易讓它們消亡。如果你發(fā)現(xiàn)兩個(gè)服務(wù)一直重復(fù)的變更時(shí)，這就是一個(gè)要合并它們的信號(hào)了。 把組件改成服務(wù)，增加了細(xì)化發(fā)布計(jì)劃的一個(gè)機(jī)會(huì)。整體構(gòu)架的任

27、務(wù)變更需要整個(gè)應(yīng)用的完整的構(gòu)建和發(fā)布。然而，使用微服務(wù)，你只需要發(fā)布你要修改的服務(wù)就可以了。這將簡(jiǎn)化和加速你的發(fā)布周期。缺點(diǎn)是你需要為一個(gè)變更服務(wù)發(fā)布可能中斷用戶的體驗(yàn)而擔(dān)心。傳統(tǒng)的集成方法是使用版本來處理這些問題，但是微服務(wù)版本僅是最后的通告手段。我們需要在設(shè)計(jì)服務(wù)時(shí)盡可能的容忍供應(yīng)商的變更，以避免提供多個(gè)版本。其它微服務(wù)系統(tǒng)多大？ 盡管“微服務(wù)”一詞在架構(gòu)風(fēng)格中越來越流行，它的名字很不辛讓人關(guān)注它的服務(wù)大小，以及對(duì)“微”這個(gè)組成的爭(zhēng)議。在我們與微服務(wù)實(shí)踐者的談話中，我們發(fā)現(xiàn)了服務(wù)的大小范圍。被報(bào)道的最大團(tuán)隊(duì)遵循亞馬遜Tow Pizaa團(tuán)隊(duì)理念（比如，一個(gè)團(tuán)隊(duì)吃兩個(gè)比薩就可以了。），這意味著

28、不超過20號(hào)（一打）人。我們發(fā)現(xiàn)最小配置是半打的團(tuán)隊(duì)支撐起一打的服務(wù)。 這也引發(fā)這樣的考慮：規(guī)模為一個(gè)服務(wù)一打人到一個(gè)服務(wù)一個(gè)人的團(tuán)隊(duì)打上微服務(wù)的標(biāo)簽。此刻我們認(rèn)為，它們是一樣的，但是隨著對(duì)這種風(fēng)格的深入研究，也存在我們改變我們的想法的可能。微服務(wù)與SOA 當(dāng)前我們談到微服務(wù)時(shí)，通常會(huì)問，這是不是我們20年前討論的面向服務(wù)架構(gòu)（SOA）。這是一個(gè)很好的觀點(diǎn)，因?yàn)槲⒎?wù)風(fēng)格也SOA所提倡的一些優(yōu)勢(shì)非常相似。盡管如此，問題在于SOA意味的太多不同的東西了，因此通常時(shí)候我們談的所謂“SOA”時(shí)，它與我們談?wù)摰娘L(fēng)格不一至，因?yàn)樗ǔＪ侵冈谡w風(fēng)格應(yīng)用中的ESB。 此外，我們發(fā)現(xiàn)面向服務(wù)的風(fēng)格是這么的拙

29、劣：從試圖使用ESB隱藏復(fù)雜性， 到使用多年才認(rèn)識(shí)到發(fā)費(fèi)數(shù)百美元卻沒產(chǎn)生任務(wù)價(jià)值這樣的失敗，到集中治理模式抑制變更。而且這些問題往往很難發(fā)現(xiàn)。 可以肯定的時(shí)，微服務(wù)社區(qū)中使用的許多的技術(shù)都開發(fā)者是從大型機(jī)構(gòu)的整合服務(wù)經(jīng)驗(yàn)中發(fā)展來的。Tolerant Reader模式就是這樣的一個(gè)例子。由于互聯(lián)網(wǎng)的發(fā)展，利用簡(jiǎn)單的協(xié)議這種方法，讓它從這些經(jīng)驗(yàn)傳達(dá)的出來。這是從已經(jīng)很復(fù)雜的集中式標(biāo)準(zhǔn)中的一種反模式，坦白的說，真讓人驚嘆。（無論何時(shí)，當(dāng)你需要用一個(gè)服務(wù)來管理你的所有的服務(wù)，你就知道這很麻煩。） SOA的這種常見行為讓微服務(wù)的提倡者拒絕打上SOA的標(biāo)簽，盡管有人認(rèn)為微服務(wù)是從SOA中發(fā)展而來的，或許面

30、向服務(wù)是對(duì)的。無論如何，事實(shí)上SOA表達(dá)這么多的含義，它給一個(gè)團(tuán)隊(duì)清醒的認(rèn)識(shí)到這種構(gòu)架風(fēng)格就已經(jīng)值的了。多語言，多選擇 JVM做為一個(gè)平臺(tái)，它的增長就是一個(gè)平臺(tái)中運(yùn)行多語言的最大的例子。過去二十年中，它通常做為更高層次語言的殼，以達(dá)到更高層次的抽象。比如，研究它的內(nèi)部結(jié)構(gòu)，、使用低級(jí)的語言寫更高效的代碼。盡管如此，許多整體風(fēng)格并不需要這種層次的性能優(yōu)化或者在語法及高層次上的抽象，這很常見（讓我們很失望）。此外整體構(gòu)架通常意味著使用單一的語言，這也限制著使用技術(shù)的數(shù)量。實(shí)踐標(biāo)準(zhǔn)和強(qiáng)制標(biāo)準(zhǔn) 它有點(diǎn)尷尬，微服務(wù)團(tuán)隊(duì)傾向于避免這種通常由企業(yè)架構(gòu)隊(duì)伍定制的僵硬的強(qiáng)制標(biāo)準(zhǔn)，但是它們卻非常樂于甚至推廣這些開

31、放的標(biāo)準(zhǔn)，如HTTP、ATOM、其它微規(guī)范。 關(guān)鍵的不同在這些標(biāo)準(zhǔn)是怎么開發(fā)出來的，以及它們是怎么被推廣的。標(biāo)準(zhǔn)被一些組件管理，如IETF認(rèn)證標(biāo)準(zhǔn)，僅當(dāng)它們?cè)诨ヂ?lián)網(wǎng)上有幾個(gè)在用的實(shí)現(xiàn)，通常源自于開源工程的成功應(yīng)用。 這些標(biāo)準(zhǔn)單獨(dú)分離出來，與那種在企業(yè)中通常有沒有什么編碼經(jīng)驗(yàn)的或者沒有什么影響力的廠商標(biāo)準(zhǔn)進(jìn)行區(qū)別。讓做對(duì)事更容易 一方面，我們發(fā)現(xiàn)在持續(xù)發(fā)布、部署越來越多的使用自動(dòng)化，是很多有用的工具開發(fā)出來幫助開發(fā)者和運(yùn)營商的努力結(jié)果。為打包、代碼管理、支撐服務(wù)的工具，或者增加標(biāo)準(zhǔn)監(jiān)控的記錄的工具，現(xiàn)在都非常常見了。網(wǎng)絡(luò)中最好的，可能就是Netflixs的開源工具，但是包含Dropwizard在

32、內(nèi)的其它工具也被廣泛的使用著。斷路器(circuit breaker)和產(chǎn)品中現(xiàn)有的代碼斷路器(circuit breaker)出現(xiàn)在Realease It!一書中，與Bulkhead和Timeout這樣的模式放在一起。實(shí)施起來，這些模式用于構(gòu)建通信應(yīng)用時(shí)相當(dāng)?shù)闹匾etflix的博客在解釋它們的應(yīng)用時(shí)，做了大量的工作。同步是有害的 任務(wù)時(shí)候，你在服務(wù)間的調(diào)用使用同步的方法，都會(huì)遇到宕機(jī)時(shí)間的乘積效應(yīng)。簡(jiǎn)單的說，你的系統(tǒng)宕機(jī)時(shí)間是你系統(tǒng)的單獨(dú)組件的宕機(jī)時(shí)間的乘積。你面臨的選擇使用異步或者管理宕機(jī)時(shí)間。在www.guardian.co.uk中，它們?cè)谛缕脚_(tái)中使用一種簡(jiǎn)單的規(guī)則來實(shí)現(xiàn)它：在Netflix中每次用戶請(qǐng)求的同步調(diào)用，他們重新設(shè)計(jì)的平臺(tái)API都會(huì)把它構(gòu)建成異步的API來執(zhí)行。微服務(wù)是未來嗎？ 我們寫這篇文章的主要目的在于解釋微服務(wù)的主要思想和原則。但是發(fā)時(shí)間做這事的時(shí)候，我們清醒的認(rèn)識(shí)到微服務(wù)構(gòu)架風(fēng)格是一個(gè)非常重要的想法：一個(gè)值得企業(yè)應(yīng)用中認(rèn)真考慮的東西。我們最近使用這種風(fēng)格構(gòu)建了幾個(gè)系統(tǒng)，認(rèn)識(shí)那些也使用和喜歡這種方法的愛好者。 我們認(rèn)識(shí)的使用這種方式的先行者，包含亞馬遜、Netflix、The Guardian、The UK Government Digital Service、.a