微服務(wù)定義
過去幾年中出現(xiàn)了“微服務(wù)架構(gòu)”這一術(shù)語，它描述了將軟件應(yīng)用程序設(shè)計為可獨(dú)立部署的服務(wù)套件的特定方法种樱。雖然沒有對這種架構(gòu)風(fēng)格的精確定義，但圍繞業(yè)務(wù)能力俊卤，自動部署嫩挤，端點(diǎn)智能以及語言和數(shù)據(jù)的分散控制等組織存在某些共同特征。
“微服務(wù)” - 在擁擠的軟件架構(gòu)街道上又一個新名詞消恍。雖然我們的自然傾向是通過輕蔑的眼神來傳遞這些東西岂昭，但這一點(diǎn)術(shù)語描述了一種我們發(fā)現(xiàn)越來越有吸引力的軟件系統(tǒng)的風(fēng)格。我們已經(jīng)看到許多項目在過去幾年中使用了這種風(fēng)格狠怨，到目前為止的結(jié)果是積極的约啊，以至于對于我們的許多同事而言邑遏，這已經(jīng)成為構(gòu)建企業(yè)應(yīng)用程序的默認(rèn)風(fēng)格。然而恰矩，遺憾的是记盒，沒有太多信息可以概述微服務(wù)的風(fēng)格以及如何實現(xiàn)。
簡而言之外傅，微服務(wù)架構(gòu)風(fēng)格是一種將單個應(yīng)用程序開發(fā)為一套小型服務(wù)的方法孽鸡，每個小型服務(wù)都在自己的流程中運(yùn)行，并與輕量級機(jī)制（通常是HTTP資源API）進(jìn)行通信栏豺。這些服務(wù)圍繞業(yè)務(wù)功能構(gòu)建彬碱，可通過全自動部署機(jī)制獨(dú)立部署。對這些服務(wù)的集中管理幾乎是最低限度的奥洼，可以用不同的編程語言編寫巷疼，并使用不同的數(shù)據(jù)存儲技術(shù)。
為了開始解釋微服務(wù)風(fēng)格灵奖，將它與單片風(fēng)格進(jìn)行比較是有用的：作為單個單元構(gòu)建的單片應(yīng)用程序嚼沿。企業(yè)應(yīng)用程序通常由三個主要部分構(gòu)成：客戶端用戶界面（由用戶機(jī)器上的瀏覽器中運(yùn)行的HTML頁面和javascript組成）數(shù)據(jù)庫（由插入到公共數(shù)據(jù)庫管理中的許多表組成，通常是關(guān)系數(shù)據(jù)庫管理系統(tǒng)）和服務(wù)器端應(yīng)用程序瓷患。服務(wù)器端應(yīng)用程序?qū)⑻幚鞨TTP請求骡尽，執(zhí)行域邏輯，從數(shù)據(jù)庫檢索和更新數(shù)據(jù)擅编，以及選擇和填充要發(fā)送到瀏覽器的HTML視圖攀细。這個服務(wù)器端應(yīng)用程序是一個整體 - 一個邏輯可執(zhí)行文件。對系統(tǒng)的任何更改都涉及構(gòu)建和部署新版本的服務(wù)器端應(yīng)用程序爱态。
這種單片服務(wù)器是構(gòu)建這種系統(tǒng)的自然方式谭贪。處理請求的所有邏輯都在一個進(jìn)程中運(yùn)行，允許您使用語言的基本功能將應(yīng)用程序劃分為類锦担，函數(shù)和命名空間俭识。需要注意的是，您可以在開發(fā)人員的筆記本電腦上運(yùn)行和測試應(yīng)用程序洞渔，并使用部署管道確保對更改進(jìn)行適當(dāng)測試并將其部署到生產(chǎn)環(huán)境中套媚。您可以通過在負(fù)載均衡器后面運(yùn)行許多實例來水平擴(kuò)展整體。
單片應(yīng)用程序可以取得成功磁椒，但越來越多的人對它們感到沮喪 - 特別是隨著更多應(yīng)用程序被部署到云中堤瘤。變更周期聯(lián)系在一起 - 對應(yīng)用程序的一小部分進(jìn)行了更改，需要重建和部署整個整體衷快。隨著時間的推移宙橱，通常很難保持良好的模塊化結(jié)構(gòu)姨俩，使得更難以保持應(yīng)該只影響該模塊中的一個模塊的更改蘸拔。擴(kuò)展需要擴(kuò)展整個應(yīng)用程序师郑，而不是需要更多資源的部分。
這些挫折導(dǎo)致了微服務(wù)架構(gòu)風(fēng)格：將應(yīng)用程序構(gòu)建為服務(wù)套件调窍。除了服務(wù)可獨(dú)立部署和擴(kuò)展的事實之外宝冕，每個服務(wù)還提供了牢固的模塊邊界，甚至允許以不同的編程語言編寫不同的服務(wù)邓萨。他們也可以由不同的團(tuán)隊管理地梨。
我們并不認(rèn)為微服務(wù)風(fēng)格是新穎的或創(chuàng)新的，其根源至少可以歸結(jié)為Unix的設(shè)計原則缔恳。但我們認(rèn)為沒有足夠的人考慮微服務(wù)架構(gòu)宝剖，如果使用它們，許多軟件開發(fā)會更好歉甚。
微服務(wù)架構(gòu)的特征
我們不能說微服務(wù)架構(gòu)風(fēng)格有正式的定義万细，但我們可以嘗試描述我們認(rèn)為適合標(biāo)簽的架構(gòu)的共同特征。與概述共同特征的任何定義一樣纸泄，并非所有微服務(wù)架構(gòu)都具有所有特征赖钞，但我們確實期望大多數(shù)微服務(wù)架構(gòu)具有大多數(shù)特征。雖然我們的作者一直是這個相當(dāng)寬松的社區(qū)的積極成員聘裁，但我們的目的是嘗試描述我們在自己的工作中所看到的以及我們所知道的團(tuán)隊的類似努力雪营。特別是我們沒有規(guī)定一些符合的定義。
通過服務(wù)進(jìn)行組件化
只要我們參與軟件行業(yè)衡便，就一直希望通過將組件集成在一起來構(gòu)建系統(tǒng)献起，就像我們在物理世界中看到事物的方式一樣。在過去的幾十年中镣陕，我們已經(jīng)看到了大多數(shù)語言平臺的大型公共庫的大量進(jìn)展征唬。
在談?wù)摻M件時，我們遇到了組件構(gòu)成的困難定義茁彭。我們的定義是 組件是一個可獨(dú)立更換和升級的軟件單元总寒。
微服務(wù)架構(gòu)將使用庫，但是他們將自己的軟件組件化的主要方式是分解為服務(wù)理肺。我們將庫定義 為鏈接到程序中并使用內(nèi)存中函數(shù)調(diào)用調(diào)用的組件摄闸，而服務(wù)是與Web服務(wù)請求或遠(yuǎn)程過程調(diào)用等機(jī)制進(jìn)行通信的進(jìn)程外組件。（這與許多面向?qū)ο蟪绦蛑械姆?wù)對象的概念不同妹萨。）
將服務(wù)用作組件（而不是庫）的一個主要原因是服務(wù)可以獨(dú)立部署年枕。如果您在單個進(jìn)程中有一個由多個庫組成的應(yīng)用程序，則對任何單個組件的更改都會導(dǎo)致必須重新部署整個應(yīng)用程序乎完。但是熏兄，如果將該應(yīng)用程序分解為多個服務(wù)，則可以預(yù)期許多單個服務(wù)更改僅需要重新部署該服務(wù)。這不是絕對的摩桶，一些變化將改變服務(wù)接口桥状，從而產(chǎn)生一些協(xié)調(diào)，但良好的微服務(wù)架構(gòu)的目標(biāo)是通過服務(wù)合同中的緊密服務(wù)邊界和演化機(jī)制來最小化這些硝清。
將服務(wù)用作組件的另一個結(jié)果是更明確的組件接口辅斟。大多數(shù)語言沒有很好的機(jī)制來定義顯式的已發(fā)布接口。通常芦拿，它只是文檔和規(guī)程士飒，可以防止客戶端破壞組件的封裝，從而導(dǎo)致組件之間過于緊密的耦合蔗崎。通過使用顯式遠(yuǎn)程調(diào)用機(jī)制酵幕，服務(wù)可以更容易地避免這種情況。
使用這樣的服務(wù)確實有缺點(diǎn)缓苛。遠(yuǎn)程調(diào)用比進(jìn)程內(nèi)調(diào)用更昂貴裙盾，因此遠(yuǎn)程API需要更粗糙，這通常更難以使用他嫡。如果您需要更改組件之間的職責(zé)分配番官，那么當(dāng)您跨越流程邊界時，這種行為的變化就更難钢属。
在第一次近似中徘熔，我們可以觀察到服務(wù)映射到運(yùn)行時進(jìn)程，但這只是第一次近似淆党。服務(wù)可能包含多個始終一起開發(fā)和部署的進(jìn)程酷师，例如應(yīng)用程序進(jìn)程和僅由該服務(wù)使用的數(shù)據(jù)庫。
圍繞業(yè)務(wù)能力進(jìn)行組織
在將大型應(yīng)用程序拆分為多個部分時染乌，通常管理側(cè)重于技術(shù)層山孔，從而導(dǎo)致UI團(tuán)隊，服務(wù)器端邏輯團(tuán)隊和數(shù)據(jù)庫團(tuán)隊荷憋。當(dāng)團(tuán)隊按照這些方式分開時台颠，即使是簡單的更改也可能導(dǎo)致跨團(tuán)隊項目需要時間和預(yù)算批準(zhǔn)。一個聰明的團(tuán)隊將圍繞這個進(jìn)行優(yōu)化勒庄，并為兩個惡魔中的較小者提供豐富的優(yōu)勢 - 只需將邏輯強(qiáng)制轉(zhuǎn)換為他們可以訪問的任何應(yīng)用程序串前。換句話說，邏輯無處不在实蔽。這是康威定律的一個例子荡碾。
設(shè)計系統(tǒng)（廣泛定義）的任何組織都將生成一種設(shè)計，其結(jié)構(gòu)是組織通信結(jié)構(gòu)的副本局装。
微服務(wù)劃分方法是不同的坛吁，分為圍繞業(yè)務(wù)能力組織的服務(wù) 劳殖。此類服務(wù)為該業(yè)務(wù)領(lǐng)域采用廣泛的軟件實現(xiàn)，包括用戶界面拨脉，持久存儲和任何外部協(xié)作哆姻。因此，團(tuán)隊是跨職能的女坑，包括開發(fā)所需的全部技能：用戶體驗填具，數(shù)據(jù)庫和項目管理统舀。
以這種方式組建的一家公司是www.comparethemarket.com匆骗。跨職能團(tuán)隊負(fù)責(zé)構(gòu)建和運(yùn)營每個產(chǎn)品誉简，每個產(chǎn)品分為多個通過消息總線進(jìn)行通信的單獨(dú)服務(wù)碉就。
大型單片應(yīng)用程序也可以圍繞業(yè)務(wù)功能進(jìn)行模塊化，盡管這不是常見的情況闷串。當(dāng)然瓮钥，我們會敦促一個龐大的團(tuán)隊構(gòu)建一個單一的應(yīng)用程序，以便在業(yè)務(wù)線上劃分自己烹吵。我們在這里看到的主要問題是碉熄，它們往往圍繞太多的背景進(jìn)行組織。如果整體跨越許多這些模塊化邊界肋拔，團(tuán)隊中的個體成員可能難以將它們放入短期記憶中锈津。此外，我們看到模塊化生產(chǎn)線需要大量的紀(jì)律來執(zhí)行凉蜂。服務(wù)組件所需的更明確的分離使得更容易保持團(tuán)隊邊界清晰琼梆。
微服務(wù)有多大？
雖然“微服務(wù)”已經(jīng)成為這種架構(gòu)風(fēng)格的流行名稱窿吩，但它的名稱確實導(dǎo)致了對服務(wù)規(guī)模的不幸關(guān)注以及關(guān)于什么構(gòu)成“微觀”的爭論茎杂。在我們與微服務(wù)從業(yè)者的對話中，我們看到了一系列服務(wù)規(guī)模纫雁。報道的最大尺寸遵循亞馬遜的Two Pizza Team的概念（即整個團(tuán)隊可以由兩個比薩餅喂養(yǎng)）煌往，意味著不超過十幾個人。在規(guī)模較小的規(guī)模上轧邪，我們已經(jīng)看到了一個由六人組成的團(tuán)隊支持六項服務(wù)的設(shè)置携冤。這導(dǎo)致了這樣的問題：在這個尺寸范圍內(nèi)是否存在足夠大的差異，即每個人的服務(wù)和每人服務(wù)的尺寸不應(yīng)該集中在一個微服務(wù)標(biāo)簽下闲勺。目前我們認(rèn)為將它們組合在一起會更好曾棕，但當(dāng)我們進(jìn)一步探索這種風(fēng)格時，我們肯定會改變主意菜循。
產(chǎn)品不是項目
我們看到的大多數(shù)應(yīng)用程序開發(fā)工作都使用項目模型：其目的是提供一些軟件然后被認(rèn)為是完成的翘地。完成后，軟件將移交給維護(hù)組織型型，構(gòu)建它的項目團(tuán)隊將被解散兆蕉。
微服務(wù)支持者傾向于避免這種模式，而是傾向于認(rèn)為團(tuán)隊?wèi)?yīng)該在其整個生命周期內(nèi)擁有產(chǎn)品署尤。對此的一個共同啟示是亞馬遜的概念“你構(gòu)建橙喘，運(yùn)行它”时鸵，開發(fā)團(tuán)隊對生產(chǎn)中的軟件負(fù)全部責(zé)任。這使開發(fā)人員能夠日常接觸他們的軟件在生產(chǎn)中的行為厅瞎，并增加與用戶的聯(lián)系饰潜，因為他們必須承擔(dān)至少一些支持負(fù)擔(dān)。
產(chǎn)品心態(tài)和簸，與業(yè)務(wù)能力的聯(lián)系緊密相連彭雾。不是將軟件視為一組要完成的功能，而是存在一種持續(xù)的關(guān)系锁保，其中的問題是軟件如何幫助其用戶增強(qiáng)業(yè)務(wù)能力薯酝。
沒有理由為什么這種方法不能與單一應(yīng)用程序一起使用，但較小的服務(wù)粒度可以使創(chuàng)建服務(wù)開發(fā)人員與其用戶之間的個人關(guān)系變得更加容易爽柒。
智能端點(diǎn)和啞管
在不同流程之間建立溝通結(jié)構(gòu)時吴菠，我們已經(jīng)看到許多產(chǎn)品和方法都強(qiáng)調(diào)將重要的智慧放入溝通機(jī)制本身。一個很好的例子是企業(yè)服務(wù)總線（ESB）浩村，其中ESB產(chǎn)品通常包括用于消息路由做葵，編排，轉(zhuǎn)換和應(yīng)用業(yè)務(wù)規(guī)則的復(fù)雜工具穴亏。
微服務(wù)社區(qū)傾向于采用另一種方法： 智能端點(diǎn)和啞管蜂挪。從微服務(wù)構(gòu)建的應(yīng)用程序旨在盡可能地分離和凝聚 - 它們擁有自己的域邏輯，并且在經(jīng)典的Unix意義上更多地充當(dāng)過濾器 - 接收請求嗓化，適當(dāng)?shù)貞?yīng)用邏輯并產(chǎn)生響應(yīng)棠涮。這些是使用簡單的RESTish協(xié)議而不是復(fù)雜的協(xié)議（如WS-Choreography或BPEL或中央工具的編排）編排的。
最常用的兩種協(xié)議是HTTP請求 - 響應(yīng)資源API和輕量級消息傳遞刺覆。第一個最好的表達(dá)方式是做網(wǎng)絡(luò)的主人严肪，而不是網(wǎng)絡(luò)背后的主人。
微服務(wù)團(tuán)隊使用萬維網(wǎng)（在很大程度上谦屑，Unix）構(gòu)建的原則和協(xié)議驳糯。經(jīng)常使用的資源可以通過開發(fā)人員或操作人員的非常小的努力來緩存。
常用的第二種方法是通過輕量級消息總線進(jìn)行消息傳遞氢橙。選擇的基礎(chǔ)設(shè)施通常是愚蠢的（如同僅作為消息路由器那樣愚蠢） - 像RabbitMQ或ZeroMQ這樣的簡單實現(xiàn)不僅僅提供可靠的異步結(jié)構(gòu) - 智能仍然存在于生成和消費(fèi)消息; 在服務(wù)中酝枢。
在整體中，組件在進(jìn)程中執(zhí)行悍手，它們之間的通信是通過方法調(diào)用或函數(shù)調(diào)用帘睦。將整體變?yōu)槲⒎?wù)的最大問題在于改變通信模式袍患。從內(nèi)存中方法調(diào)用到RPC的簡單轉(zhuǎn)換導(dǎo)致繁瑣的通信，這些通信效果不佳竣付。相反诡延，您需要用粗粒度的方法替換細(xì)粒度的通信。
去中心化治理
集中治理的后果之一是在單一技術(shù)平臺上實現(xiàn)標(biāo)準(zhǔn)化的趨勢古胆。經(jīng)驗表明肆良，這種方法是有限的 - 不是每個問題都是釘子，而不是每個解決方案都是錘子逸绎。我們更喜歡使用正確的工具來完成工作惹恃，而單片應(yīng)用程序可以在一定程度上利用不同的語言，但這并不常見桶良。
將monolith的組件拆分為服務(wù)座舍，我們可以在構(gòu)建每個組件時做出選擇沮翔。您想使用Node.js站起來一個簡單的報告頁面嗎陨帆？去吧。C ++是否適用于特別近乎實時的組件采蚀？精細(xì)疲牵。您想交換不同風(fēng)格的數(shù)據(jù)庫，以更好地適應(yīng)一個組件的讀取行為榆鼠？我們有重建他的技術(shù)纲爸。
當(dāng)然，僅僅因為你可以做某事妆够，并不意味著你應(yīng)該 - 但以這種方式對系統(tǒng)進(jìn)行分區(qū)意味著你可以選擇识啦。
構(gòu)建微服務(wù)的團(tuán)隊也更喜歡采用不同的標(biāo)準(zhǔn)方法。他們不是使用在紙上某處寫下的一組定義標(biāo)準(zhǔn)神妹，而是更愿意生成有用的工具颓哮，其他開發(fā)人員可以使用它來解決與他們面臨的類似問題。這些工具通常從實現(xiàn)中收集并與更廣泛的組共享鸵荠，有時冕茅，但不僅僅是使用內(nèi)部開源模型。現(xiàn)在git和github已成為事實上的版本控制系統(tǒng)蛹找，開源實踐在內(nèi)部變得越來越普遍姨伤。
Netflix是遵循這一理念的組織的一個很好的例子。共享有用的庸疾，最重要的是經(jīng)過實戰(zhàn)考驗的代碼乍楚，因為庫鼓勵其他開發(fā)人員以類似的方式解決類似問題，但如果需要届慈，可以選擇不同的方法徒溪。共享庫往往側(cè)重于數(shù)據(jù)存儲凌箕，進(jìn)程間通信的常見問題，我們將在下面進(jìn)一步討論基礎(chǔ)架構(gòu)自動化词渤。
對于微服務(wù)社區(qū)來說牵舱，管理費(fèi)用特別缺乏吸引力。這并不是說社區(qū)不重視服務(wù)合同缺虐。恰恰相反芜壁，因為往往會有更多。只是他們正在尋找管理這些合同的不同方式高氮。模式慧妄，如 容錯讀者和消費(fèi)者驅(qū)動的契約通常應(yīng)用于微服務(wù)。這些援助服務(wù)合同獨(dú)立發(fā)展剪芍。在構(gòu)建過程中執(zhí)行消費(fèi)者驅(qū)動的合同可以增強(qiáng)信心塞淹，并提供有關(guān)您的服務(wù)是否正常運(yùn)行的快速反饋。事實上罪裹，我們知道澳大利亞的一個團(tuán)隊通過消費(fèi)者驅(qū)動的合同推動新服務(wù)的建設(shè)饱普。他們使用簡單的工具來定義服務(wù)合同。在編寫新服務(wù)的代碼之前状共，這將成為自動構(gòu)建的一部分套耕。然后，服務(wù)建立在滿足合同的地步 - 避免'YAGNI'的優(yōu)雅方法構(gòu)建新軟件時的兩難選擇峡继。這些技術(shù)和圍繞它們成長的工具通過減少服務(wù)之間的時間耦合來限制中央合同管理的需要冯袍。
也許分散治理的最高點(diǎn)是建立它/運(yùn)行它由亞馬遜推廣的精神。團(tuán)隊負(fù)責(zé)他們構(gòu)建的軟件的所有方面碾牌，包括全天候運(yùn)行軟件康愤。這種責(zé)任水平的下放絕對不是常態(tài)，但我們確實看到越來越多的公司將責(zé)任推向開發(fā)團(tuán)隊舶吗。Netflix是另一個采用這種精神的組織征冷。每天晚上凌晨3點(diǎn)被您的尋呼機(jī)喚醒，無疑是在編寫代碼時專注于質(zhì)量的強(qiáng)大動力裤翩。這些想法與傳統(tǒng)的集中治理模式相差甚遠(yuǎn)资盅。
去中心化管理
數(shù)據(jù)管理的分散化以多種不同的方式呈現(xiàn)。在最抽象的層面上踊赠，它意味著世界的概念模型在不同系統(tǒng)之間會有所不同呵扛。在整合大型企業(yè)時，這是一個常見問題筐带，客戶的銷售視圖將與支持視圖不同今穿。在銷售視圖中稱為客戶的某些內(nèi)容可能根本不會出現(xiàn)在支持視圖中。那些做的可能具有不同的屬性和（更糟糕的）具有微妙不同語義的共同屬性伦籍。
此問題在應(yīng)用程序之間很常見蓝晒，但也可能在應(yīng)用程序中發(fā)生腮出，特別是在將應(yīng)用程序劃分為單獨(dú)的組件時。一種有用的思考方式是有界上下文的領(lǐng)域驅(qū)動設(shè)計概念 芝薇。DDD將復(fù)雜域劃分為多個有界上下文胚嘲，并映射出它們之間的關(guān)系。此過程對單片和微服務(wù)體系結(jié)構(gòu)都很有用洛二，但服務(wù)和上下文邊界之間存在自然關(guān)聯(lián)馋劈，這有助于澄清，正如我們在業(yè)務(wù)功能部分中所述晾嘶，強(qiáng)化了分離妓雾。
除了關(guān)于概念模型的分散決策之外，微服務(wù)還分散了數(shù)據(jù)存儲決策垒迂。雖然單一應(yīng)用程序更喜歡使用單個邏輯數(shù)據(jù)庫來存儲持久性數(shù)據(jù)械姻，但企業(yè)通常更喜歡在一系列應(yīng)用程序中使用單個數(shù)據(jù)庫 - 其中許多決策是通過供應(yīng)商圍繞許可的商業(yè)模型來實現(xiàn)的。微服務(wù)更喜歡讓每個服務(wù)管理自己的數(shù)據(jù)庫机断，可以是同一數(shù)據(jù)庫技術(shù)的不同實例楷拳，也可以是完全不同的數(shù)據(jù)庫系統(tǒng) - 這種方法稱為Polyglot Persistence。您可以在整體中使用多語言持久性毫缆，但它在微服務(wù)中更常出現(xiàn)唯竹。
跨微服務(wù)分散數(shù)據(jù)責(zé)任對管理更新有影響乐导。處理更新的常用方法是在更新多個資源時使用事務(wù)來保證一致性苦丁。這種方法通常用于整體結(jié)構(gòu)中。
使用這樣的事務(wù)有助于保持一致性物臂，但會產(chǎn)生顯著的時間耦合旺拉，這在多個服務(wù)中是有問題的。眾所周知棵磷，分布式事務(wù)很難實現(xiàn)蛾狗，因此微服務(wù)架構(gòu)強(qiáng)調(diào)服務(wù)之間的無事務(wù)協(xié)調(diào)，并明確認(rèn)識到一致性可能只是最終的一致性仪媒，而問題通過補(bǔ)償操作來處理沉桌。
選擇以這種方式管理不一致是許多開發(fā)團(tuán)隊面臨的新挑戰(zhàn)，但它通常與業(yè)務(wù)實踐相匹配算吩。企業(yè)通常會處理一定程度的不一致留凭，以便快速響應(yīng)需求，同時采取某種逆轉(zhuǎn)流程來應(yīng)對錯誤偎巢。只要修復(fù)錯誤的成本低于在更大的一致性下丟失業(yè)務(wù)的成本蔼夜，那么權(quán)衡是值得的。
基建自動化
基礎(chǔ)設(shè)施自動化技術(shù)在過去幾年中發(fā)生了巨大變化 - 特別是云和AWS的發(fā)展降低了構(gòu)建压昼，部署和運(yùn)行微服務(wù)的操作復(fù)雜性求冷。
許多使用微服務(wù)構(gòu)建的產(chǎn)品或系統(tǒng)都是由具有豐富的持續(xù)交付經(jīng)驗的團(tuán)隊構(gòu)建的瘤运，并且是前身的持續(xù)集成。以這種方式構(gòu)建軟件的團(tuán)隊廣泛使用基礎(chǔ)設(shè)施自動化技術(shù)匠题。這在下面顯示的構(gòu)建管道中說明拯坟。
由于這不是關(guān)于持續(xù)交付的文章，我們將在這里引起注意幾個關(guān)鍵功能韭山。我們希望盡可能多的信心使我們的軟件正常工作似谁，因此我們進(jìn)行了大量的自動化測試。推廣工作軟件“向上”管道意味著我們自動部署 到每個新環(huán)境掠哥。
一個單一的應(yīng)用程序?qū)⒎浅Ｓ淇斓貥?gòu)建巩踏，測試和推動通過這些環(huán)境。事實證明续搀，一旦你投資自動化整體生產(chǎn)的生產(chǎn)之路塞琼，那么部署更多的應(yīng)用程序似乎不再那么可怕了。請記住禁舷，CD的目標(biāo)之一就是使部署無聊彪杉，所以無論是一個還是三個應(yīng)用程序，只要它仍然無聊就無所謂牵咙。
我們看到團(tuán)隊使用廣泛的基礎(chǔ)設(shè)施自動化的另一個領(lǐng)域是管理生產(chǎn)中的微服務(wù)派近。與我們上面的斷言相反，只要部署很無聊洁桌，單塊和微服務(wù)之間沒有太大的區(qū)別渴丸，每個部署的運(yùn)營環(huán)境可能會截然不同。
設(shè)計失敗
使用服務(wù)作為組件的結(jié)果是另凌，需要設(shè)計應(yīng)用程序以便它們能夠容忍服務(wù)的失敗谱轨。由于供應(yīng)商不可用，任何服務(wù)呼叫都可能失敗吠谢，客戶必須盡可能優(yōu)雅地對此做出響應(yīng)土童。與單片設(shè)計相比，這是一個缺點(diǎn)工坊，因為它引入了額外的復(fù)雜性來處理它献汗。結(jié)果是微服務(wù)團(tuán)隊不斷反思服務(wù)失敗如何影響用戶體驗。Netflix的Simian Army 在工作日引發(fā)服務(wù)甚至數(shù)據(jù)中心的故障王污，以測試應(yīng)用程序的彈性和監(jiān)控罢吃。
這種生產(chǎn)中的自動化測試足以讓大多數(shù)操作組在休息一周之前就會發(fā)抖。這并不是說整體式建筑風(fēng)格不具備復(fù)雜的監(jiān)控設(shè)置 - 在我們的經(jīng)驗中它不常見玉掸。
由于服務(wù)可能隨時發(fā)生故障刃麸，因此能夠快速檢測故障并在可能的情況下自動恢復(fù)服務(wù)非常重要。微服務(wù)應(yīng)用程序非常重視應(yīng)用程序的實時監(jiān)控司浪，檢查架構(gòu)元素（數(shù)據(jù)庫每秒獲得多少請求）和業(yè)務(wù)相關(guān)度量（例如每分鐘收到多少訂單）泊业。語義監(jiān)控可以提供出現(xiàn)問題的早期預(yù)警系統(tǒng)把沼，從而觸發(fā)開發(fā)團(tuán)隊跟進(jìn)和調(diào)查。
這對于微服務(wù)架構(gòu)尤為重要吁伺，因為微服務(wù)對編排和事件協(xié)作的偏好 會導(dǎo)致緊急行為饮睬。雖然許多權(quán)威人士贊揚(yáng)偶然出現(xiàn)的價值，但事實是篮奄，新興行為有時可能是一件壞事捆愁。監(jiān)控對于快速發(fā)現(xiàn)不良緊急行為至關(guān)重要，因此可以修復(fù)窟却。
Monoliths可以像微服務(wù)一樣透明 - 事實上昼丑，它們應(yīng)該是。不同之處在于您絕對需要知道在不同進(jìn)程中運(yùn)行的服務(wù)何時斷開連接夸赫。對于同一過程中的庫菩帝，這種透明性不太可能有用。
微服務(wù)團(tuán)隊希望看到針對每個服務(wù)的復(fù)雜監(jiān)控和日志記錄設(shè)置茬腿，例如顯示上/下狀態(tài)的儀表板以及各種運(yùn)營和業(yè)務(wù)相關(guān)指標(biāo)呼奢。有關(guān)斷路器狀態(tài)，當(dāng)前吞吐量和延遲的詳細(xì)信息是我們經(jīng)常遇到的其他示例切平。
進(jìn)化設(shè)計
微服務(wù)從業(yè)者通常來自進(jìn)化設(shè)計背景握础，并將服務(wù)分解視為進(jìn)一步的工具，使應(yīng)用程序開發(fā)人員能夠控制應(yīng)用程序中的更改悴品，而不會降低變更速度禀综。變更控制并不一定意味著改變 - 通過正確的態(tài)度和工具，您可以對軟件進(jìn)行頻繁他匪，快速和良好控制的更改菇存。
每當(dāng)您嘗試將軟件系統(tǒng)分解為組件時，您就面臨著如何劃分各個部分的決定 - 我們決定將應(yīng)用程序分割的原則是什么邦蜜？組件的關(guān)鍵屬性是獨(dú)立替換和可升級性的概念 - 這意味著我們尋找可以想象在不影響其協(xié)作者的情況下重寫組件的點(diǎn)。實際上亥至，許多微服務(wù)組通過明確期望許多服務(wù)被廢棄而不是長期發(fā)展來進(jìn)一步考慮這一點(diǎn)悼沈。
Guardian網(wǎng)站是一個設(shè)計和構(gòu)建為整體的應(yīng)用程序的一個很好的例子，但是已經(jīng)在微服務(wù)方向上發(fā)展姐扮。monolith仍然是網(wǎng)站的核心絮供，但他們更喜歡通過構(gòu)建使用monolith API的微服務(wù)來添加新功能。這種方法對于本質(zhì)上是臨時的功能尤其方便茶敏，例如處理體育賽事的專用頁面壤靶。網(wǎng)站的這一部分可以使用快速開發(fā)語言快速組合在一起，并在事件結(jié)束后刪除惊搏。我們在金融機(jī)構(gòu)看到了類似的方法贮乳，為市場機(jī)會添加新服務(wù)忧换，并在幾個月甚至幾周后丟棄。
這種對可替換性的強(qiáng)調(diào)是模塊化設(shè)計的更一般原則的一個特例向拆，即通過變化模式驅(qū)動模塊化亚茬。您希望在同一模塊中保持同時更改的內(nèi)容。很少變化的系統(tǒng)部分應(yīng)該與目前正在經(jīng)歷大量流失的系統(tǒng)處于不同的服務(wù)中浓恳。如果您發(fā)現(xiàn)自己一再改變兩項服務(wù)刹缝，那就表明它們應(yīng)該合并。
將組件放入服務(wù)中可以為更細(xì)粒度的發(fā)布計劃添加機(jī)會颈将。對于整體梢夯，任何更改都需要完整構(gòu)建和部署整個應(yīng)用程序。但是晴圾，使用微服務(wù)厨疙，您只需要重新部署您修改的服務(wù)。這可以簡化并加快發(fā)布過程疑务。缺點(diǎn)是您必須擔(dān)心一項服務(wù)的變化會打破其消費(fèi)者沾凄。傳統(tǒng)的集成方法是嘗試使用版本控制來解決這個問題，但微服務(wù)領(lǐng)域的偏好是僅使用版本控制作為最后的手段知允。我們可以通過將服務(wù)設(shè)計為對供應(yīng)商變更盡可能寬容來避免大量版本控制撒蟀。
微服務(wù)是未來嗎？
我們寫這篇文章的主要目的是解釋微服務(wù)的主要思想和原則温鸽。通過花時間來做到這一點(diǎn)保屯，我們清楚地認(rèn)為微服務(wù)架構(gòu)風(fēng)格是一個重要的想法 - 值得認(rèn)真考慮企業(yè)應(yīng)用程序。我們最近使用這種方式構(gòu)建了幾個系統(tǒng)涤垫，并了解其他已經(jīng)使用并支持這種方法的系統(tǒng)姑尺。
我們知道誰在某種程度上開創(chuàng)了建筑風(fēng)格，包括亞馬遜蝠猬，Netflix切蟋，衛(wèi)報，英國政府?dāng)?shù)字服務(wù)榆芦，realestate.com.au柄粹，F(xiàn)orward和comparethemarket.com。2013年的會議電路充滿了一些公司的例子匆绣，這些公司正在轉(zhuǎn)向可以歸類為微服務(wù)的公司 - 包括Travis CI驻右。此外，有很多組織長期以來一直在做我們稱之為微服務(wù)的東西崎淳，但沒有使用過這個名字堪夭。（通常這被標(biāo)記為SOA - 盡管如我們所說，SOA有許多相互矛盾的形式。
然而森爽，盡管有這些積極的經(jīng)驗恨豁，但我們并不認(rèn)為我們確信微服務(wù)是軟件架構(gòu)的未來發(fā)展方向。雖然到目前為止我們的經(jīng)驗與整體應(yīng)用相比是積極的拗秘，但我們意識到?jīng)]有足夠的時間讓我們做出充分的判斷圣絮。
通常，您的架構(gòu)決策的真正后果只有在您制作它們幾年后才會明顯雕旨。我們已經(jīng)看到一個項目扮匠，一個優(yōu)秀的團(tuán)隊，對模塊化的強(qiáng)烈渴望凡涩，已經(jīng)建立了一個多年來已經(jīng)腐朽的單片架構(gòu)棒搜。許多人認(rèn)為微服務(wù)不太可能出現(xiàn)這種衰退，因為服務(wù)邊界是明確的活箕，很難修補(bǔ)力麸。然而，在我們看到足夠的系統(tǒng)具有足夠的年齡之前育韩，我們無法真正評估微服務(wù)架構(gòu)是如何成熟的克蚂。
人們可能會期望微服務(wù)成熟得很好。在組件化的任何努力中筋讨，成功取決于軟件在組件中的適用程度埃叭。很難弄清楚組件邊界的確切位置。進(jìn)化設(shè)計認(rèn)識到正確邊界的困難悉罕，因此很容易重構(gòu)它們的重要性赤屋。但是當(dāng)您的組件是具有遠(yuǎn)程通信的服務(wù)時，那么重構(gòu)比使用進(jìn)程內(nèi)庫要困難得多壁袄±嘣纾跨服務(wù)邊界移動代碼很困難，需要在參與者之間協(xié)調(diào)任何接口更改嗜逻，需要添加向后兼容性層涩僻，并且測試變得更加復(fù)雜。
另一個問題是如果組件沒有干凈地組成变泄，那么您所做的就是將復(fù)雜性從組件內(nèi)部轉(zhuǎn)移到組件之間的連接令哟。這不僅僅是移動復(fù)雜性，而是將其移動到一個不那么明確且難以控制的地方妨蛹。當(dāng)你在一個小而簡單的組件內(nèi)部查看時，很容易認(rèn)為事情會更好晴竞，同時缺少服務(wù)之間的混亂連接蛙卤。
最后，還有團(tuán)隊技能的因素。新技術(shù)往往被更熟練的團(tuán)隊所采用颤难。但對于技能更高的團(tuán)隊來說神年，一種更有效的技術(shù)并不一定適用于技能較低的團(tuán)隊。我們已經(jīng)看到很多不太熟練的團(tuán)隊構(gòu)建混亂的單片架構(gòu)行嗤，但是當(dāng)微服務(wù)發(fā)生這種混亂時已日，需要花時間看看會發(fā)生什么。一個糟糕的團(tuán)隊總是會創(chuàng)建一個糟糕的系統(tǒng) - 很難說微服務(wù)是否可以減少這種情況下的混亂或使情況變得更糟栅屏。
我們聽到的一個合理的論點(diǎn)是飘千，您不應(yīng)該從微服務(wù)架構(gòu)開始。相反栈雳， 從整體開始护奈，保持模塊化，并在整體成為問題時將其拆分為微服務(wù)哥纫。（雖然 這個建議并不理想霉旗，但是好的進(jìn)程內(nèi)接口通常不是一個好的服務(wù)接口。）
因此蛀骇，我們謹(jǐn)慎樂觀地寫下這一點(diǎn)厌秒。到目前為止，我們已經(jīng)看到了足夠多的微服務(wù)風(fēng)格擅憔，覺得它是 一條值得走的路鸵闪。我們無法確定最終會在哪里結(jié)束，但軟件開發(fā)的挑戰(zhàn)之一是您只能根據(jù)您當(dāng)前必須提供的不完善信息做出決策雕欺。
