微服務(wù)
這個(gè)新架構(gòu)術(shù)語的定義
在過去的幾年中，出現(xiàn)了“微服務(wù)體系結(jié)構(gòu)”一詞，用于描述將軟件應(yīng)用程序設(shè)計(jì)為可獨(dú)立部署的服務(wù)套件的特定方式。盡管沒有這種架構(gòu)樣式的精確定義，但圍繞業(yè)務(wù)能力，自動(dòng)部署，端點(diǎn)中的智能以及對(duì)語言和數(shù)據(jù)的分散控制，組織周圍存在某些共同特征。
2014年3月25日
James Lewis是ThoughtWorks的首席顧問和技術(shù)顧問委員會(huì)的成員。James對(duì)通過小型協(xié)作服務(wù)構(gòu)建應(yīng)用程序的興趣源于大規(guī)模集成企業(yè)系統(tǒng)的背景。他使用微服務(wù)構(gòu)建了許多系統(tǒng)，并在成長中的社區(qū)中積極參與了兩年。
Martin Fowler是軟件開發(fā)的作者，演講者和大聲講話。長期以來，他一直對(duì)如何組成軟件系統(tǒng)的問題感到困惑，因?yàn)槁牭降哪：f法不盡如人意。他希望微服務(wù)能夠?qū)崿F(xiàn)其擁護(hù)者發(fā)現(xiàn)的早期承諾。
翻譯：日語 ·俄語 ·韓語 ·葡萄牙語 ·簡體中文 ·簡體中文 ·波斯語
內(nèi)容
側(cè)邊欄
- 微服務(wù)有多大？
- 微服務(wù)和SOA
- 多種語言，多種選擇
- 經(jīng)過戰(zhàn)斗測試的標(biāo)準(zhǔn)和強(qiáng)制執(zhí)行的標(biāo)準(zhǔn)
- 輕松做正確的事
- 斷路器和生產(chǎn)就緒代碼
- 同步呼叫被認(rèn)為是有害的
“微服務(wù)”-在擁擠的軟件體系結(jié)構(gòu)大街上的又一個(gè)新名詞。盡管我們的天性是輕蔑地掠過這些事物，但是這種術(shù)語描述了一種越來越受歡迎的軟件系統(tǒng)樣式。在過去的幾年中，我們已經(jīng)看到許多項(xiàng)目都使用這種樣式，到目前為止，結(jié)果是非常積極的，以至于對(duì)于我們的許多同事來說，這已成為構(gòu)建企業(yè)應(yīng)用程序的默認(rèn)樣式。但是，令人遺憾的是，沒有太多信息可以概述微服務(wù)風(fēng)格是什么以及如何實(shí)現(xiàn)。
簡而言之，微服務(wù)架構(gòu)樣式[1]是一種將單個(gè)應(yīng)用程序開發(fā)為一組小服務(wù)的方法，每個(gè)小服務(wù)都在自己的進(jìn)程中運(yùn)行并與輕量級(jí)機(jī)制（通常是HTTP資源API）進(jìn)行通信。這些服務(wù)圍繞業(yè)務(wù)功能構(gòu)建，并且可以由全自動(dòng)部署機(jī)制獨(dú)立部署。這些服務(wù)的集中管理幾乎沒有，可以用不同的編程語言編寫并使用不同的數(shù)據(jù)存儲(chǔ)技術(shù)。
我的微服務(wù)資源指南提供了有關(guān)微服務(wù)的最佳文章，視頻，書籍和播客的鏈接。
要開始解釋微服務(wù)樣式，將其與整體式樣式進(jìn)行比較很有用：以單個(gè)單元構(gòu)建的整體式應(yīng)用程序。企業(yè)應(yīng)用程序通常由三個(gè)主要部分構(gòu)建：客戶端用戶界面（由在用戶計(jì)算機(jī)上的瀏覽器中運(yùn)行的HTML頁面和javascript組成）和數(shù)據(jù)庫（由插入常見的（通常是關(guān)系式的）數(shù)據(jù)庫管理中的許多表組成）系統(tǒng)）和服務(wù)器端應(yīng)用程序。服務(wù)器端應(yīng)用程序?qū)⑻幚鞨TTP請(qǐng)求，執(zhí)行域邏輯，從數(shù)據(jù)庫中檢索和更新數(shù)據(jù)，以及選擇并填充要發(fā)送到瀏覽器的HTML視圖。這個(gè)服務(wù)器端應(yīng)用程序是一個(gè)整體-一個(gè)邏輯可執(zhí)行文件[2]。對(duì)系統(tǒng)的任何更改都涉及構(gòu)建和部署新版本的服務(wù)器端應(yīng)用程序。
這種整體服務(wù)器是構(gòu)建此類系統(tǒng)的自然方法。您處理請(qǐng)求的所有邏輯都在單個(gè)過程中運(yùn)行，從而使您可以使用語言的基本功能將應(yīng)用程序劃分為類，函數(shù)和名稱空間。一定要小心，您可以在開發(fā)人員的筆記本電腦上運(yùn)行和測試應(yīng)用程序，并使用部署管道來確保正確測試了更改并將其部署到生產(chǎn)中。您可以通過在負(fù)載均衡器后面運(yùn)行許多實(shí)例來水平縮放整體。
整體應(yīng)用程序可以成功，但是越來越多的人對(duì)它們感到沮喪，尤其是隨著越來越多的應(yīng)用程序部署到云中。變更周期捆綁在一起-對(duì)應(yīng)用程序的一小部分進(jìn)行更改，需要重建和部署整個(gè)整體。隨著時(shí)間的流逝，通常很難保持良好的模塊化結(jié)構(gòu)，這使得很難保留只影響該模塊中一個(gè)模塊的更改。擴(kuò)展要求擴(kuò)展整個(gè)應(yīng)用程序，而不是需要更多資源的部分應(yīng)用程序。
這些挫敗感導(dǎo)致了微服務(wù)架構(gòu)的風(fēng)格：將應(yīng)用程序構(gòu)建為服務(wù)套件。除了服務(wù)可獨(dú)立部署和可擴(kuò)展之外，每個(gè)服務(wù)還提供了牢固的模塊邊界，甚至允許使用不同的編程語言編寫不同的服務(wù)。他們也可以由不同的團(tuán)隊(duì)管理。
我們并不聲稱微服務(wù)風(fēng)格是新穎的或創(chuàng)新的，它的根源至少可以追溯到Unix的設(shè)計(jì)原理。但是我們確實(shí)認(rèn)為沒有足夠的人考慮微服務(wù)架構(gòu)，如果使用微服務(wù)架構(gòu)，許多軟件開發(fā)會(huì)更好。
微服務(wù)架構(gòu)的特征
我們不能說對(duì)微服務(wù)架構(gòu)風(fēng)格有一個(gè)正式的定義，但是我們可以嘗試描述我們認(rèn)為適合該標(biāo)簽的架構(gòu)的共同特征。與任何概述通用特征的定義一樣，并非所有微服務(wù)架構(gòu)都具有所有特征，但是我們確實(shí)希望大多數(shù)微服務(wù)架構(gòu)都具有大多數(shù)特征。盡管我們的作者一直是這個(gè)相當(dāng)松散的社區(qū)的活躍成員，但我們的意圖是嘗試描述我們?cè)谧约旱墓ぷ饕约拔覀兯J(rèn)識(shí)的團(tuán)??隊(duì)的類似努力中所看到的。特別是，我們沒有規(guī)定要符合的定義。
通過服務(wù)進(jìn)行組件化
自從我們從事軟件行業(yè)以來，就一直希望通過將組件連接在一起來構(gòu)建系統(tǒng)，這與我們?cè)谖锢硎澜缰锌吹绞挛锏姆绞椒浅Ｏ嗨?。在過去的幾十年中，我們看到了在大多數(shù)語言平臺(tái)中都包含的大量通用庫概要中取得了長足的進(jìn)步。
在談?wù)摻M件時(shí)，我們會(huì)遇到難以定義組件的定義。我們的定義是 組件是獨(dú)立可替換和可升級(jí)的軟件單元。
微服務(wù)架構(gòu)將使用庫，但是它們將自己的軟件組成組件的主要方式是分解成服務(wù)。我們將庫定義 為鏈接到程序中并使用內(nèi)存中函數(shù)調(diào)用進(jìn)行調(diào)用的組件，而服務(wù)則是進(jìn)程外組件，它們通過某種機(jī)制（例如Web服務(wù)請(qǐng)求或遠(yuǎn)程過程調(diào)用）進(jìn)行通信。（這與許多OO程序中的服務(wù)對(duì)象的概念不同[3]。）
使用服務(wù)作為組件（而不是庫）的主要原因之一是服務(wù)是可獨(dú)立部署的。如果您的應(yīng)用程序[4]在單個(gè)過程中包含多個(gè)庫，則對(duì)任何單個(gè)組件的更改都會(huì)導(dǎo)致必須重新部署整個(gè)應(yīng)用程序。但是，如果該應(yīng)用程序分解為多個(gè)服務(wù)，則可以預(yù)期許多單個(gè)服務(wù)的更改僅要求重新部署該服務(wù)。這不是絕對(duì)的，某些更改會(huì)改變服務(wù)接口，從而導(dǎo)致某種程度的協(xié)調(diào)，但是好的微服務(wù)架構(gòu)的目的是通過服務(wù)契約的內(nèi)聚性服務(wù)邊界和演化機(jī)制來最小化它們。
將服務(wù)用作組件的另一個(gè)結(jié)果是更明確的組件接口。大多數(shù)語言都沒有定義明確的發(fā)布接口的良好機(jī)制。通常，唯一的文檔和紀(jì)律可以防止客戶端破壞組件的封裝，從而導(dǎo)致組件之間的耦合過于緊密。服務(wù)通過使用顯式的遠(yuǎn)程調(diào)用機(jī)制使避免這種情況變得更加容易。
使用這樣的服務(wù)確實(shí)有缺點(diǎn)。遠(yuǎn)程調(diào)用比進(jìn)程內(nèi)調(diào)用更昂貴，因此遠(yuǎn)程API需要更粗粒度，這通常更難使用。如果您需要更改組件之間的職責(zé)分配，那么當(dāng)您跨越流程邊界時(shí)，這種行為轉(zhuǎn)移就很難做到。
初看起來，我們可以觀察到服務(wù)映射到運(yùn)行時(shí)進(jìn)程，但這僅僅是初看起來。服務(wù)可能包含將始終一起開發(fā)和部署的多個(gè)流程，例如僅由該服務(wù)使用的應(yīng)用程序流程和數(shù)據(jù)庫。
圍繞業(yè)務(wù)能力進(jìn)行組織
當(dāng)希望將大型應(yīng)用程序拆分為多個(gè)部分時(shí)，管理層通常將重點(diǎn)放在技術(shù)層，從而導(dǎo)致UI團(tuán)隊(duì)，服務(wù)器端邏輯團(tuán)隊(duì)和數(shù)據(jù)庫團(tuán)隊(duì)。當(dāng)團(tuán)隊(duì)按這些方向分開時(shí)，即使簡單的更改也可能導(dǎo)致跨團(tuán)隊(duì)項(xiàng)目需要時(shí)間和預(yù)算批準(zhǔn)。精明的團(tuán)隊(duì)會(huì)圍繞此問題進(jìn)行優(yōu)化，并針對(duì)兩種弊端中的較小者進(jìn)行處理-只需將邏輯強(qiáng)加給他們可以訪問的任何應(yīng)用程序即可。換句話說，邏輯無處不在。這是康威定律[5]發(fā)揮作用的一個(gè)例子。
設(shè)計(jì)系統(tǒng)（廣泛定義）的任何組織都將產(chǎn)生其結(jié)構(gòu)是組織通信結(jié)構(gòu)副本的設(shè)計(jì)。
-梅爾文·康威（Melvin Conway），1968年
細(xì)分的微服務(wù)方法不同，分為圍繞業(yè)務(wù)能力組織的服務(wù) 。此類服務(wù)針對(duì)該業(yè)務(wù)領(lǐng)域采用軟件的廣泛實(shí)施，包括用戶界面，持久性存儲(chǔ)和任何外部協(xié)作。因此，團(tuán)隊(duì)是跨職能的，包括開發(fā)所需的全部技能：用戶體驗(yàn)，數(shù)據(jù)庫和項(xiàng)目管理。
微服務(wù)有多大？
盡管“微服務(wù)”已成為這種體系結(jié)構(gòu)樣式的流行名稱，但不幸的是，它的名稱確實(shí)導(dǎo)致人們對(duì)服務(wù)規(guī)模的關(guān)注，以及關(guān)于“微”的構(gòu)成的爭論。在與微服務(wù)從業(yè)者的對(duì)話中，我們看到了各種規(guī)模的服務(wù)。報(bào)告的最大尺寸遵循亞馬遜的“兩個(gè)比薩餅團(tuán)隊(duì)”的概念（即整個(gè)團(tuán)隊(duì)可以吃兩個(gè)比薩餅），意思是最多可以吃十二個(gè)人。在較小的規(guī)模上，我們看到了一組六個(gè)打混的團(tuán)隊(duì)將支持六個(gè)打混的服務(wù)的設(shè)置。
這就引發(fā)了一個(gè)問題，即在此大小范圍內(nèi)是否存在足夠大的差異，以致每六個(gè)人的服務(wù)大小和每個(gè)人的服務(wù)大小不應(yīng)該被歸入一個(gè)微服務(wù)標(biāo)簽之下。目前，我們認(rèn)為最好將它們組合在一起，但是隨著我們進(jìn)一步探索這種風(fēng)格，我們肯定會(huì)改變主意。
以這種方式組織的一家公司是www.comparethemarket.com。跨職能團(tuán)隊(duì)負(fù)責(zé)構(gòu)建和操作每個(gè)產(chǎn)品，每個(gè)產(chǎn)品分為多個(gè)單獨(dú)的服務(wù)，這些服務(wù)通過消息總線進(jìn)行通信。
大型單片應(yīng)用程序也始終可以圍繞業(yè)務(wù)功能進(jìn)行模塊化，盡管這種情況并不常見。當(dāng)然，我們會(huì)敦促組成一個(gè)整體應(yīng)用程序的大型團(tuán)隊(duì)按照業(yè)務(wù)線劃分自己。我們?cè)谶@里看到的主要問題是，它們往往是圍繞太多環(huán)境來組織的。如果整體跨越了這些模塊化邊界中的許多邊界，那么團(tuán)隊(duì)中的各個(gè)成員可能很難將其放入他們的短期記憶中。另外，我們看到模塊化的生產(chǎn)線需要大量的紀(jì)律來實(shí)施。服務(wù)組件所需的必要的，更明確的分隔使得更容易保持團(tuán)隊(duì)界限。
產(chǎn)品不是項(xiàng)目
我們看到的大多數(shù)應(yīng)用程序開發(fā)工作都使用項(xiàng)目模型：目的是交付某些軟件，然后將其視為已完成。完成后，將軟件移交給維護(hù)組織，并解散構(gòu)建該軟件的項(xiàng)目團(tuán)隊(duì)。
微服務(wù)的支持者傾向于避免這種模式，而是傾向于團(tuán)隊(duì)?wèi)?yīng)該在產(chǎn)品的整個(gè)生命周期內(nèi)擁有產(chǎn)品的想法。這樣做的一個(gè)共同靈感是亞馬遜的“構(gòu)建，運(yùn)行”概念，其中開發(fā)團(tuán)隊(duì)對(duì)生產(chǎn)中的軟件負(fù)全部責(zé)任。這使開發(fā)人員可以日常接觸其軟件在生產(chǎn)中的行為方式，并增加與用戶的接觸，因?yàn)樗麄儽仨毘袚?dān)至少一些支持負(fù)擔(dān)。
產(chǎn)品的心態(tài)與業(yè)務(wù)能力的聯(lián)系緊密相關(guān)。與其將軟件視為要完成的功能集，不如說存在著一種持續(xù)的關(guān)系，即問題是軟件如何幫助其用戶增強(qiáng)業(yè)務(wù)能力。
沒有理由不能在整體應(yīng)用程序中采用相同的方法，但是較小的服務(wù)粒度可以使在服務(wù)開發(fā)人員與其用戶之間建立個(gè)人關(guān)系變得更加容易。
智能端點(diǎn)和啞管道
在不同流程之間建立通信結(jié)構(gòu)時(shí)，我們已經(jīng)看到了許多產(chǎn)品和方法，這些產(chǎn)品和方法強(qiáng)調(diào)在通信機(jī)制本身中投入大量智慧。一個(gè)很好的例子就是企業(yè)服務(wù)總線（ESB），其中，ESB產(chǎn)品通常包括用于消息路由，編排，轉(zhuǎn)換和應(yīng)用業(yè)務(wù)規(guī)則的復(fù)雜工具。
微服務(wù)和SOA
當(dāng)我們談?wù)撐⒎?wù)時(shí)，一個(gè)常見的問題是這是否只是我們十年前看到的面向服務(wù)的體系結(jié)構(gòu)（SOA）。這一點(diǎn)是有好處的，因?yàn)槲⒎?wù)風(fēng)格與某些SOA擁護(hù)者所支持的風(fēng)格非常相似。但是，問題在于SOA意味著太多不同的事物，而且在大多數(shù)情況下，我們遇到一種稱為“ SOA”的東西，這與我們?cè)诖嗣枋龅臉邮接泻艽蟛煌?，通常是因?yàn)橹塾谶^去的ESB。集成單片應(yīng)用程序。
特別是，我們已經(jīng)看到了許多面向服務(wù)的拙劣實(shí)現(xiàn)，從傾向于將復(fù)雜性隱藏在ESB的[6]中，到失敗的，花費(fèi)數(shù)百萬美元且沒有價(jià)值的多年計(jì)劃，到積極抑制變更的集中式治理模型，有時(shí)很難看清這些問題。
當(dāng)然，微服務(wù)社區(qū)中使用的許多技術(shù)都是從開發(fā)人員在大型組織中集成服務(wù)的經(jīng)驗(yàn)中獲得的。的容錯(cuò)閱讀器模式是這樣的一個(gè)例子。使用網(wǎng)絡(luò)的努力有所貢獻(xiàn)，使用簡單的協(xié)議是從這些經(jīng)驗(yàn)中獲得的另一種方法-坦率地說，這種反應(yīng)偏離了達(dá)到復(fù)雜性的中心標(biāo)準(zhǔn)。（每當(dāng)您需要一個(gè)本體來管理本體時(shí)，您就知道自己陷入了嚴(yán)重的麻煩。）
SOA的這種普遍表現(xiàn)導(dǎo)致一些微服務(wù)擁護(hù)者完全拒絕了SOA標(biāo)簽，盡管其他人認(rèn)為微服務(wù)是SOA的一種形式[7]，也許面向服務(wù)是正確的。無論哪種方式，SOA意味著如此不同的事實(shí)這一事實(shí)意味著，擁有一個(gè)更清晰地定義該體系結(jié)構(gòu)樣式的術(shù)語很有價(jià)值。
微服務(wù)社區(qū)贊成一種替代方法： 智能端點(diǎn)和啞管道。從微服務(wù)構(gòu)建的應(yīng)用程序旨在盡可能地分離和具有凝聚力-它們擁有自己的域邏輯，并在傳統(tǒng)的Unix意義上充當(dāng)過濾器-接收請(qǐng)求，適當(dāng)?shù)貞?yīng)用邏輯并產(chǎn)生響應(yīng)。使用簡單的RESTish協(xié)議而不是諸如WS-Choreography或BPEL之類的復(fù)雜協(xié)議或通過中央工具進(jìn)行編排來對(duì)這些文件進(jìn)行編排。
最常用的兩種協(xié)議是帶有資源API的HTTP請(qǐng)求響應(yīng)和輕量級(jí)消息傳遞[8]。第一個(gè)的最好表達(dá)是
在網(wǎng)絡(luò)上，而不是在網(wǎng)絡(luò)后面
微服務(wù)團(tuán)隊(duì)使用建立在萬維網(wǎng)（很大程度上是Unix）上的原理和協(xié)議。通常，開發(fā)人員或操作人員只需很少的精力就可以緩存使用過的資源。
常用的第二種方法是通過輕量級(jí)消息總線進(jìn)行消息傳遞。所選的基礎(chǔ)結(jié)構(gòu)通常是啞巴的（啞巴僅用作消息路由器）-簡單的實(shí)現(xiàn)（例如RabbitMQ或ZeroMQ）除了提供可靠的異步結(jié)構(gòu)外，所做的工作不多-智能終端仍然存在于生產(chǎn)和銷售端點(diǎn)消費(fèi)信息；在服務(wù)中。
在整體中，組件在進(jìn)程內(nèi)執(zhí)行，并且它們之間的通信是通過方法調(diào)用或函數(shù)調(diào)用進(jìn)行的。將整體式服務(wù)轉(zhuǎn)換為微服務(wù)的最大問題在于更改通信模式。從內(nèi)存中方法調(diào)用到RPC的幼稚轉(zhuǎn)換會(huì)導(dǎo)致健談的通信，效果不佳。相反，您需要使用更粗粒度的方法來替換細(xì)粒度的通信。
分散治理
集中治理的后果之一是傾向于在單一技術(shù)平臺(tái)上實(shí)現(xiàn)標(biāo)準(zhǔn)化。經(jīng)驗(yàn)表明，這種方法是束手無策的-并非每個(gè)問題都是釘子，也不是每個(gè)解決方案都是錘子。我們更喜歡使用正確的工具來完成工作，而整體式應(yīng)用程序可以在一定程度上利用不同的語言，但這并不常見。
將整體組件拆分為服務(wù)時(shí)，我們?cè)跇?gòu)建每個(gè)組件時(shí)都可以選擇。您想使用Node.js站起來一個(gè)簡單的報(bào)告頁面嗎？去吧。C ++是否適合用于特別粗糙的近實(shí)時(shí)組件？精細(xì)。您要交換一種更適合某個(gè)組件的讀取行為的數(shù)據(jù)庫類型嗎？我們擁有重建他的技術(shù)。
當(dāng)然，僅僅因?yàn)槟?em>可以做某事，并不意味著您應(yīng)該-而是通過這種方式對(duì)系統(tǒng)進(jìn)行分區(qū)意味著您可以選擇。
構(gòu)建微服務(wù)的團(tuán)隊(duì)也更喜歡采用不同的標(biāo)準(zhǔn)方法。與其使用書面在紙上某個(gè)地方寫下的一組定義的標(biāo)準(zhǔn)，他們更喜歡產(chǎn)生有用的工具的想法，其他開發(fā)人員可以使用這些工具來解決與其面臨的類似問題。這些工具通常是從實(shí)現(xiàn)中獲取的，有時(shí)與更廣泛的群體共享，但并非唯一地使用內(nèi)部開源模型。既然git和github已經(jīng)成為事實(shí)上的版本控制系統(tǒng)的選擇，內(nèi)部內(nèi)部的開放源碼實(shí)踐也變得越來越普遍。
Netflix是遵循這種理念的組織的一個(gè)很好的例子。共享有用的，最重要的是，經(jīng)過試驗(yàn)驗(yàn)證的代碼，因?yàn)閹旃膭?lì)其他開發(fā)人員以類似的方式解決類似的問題，但仍為選擇其他方法（如果需要）打開了大門。共享庫往往集中在數(shù)據(jù)存儲(chǔ)，進(jìn)程間通信以及我們?cè)谙旅孢M(jìn)一步討論的基礎(chǔ)架構(gòu)自動(dòng)化等常見問題上。
對(duì)于微服務(wù)社區(qū)而言，開銷尤其沒有吸引力。這并不是說社區(qū)不重視服務(wù)合同。相反，因?yàn)樗鼈兺唷Ｖ皇撬麄冋趯ふ夜芾磉@些合同的不同方法。容忍讀者和消費(fèi)者驅(qū)動(dòng)的合同之類的模式 通常應(yīng)用于微服務(wù)。這些援助服務(wù)合同是獨(dú)立發(fā)展的。在構(gòu)建過程中執(zhí)行以消費(fèi)者為導(dǎo)向的合同可以增強(qiáng)信心，并提供有關(guān)服務(wù)是否正常運(yùn)行的快速反饋。實(shí)際上，我們知道在澳大利亞有一個(gè)團(tuán)隊(duì)，該團(tuán)隊(duì)通過消費(fèi)者驅(qū)動(dòng)的合同來推動(dòng)新服務(wù)的構(gòu)建。他們使用簡單的工具來定義服務(wù)合同。在為新服務(wù)編寫代碼之前，這已成為自動(dòng)化構(gòu)建的一部分。然后，僅將服務(wù)構(gòu)建到滿足合同的程度，這是避免使用“ YAGNI”的一種優(yōu)雅方法[9]開發(fā)新軟件時(shí)的困境。這些技術(shù)及其周圍發(fā)展的工具通過減少服務(wù)之間的時(shí)間耦合來限制對(duì)中央合同管理的需求。
多種語言，多種選擇
JVM作為平臺(tái)的增長只是在通用平臺(tái)內(nèi)混合語言的最新示例。幾十年來，使用高級(jí)語言進(jìn)行剝殼是一種常見的做法。順便說一句，并在較低的級(jí)別編寫對(duì)性能敏感的代碼。但是，許多巨石都不需要這種級(jí)別的性能優(yōu)化，也不需要DSL和更高級(jí)別的抽象（這讓我們沮喪）。相反，整體語言通常是單一語言，趨勢是限制所使用技術(shù)的數(shù)量[10]。
分散治理的最高點(diǎn)也許是亞馬遜推廣的構(gòu)建/運(yùn)行它的精神。團(tuán)隊(duì)負(fù)責(zé)他們構(gòu)建的軟件的各個(gè)方面，包括24/7全天候運(yùn)行的軟件。這種責(zé)任級(jí)別的下放絕對(duì)不是常態(tài)，但我們確實(shí)看到越來越多的公司將責(zé)任推向開發(fā)團(tuán)隊(duì)。Netflix是采用這種精神的另一個(gè)組織[11]。您的尋呼機(jī)每天晚上3點(diǎn)醒來，肯定是在編寫代碼時(shí)專注于質(zhì)量的強(qiáng)大動(dòng)力。這些想法盡可能遠(yuǎn)離傳統(tǒng)的集中式治理模型。
分散數(shù)據(jù)管理
數(shù)據(jù)管理的分散化以多種不同的方式呈現(xiàn)。從最抽象的角度講，這意味著系統(tǒng)的世界概念模型將有所不同。在大型企業(yè)中進(jìn)行集成時(shí)，這是一個(gè)常見問題，客戶的銷售視圖將與支持視圖不同。在銷售視圖中稱為客戶的某些內(nèi)容可能根本不會(huì)出現(xiàn)在支持視圖中。那些具有相同屬性的屬性可能具有不同的語義，并且（更差的）共同屬性具有不同的語義。
經(jīng)過戰(zhàn)斗測試的標(biāo)準(zhǔn)和強(qiáng)制執(zhí)行的標(biāo)準(zhǔn)
微服務(wù)團(tuán)隊(duì)傾向于避開企業(yè)體系結(jié)構(gòu)組制定的那種嚴(yán)格的強(qiáng)制性標(biāo)準(zhǔn)，但是卻樂于使用甚至宣傳使用開放式標(biāo)準(zhǔn)（例如HTTP，ATOM和其他微格式），這有點(diǎn)矛盾。
關(guān)鍵區(qū)別在于標(biāo)準(zhǔn)的制定方式和實(shí)施方式。由IETF等組織管理的標(biāo)準(zhǔn)只有在更廣泛的世界中有幾種實(shí)時(shí)實(shí)施時(shí)才成為標(biāo)準(zhǔn)，并且這些標(biāo)準(zhǔn)通常源于成功的開源項(xiàng)目。
這些標(biāo)準(zhǔn)與企業(yè)世界中的許多世界是一個(gè)不同的世界，這些世界通常是由近期編程經(jīng)驗(yàn)很少或受供應(yīng)商影響過大的團(tuán)隊(duì)開發(fā)的。
此問題在應(yīng)用程序之間很常見，但也可能在應(yīng)用程序內(nèi)發(fā)生，特別是當(dāng)該應(yīng)用程序劃分為單獨(dú)的組件時(shí)。關(guān)于這一點(diǎn)的一種有用的思考方法是有界上下文的域驅(qū)動(dòng)設(shè)計(jì)概念 。DDD將復(fù)雜域劃分為多個(gè)有界上下文，并映射出它們之間的關(guān)系。此過程對(duì)于單片和微服務(wù)體系結(jié)構(gòu)都是有用的，但是服務(wù)和上下文邊界之間存在自然的關(guān)聯(lián)，這有助于弄清這一點(diǎn)，并且正如我們?cè)跇I(yè)務(wù)能力部分中所描述的那樣，它加強(qiáng)了分離。
除了分散有關(guān)概念模型的決策外，微服務(wù)還分散了數(shù)據(jù)存儲(chǔ)決策。整體應(yīng)用程序更喜歡使用單個(gè)邏輯數(shù)據(jù)庫存儲(chǔ)持久性數(shù)據(jù)，而企業(yè)通常更喜歡跨多個(gè)應(yīng)用程序使用單個(gè)數(shù)據(jù)庫-這些決定中的許多決定是由供應(yīng)商圍繞許可的商業(yè)模型決定的。微服務(wù)更喜歡讓每個(gè)服務(wù)管理自己的數(shù)據(jù)庫，或者是相同數(shù)據(jù)庫技術(shù)的不同實(shí)例，或者是完全不同的數(shù)據(jù)庫系統(tǒng)-一種稱為Polyglot Persistence的方法。您可以在整體中使用多語種持久性，但是在微服務(wù)中它的出現(xiàn)頻率更高。
跨微服務(wù)將數(shù)據(jù)的責(zé)任分散到管理更新的含義中。處理更新的常見方法是使用事務(wù)來確保更新多個(gè)資源時(shí)的一致性。這種方法通常在整料中使用。
使用這樣的事務(wù)有助于保持一致性，但會(huì)帶來明顯的時(shí)間耦合，這在多個(gè)服務(wù)之間是有問題的。眾所周知，分布式事務(wù)難以實(shí)現(xiàn)，因此，微服務(wù)體系結(jié)構(gòu)強(qiáng)調(diào)服務(wù)之間的無事務(wù)協(xié)調(diào)，并明確認(rèn)識(shí)到一致性可能只是最終的一致性，而問題只能通過補(bǔ)償操作來解決。
對(duì)于許多開發(fā)團(tuán)隊(duì)來說，以這種方式選擇管理不一致是一個(gè)新的挑戰(zhàn)，但這是通常與業(yè)務(wù)實(shí)踐相匹配的挑戰(zhàn)。企業(yè)通常會(huì)處理一定程度的不一致以快速響應(yīng)需求，同時(shí)具有某種逆轉(zhuǎn)流程來處理錯(cuò)誤。只要在更大的一致性下解決錯(cuò)誤的成本小于失去業(yè)務(wù)的成本，就可以進(jìn)行權(quán)衡。
基礎(chǔ)設(shè)施自動(dòng)化
基礎(chǔ)設(shè)施自動(dòng)化技術(shù)在過去幾年中發(fā)生了巨大的發(fā)展，尤其是云技術(shù)和AWS的發(fā)展降低了構(gòu)建，部署和操作微服務(wù)的操作復(fù)雜性。
由微服務(wù)構(gòu)建的許多產(chǎn)品或系統(tǒng)，都是由具有持續(xù)交付及其先驅(qū)持續(xù)集成經(jīng)驗(yàn)的團(tuán)隊(duì)構(gòu)建的。以這種方式構(gòu)建軟件的團(tuán)隊(duì)廣泛使用了基礎(chǔ)架構(gòu)自動(dòng)化技術(shù)。如下所示的構(gòu)建管道中對(duì)此進(jìn)行了說明。
由于這不是有關(guān)持續(xù)交付的文章，因此我們?cè)谶@里僅關(guān)注幾個(gè)關(guān)鍵功能。我們希望盡可能地放心我們的軟件正在運(yùn)行，因此我們運(yùn)行了許多自動(dòng)化測試。升級(jí)工作軟件的渠道意味著我們可以自動(dòng)部署 到每個(gè)新環(huán)境。
輕松做正確的事
我們發(fā)現(xiàn)，由于持續(xù)交付和部署而導(dǎo)致自動(dòng)化程度提高的一個(gè)副作用是，創(chuàng)建了有用的工具來幫助開發(fā)人員和操作人員?，F(xiàn)在，用于創(chuàng)建人工制品，管理代碼庫，建立簡單服務(wù)或添加標(biāo)準(zhǔn)監(jiān)視和日志記錄的工具非常普遍。網(wǎng)絡(luò)上最好的例子可能是Netflix的開源工具集，但還有其他一些工具，包括我們廣泛使用的Dropwizard。
將很高興地在這些環(huán)境中構(gòu)建，測試并推動(dòng)一個(gè)整體應(yīng)用程序。事實(shí)證明，一旦您為自動(dòng)化整體生產(chǎn)進(jìn)行了投資，那么部署更多應(yīng)用程序就不再那么令人恐懼了。請(qǐng)記住，CD的目的之一是使部署變得無聊，因此，只要是一個(gè)應(yīng)用程序還是三個(gè)應(yīng)用程序，只要它仍然很無聊就沒關(guān)系[12]。
我們看到團(tuán)隊(duì)使用廣泛的基礎(chǔ)架構(gòu)自動(dòng)化的另一個(gè)領(lǐng)域是在生產(chǎn)中管理微服務(wù)。與我們上面的斷言相反，只要部署很無聊，整體和微服務(wù)之間就不會(huì)有太大的區(qū)別，每種服務(wù)的運(yùn)營前景可能會(huì)截然不同。
失敗設(shè)計(jì)
將服務(wù)用作組件的結(jié)果是，需要對(duì)應(yīng)用程序進(jìn)行設(shè)計(jì)，以便它們可以容忍服務(wù)故障。由于供應(yīng)商不可用，任何服務(wù)呼叫都可能失敗，客戶必須盡可能優(yōu)雅地對(duì)此做出響應(yīng)。與單片設(shè)計(jì)相比，這是一個(gè)缺點(diǎn)，因?yàn)樗鼛砹祟~外的處理復(fù)雜性。結(jié)果是微服務(wù)團(tuán)隊(duì)不斷反思服務(wù)故障如何影響用戶體驗(yàn)。Netflix的Simian Army 在工作日內(nèi)導(dǎo)致服務(wù)甚至數(shù)據(jù)中心出現(xiàn)故障，以測試應(yīng)用程序的彈性和監(jiān)視能力。
斷路器和生產(chǎn)就緒代碼
斷路器出現(xiàn)在Release It中！
以及“隔板”和“超時(shí)”等其他模式。這些模式一起實(shí)現(xiàn)，在構(gòu)建通信應(yīng)用程序時(shí)至關(guān)重要。該Netflix博客條目在解釋其應(yīng)用方面做得非常好。
這種在生產(chǎn)中的自動(dòng)化測試足以使大多數(shù)操作小組擺脫通常一周的休假期。這并不是說整體式的建筑風(fēng)格無法實(shí)現(xiàn)復(fù)雜的監(jiān)控設(shè)置-在我們的經(jīng)驗(yàn)中這并不常見。
由于服務(wù)隨時(shí)可能發(fā)生故障，因此重要的是能夠快速檢測到故障，并在可能的情況下自動(dòng)恢復(fù)服務(wù)。微服務(wù)應(yīng)用程序非常注重應(yīng)用程序的實(shí)時(shí)監(jiān)控，同時(shí)檢查架構(gòu)元素（數(shù)據(jù)庫每秒收到多少請(qǐng)求）和業(yè)務(wù)相關(guān)指標(biāo)（例如每分鐘收到多少訂單）。語義監(jiān)視可以為發(fā)生錯(cuò)誤的情況提供預(yù)警系統(tǒng)，從而觸發(fā)開發(fā)團(tuán)隊(duì)進(jìn)行跟進(jìn)和調(diào)查。
這對(duì)于微服務(wù)架構(gòu)特別重要，因?yàn)槲⒎?wù)偏愛編排和事件協(xié)作 會(huì)導(dǎo)致緊急行為。盡管許多專家都贊揚(yáng)意外出現(xiàn)的價(jià)值，但事實(shí)是，突然出現(xiàn)的行為有時(shí)可能是一件壞事。監(jiān)視對(duì)于迅速發(fā)現(xiàn)不良緊急行為至關(guān)重要，因此可以對(duì)其進(jìn)行修復(fù)。
同步呼叫被認(rèn)為是有害的
每當(dāng)您在服務(wù)之間進(jìn)行大量同步調(diào)用時(shí)，都會(huì)遇到停機(jī)帶來的成倍影響。簡單來說，這就是系統(tǒng)的停機(jī)時(shí)間成為各個(gè)組件的停機(jī)時(shí)間的產(chǎn)物。您面臨一個(gè)選擇，使您的呼叫異步或管理停機(jī)時(shí)間。他們?cè)?a target="_blank">www.guardian.co.uk上實(shí)現(xiàn)了一個(gè)在新平臺(tái)上的簡單規(guī)則-每個(gè)用戶請(qǐng)求一個(gè)同步調(diào)用，而在Netflix上，他們的平臺(tái)API重新設(shè)計(jì)已將異步性內(nèi)置到API結(jié)構(gòu)中。
整體組件可以像微服務(wù)一樣透明地構(gòu)建-實(shí)際上，它們應(yīng)該如此。區(qū)別在于，您絕對(duì)需要知道何時(shí)在不同進(jìn)程中運(yùn)行的服務(wù)被斷開連接。對(duì)于在同一過程中的庫，這種透明度不太可能有用。
微服務(wù)團(tuán)隊(duì)希望看到每個(gè)服務(wù)的復(fù)雜監(jiān)視和日志記錄設(shè)置，例如顯示上/下狀態(tài)的儀表板以及各種與業(yè)務(wù)和業(yè)務(wù)相關(guān)的指標(biāo)。關(guān)于斷路器狀態(tài)，當(dāng)前吞吐量和等待時(shí)間的詳細(xì)信息是我們?cè)谝巴饨?jīng)常遇到的其他示例。
進(jìn)化設(shè)計(jì)
微服務(wù)從業(yè)人員通常來自進(jìn)化設(shè)計(jì)背景，并將服務(wù)分解視為進(jìn)一步的工具，使應(yīng)用程序開發(fā)人員能夠控制其應(yīng)用程序中的更改而不會(huì)減慢更改速度。變更控制不一定意味著減少變更-使用正確的態(tài)度和工具，您可以頻繁，快速且控制良好地對(duì)軟件進(jìn)行變更。
每當(dāng)您嘗試將軟件系統(tǒng)分解為組件時(shí)，您都會(huì)面臨如何劃分各個(gè)部分的決定-我們決定對(duì)應(yīng)用程序進(jìn)行分割的原則是什么？組件的關(guān)鍵屬性是獨(dú)立替換和可升級(jí)性的概念[13] -這意味著我們尋找可以想象重寫組件而不影響其協(xié)作者的觀點(diǎn)。實(shí)際上，許多微服務(wù)組通過明確期望許多服務(wù)將被廢棄而不是長期發(fā)展而將其進(jìn)一步發(fā)展。
Guardian網(wǎng)站是一個(gè)應(yīng)用程序的一個(gè)很好的例子，該應(yīng)用程序是作為整體設(shè)計(jì)和構(gòu)建的，但是已經(jīng)朝著微服務(wù)的方向發(fā)展。Monolith仍然是網(wǎng)站的核心，但是他們更喜歡通過構(gòu)建使用Monolith的API的微服務(wù)來添加新功能。這種方法對(duì)于固有的臨時(shí)功能（例如處理體育賽事的專用頁面）特別方便?？梢允褂每焖匍_發(fā)語言將網(wǎng)站的此類部分快速組合在一起，并在活動(dòng)結(jié)束后將其刪除。我們已經(jīng)在一家金融機(jī)構(gòu)中看到了類似的方法，在這種方法中，為了獲得市場機(jī)會(huì)而增加了新服務(wù)，而在幾個(gè)月甚至幾周后就將其丟棄。
這種對(duì)可替換性的強(qiáng)調(diào)是模塊化設(shè)計(jì)的更通用原理的特例，該原理通過變化的模式來驅(qū)動(dòng)模塊化[14]。您想在同一模塊中同時(shí)保留更改的內(nèi)容。系統(tǒng)中很少發(fā)生變化的部分應(yīng)該與當(dāng)前大量流失的部分提供不同的服務(wù)。如果您發(fā)現(xiàn)自己反復(fù)更改兩個(gè)服務(wù)，則表明它們應(yīng)該合并。
將組件放入服務(wù)中將為更精細(xì)的發(fā)布計(jì)劃提供機(jī)會(huì)。對(duì)于整體，任何更改都需要完整構(gòu)建和部署整個(gè)應(yīng)用程序。但是，使用微服務(wù)時(shí)，您只需要重新部署您修改過的服務(wù)即可。這樣可以簡化并加快發(fā)布過程。缺點(diǎn)是您必須擔(dān)心一項(xiàng)服務(wù)的更改會(huì)破壞其用戶。傳統(tǒng)的集成方法是嘗試使用版本控制來解決此問題，但是微服務(wù)領(lǐng)域的首選是僅將版本控制作為最后的手段。通過設(shè)計(jì)服務(wù)以盡可能地容忍其供應(yīng)商的變更，我們可以避免很多版本控制。
微服務(wù)是未來嗎？
我們撰寫本文的主要目的是解釋微服務(wù)的主要思想和原理。通過花時(shí)間來做到這一點(diǎn)，我們清楚地認(rèn)為微服務(wù)體系結(jié)構(gòu)風(fēng)格是一個(gè)重要的想法-一個(gè)值得企業(yè)應(yīng)用程序認(rèn)真考慮的想法。我們最近使用該樣式構(gòu)建了多個(gè)系統(tǒng)，并了解了其他使用并喜歡這種方法的系統(tǒng)。
微服務(wù)的權(quán)衡
許多開發(fā)團(tuán)隊(duì)發(fā)現(xiàn)微服務(wù)架構(gòu)風(fēng)格是整體架構(gòu)的一種出色方法。但是其他團(tuán)隊(duì)發(fā)現(xiàn)它們是降低生產(chǎn)率的負(fù)擔(dān)。像任何架構(gòu)風(fēng)格一樣，微服務(wù)帶來成本和收益。要做出明智的選擇，您必須了解這些內(nèi)容并將它們應(yīng)用于您的特定環(huán)境。
馬丁·福勒（Martin Fowler）
2015年7月1日
文章
我們所知道的以某種方式引領(lǐng)建筑風(fēng)格的人包括亞馬遜，Netflix，衛(wèi)報(bào)，英國政府?dāng)?shù)字服務(wù)，realestate.com.au，F(xiàn)orward和comparethemarket.com。在2013年的會(huì)議巡回賽上，到處都有很多公司正在遷移到可歸類為微服務(wù)的公司的例子-包括Travis CI。此外，許多組織長期以來一直在做我們稱之為微服務(wù)的事情，但從未使用過這個(gè)名稱。（通常，它被標(biāo)記為SOA-盡管正如我們已經(jīng)說過的，SOA有許多相互矛盾的形式。[15]）
盡管有這些積極的經(jīng)驗(yàn)，但是，我們并沒有爭論我們可以確定微服務(wù)是軟件體系結(jié)構(gòu)的未來方向。盡管到目前為止，與整體應(yīng)用程序相比，我們的經(jīng)驗(yàn)是積極的，但我們意識(shí)到，沒有足夠的時(shí)間來進(jìn)行全面的判斷。
通常，您做出體系結(jié)構(gòu)決策的真正后果只會(huì)在您做出決策后的幾年才顯現(xiàn)出來。我們已經(jīng)看到了一個(gè)項(xiàng)目，在這個(gè)項(xiàng)目中，一個(gè)對(duì)模塊化有強(qiáng)烈需求的優(yōu)秀團(tuán)隊(duì)構(gòu)建了一個(gè)整體式的架構(gòu)，并且這種架構(gòu)多年來一直在衰落。許多人認(rèn)為，由于服務(wù)邊界是明確的并且很難修補(bǔ)，因此微服務(wù)不太可能出現(xiàn)這種衰減。但是，直到我們看到足夠的系統(tǒng)和足夠的使用期限，我們才能真正評(píng)估微服務(wù)架構(gòu)的成熟程度。
人們肯定會(huì)期望微服務(wù)成熟度很差，這是有原因的。在進(jìn)行組件化的任何努力中，成功都取決于軟件適合組件的程度。很難確切地確定組件邊界應(yīng)該在哪里。進(jìn)化設(shè)計(jì)認(rèn)識(shí)到正確設(shè)置邊界的困難，因此容易重構(gòu)它們的重要性。但是，當(dāng)您的組件是具有遠(yuǎn)程通信的服務(wù)時(shí)，則重構(gòu)要比進(jìn)程內(nèi)庫困難得多?？绶?wù)邊界移動(dòng)代碼很困難，參與者之間的任何接口更改都需要協(xié)調(diào)，需要向后兼容，并且測試變得更加復(fù)雜。
我們的同事山姆·紐曼（Sam Newman）在2014年的大部分時(shí)間里都在寫一本書，該書記錄了我們構(gòu)建微服務(wù)的經(jīng)驗(yàn)。如果您想更深入地研究該主題，那么這應(yīng)該是您的下一步。
另一個(gè)問題是，如果組件組成不清晰，那么您要做的就是將復(fù)雜性從組件內(nèi)部轉(zhuǎn)移到組件之間的連接。這不僅可以解決復(fù)雜性問題，還可以將其轉(zhuǎn)移到不太明確且難以控制的地方。當(dāng)您查看小型，簡單組件的內(nèi)部而又缺少服務(wù)之間的混亂連接時(shí)，很容易想到事情會(huì)更好。
最后，還有團(tuán)隊(duì)合作能力的因素。技能更強(qiáng)的團(tuán)隊(duì)傾向于采用新技術(shù)。但是，對(duì)于技能嫻熟的團(tuán)隊(duì)來說，更有效的技術(shù)不一定適用于技能嫻熟的團(tuán)隊(duì)。我們已經(jīng)看到了許多技能水平較低的團(tuán)隊(duì)構(gòu)建凌亂的整體架構(gòu)的案例，但是花些時(shí)間來看看當(dāng)這種微服務(wù)發(fā)生這種混亂時(shí)會(huì)發(fā)生什么。一個(gè)糟糕的團(tuán)隊(duì)總是會(huì)創(chuàng)建一個(gè)糟糕的系統(tǒng)-在這種情況下，很難說微服務(wù)是減少混亂還是使其變得更糟。
我們聽到的一個(gè)合理的論據(jù)是，您不應(yīng)該從微服務(wù)架構(gòu)開始。取而代之的是 從整體開始，使其保持模塊化，一旦整體出現(xiàn)問題，將其拆分為微服務(wù)。（盡管 此建議并不理想，因?yàn)榱己玫倪M(jìn)程內(nèi)接口通常不是良好的服務(wù)接口。）
因此，我們對(duì)此持謹(jǐn)慎樂觀的態(tài)度。到目前為止，我們已經(jīng)對(duì)微服務(wù)風(fēng)格有足夠的了解，認(rèn)為這可能是 一條值得走的路。我們不能肯定地說到哪里去，但是軟件開發(fā)的挑戰(zhàn)之一是只能根據(jù)當(dāng)前必須掌握的不完善信息來做出決策。
腳注
1： 2011年5月在威尼斯附近的軟件架構(gòu)師研討會(huì)上討論了“微服務(wù)”一詞，以描述與會(huì)人員認(rèn)為這是他們中許多人最近探索的一種通用架構(gòu)風(fēng)格。2012年5月，同一小組決定將“微服務(wù)”作為最合適的名稱。James于2012年3月在克拉科夫的微服務(wù)-Java和Unix方式中以33rd學(xué)位的案例研究提出了其中一些想法 ，與Fred George差不多在同一時(shí)間。Netflix的Adrian Cockcroft將這種方法描述為“細(xì)粒度的SOA”，正如本文中提到的許多其他人（喬·沃恩斯，丹尼爾·特霍斯特·諾斯，埃文·博特徹和格雷厄姆·塔克利）一樣，在網(wǎng)絡(luò)規(guī)模上引領(lǐng)了這種風(fēng)格。
2： unilith一詞已被Unix社區(qū)使用了一段時(shí)間。它出現(xiàn)在Unix編程藝術(shù)中，描述了太大的系統(tǒng)。
3： 許多面向?qū)ο蟮脑O(shè)計(jì)人員，包括我們自己，在域驅(qū)動(dòng)設(shè)計(jì)的意義上將術(shù)語服務(wù)對(duì)象用于執(zhí)行與實(shí)體無關(guān)的重要過程的對(duì)象。這與本文中如何使用“服務(wù)”是一個(gè)不同的概念。可悲的是，“服務(wù)”一詞具有兩種含義，我們必須忍受一詞多義。
4： 我們認(rèn)為應(yīng)用程序是一種社會(huì)結(jié)構(gòu)，它將代碼庫，功能組和資金主體捆綁在一起。
5： 原始論文可以在Melvin Conway的網(wǎng)站上找到
6： 我們無法抗拒提及吉姆·韋伯（Jim Webber）的說法，即ESB代表“ Egregious Spaghetti Box”。
7： Netflix將鏈接明確化-直到最近才將其架構(gòu)風(fēng)格稱為細(xì)粒度的SOA。
8： 在規(guī)模極限時(shí)，組織經(jīng)常使用二進(jìn)制協(xié)議，例如protobufs。使用這些功能的系統(tǒng)仍具有智能端點(diǎn)，啞管道的特性，并且會(huì)在透明性 與規(guī)模之間進(jìn)行權(quán)衡。大多數(shù)網(wǎng)絡(luò)媒體資源，當(dāng)然也包括絕大多數(shù)企業(yè)，都不需要進(jìn)行權(quán)衡取舍-透明度可以是一個(gè)很大的勝利。
9： “ YAGNI”或“您不需要它”是XP的原則，并勸告您不要添加功能，除非您知道自己需要它們。
10： 我們斷言整體式語言是單一語言，這有點(diǎn)使我們感到困惑-為了在當(dāng)今的網(wǎng)絡(luò)上構(gòu)建系統(tǒng)，您可能需要了解JavaScript和XHTML，CSS，您選擇的服務(wù)器端語言，SQL和ORM方言。幾乎沒有一種語言，但是您知道我們的意思。
11：在2013年11月在Flowcon上發(fā)表的精彩演講中， Adrian Cockcroft特別提到了“開發(fā)人員自助服務(wù)”和“開發(fā)人員運(yùn)行他們編寫的內(nèi)容” 。
12： 我們?cè)谶@里有點(diǎn)不穩(wěn)定 顯然，在更復(fù)雜的拓?fù)渲胁渴鸶喾?wù)比部署單個(gè)整體要困難得多。幸運(yùn)的是，模式降低了這種復(fù)雜性-盡管仍然必須對(duì)工具進(jìn)行投資。
13： 實(shí)際上，Daniel Terhorst-North將此樣式稱為可替換組件體系結(jié)構(gòu)，而不是微服務(wù)。由于這似乎與某些特征有關(guān)，因此我們更喜歡后者。
14： 肯特·貝克（Kent Beck）在實(shí)現(xiàn)模式中著重指出了這一點(diǎn) 。
15： SOA幾乎不是這段歷史的根源 我記得當(dāng)本世紀(jì)初出現(xiàn)SOA術(shù)語時(shí)，有人說過“我們已經(jīng)這樣做了好幾年了”。一種說法是，這種樣式的根源是在企業(yè)計(jì)算的早期，COBOL程序通過數(shù)據(jù)文件進(jìn)行通信的方式。在另一個(gè)方向上，人們可能會(huì)說微服務(wù)與Erlang編程模型是一樣的東西，但適用于企業(yè)應(yīng)用程序上下文。
