過去幾年來，“微服務(wù)架構(gòu)”這個術(shù)語出現(xiàn)了，它描述了一種將軟件應(yīng)用程序設(shè)計為可獨立部署的服務(wù)套件的特定方式。盡管這種架構(gòu)風(fēng)格沒有確切的定義，但圍繞業(yè)務(wù)能力，自動化部署，端點智能以及語言和數(shù)據(jù)的分散控制等方面存在著某些共同特征。
“微服務(wù)” - 在軟件架構(gòu)擁擠的街道上又一個新名詞。盡管我們的自然傾向是以輕蔑的眼光來傳遞這樣的東西，但這些術(shù)語描述了一種我們發(fā)現(xiàn)越來越吸引人的軟件系統(tǒng)風(fēng)格。我們已經(jīng)看到許多項目在過去幾年中都采用了這種風(fēng)格，迄今為止的結(jié)果是積極的，因此對于我們的許多同事來說，這正成為構(gòu)建企業(yè)應(yīng)用程序的默認風(fēng)格�？杀氖�，沒有太多的信息概述了微服務(wù)的風(fēng)格以及如何去做。
簡而言之，微服務(wù)架構(gòu)是一種將單應(yīng)用程序作為一套小型服務(wù)開發(fā)的方法，每種應(yīng)用程序都在其自己的進程中運行，并與輕量級機制（通常是HTTP資源的API）進行通信。這些服務(wù)是圍繞業(yè)務(wù)功能構(gòu)建的，可以通過全自動部署機制進行獨立部署。這些服務(wù)的集中化管理已經(jīng)是最少的，它們可以用不同的編程語言編寫，并使用不同的數(shù)據(jù)存儲技術(shù)。
微服務(wù)架構(gòu)
在開始介紹微服務(wù)風(fēng)格（microservice style）前，比較一下整體風(fēng)格（monolithic style）是很有幫助的：一個完整應(yīng)用程序（monolithic application）構(gòu)建成一個單獨的單元。企業(yè)應(yīng)用程序通常建立在三個主要部分中：一個客戶端用戶界面（由用戶計算機上的瀏覽器中運行的HTML頁面和JavaScript組成）數(shù)據(jù)庫（包括插入常見的通常是關(guān)系數(shù)據(jù)庫管理的多個表系統(tǒng)）和一個服務(wù)器端應(yīng)用程序。服務(wù)器端應(yīng)用程序?qū)⑻幚鞨TTP請求，執(zhí)行特定領(lǐng)域邏輯，通過數(shù)據(jù)庫進行檢索和更新數(shù)據(jù)，選擇并填充要發(fā)送到瀏覽器的HTML視圖。這個服務(wù)器端應(yīng)用程序是一個龐然大物 - 一個邏輯可執(zhí)行文件[2]。系統(tǒng)的任何更改都涉及構(gòu)建和部署新版本的服務(wù)器端應(yīng)用程序。
這樣的整體服務(wù)（monolithic server）是一種構(gòu)建系統(tǒng)很自然的方式。處理請求的所有邏輯都在一個進程中運行，允許您使用語言的基本功能將應(yīng)用程序劃分為類，函數(shù)和名稱空間。謹慎操作時，您可以在開發(fā)人員的筆記本電腦上運行和測試應(yīng)用程序，并使用部署通道來確保更改經(jīng)過適當(dāng)測試并部署到生產(chǎn)環(huán)境中。您可以通過在負載平衡器后面運行多個實例來橫向縮放整體。
單體式應(yīng)用程序可以取得成功，但越來越多的人會感到失望 - 尤其是隨著更多應(yīng)用程序被部署到云中。變更周期是連在一起的 - 對應(yīng)用程序的一小部分進行更改，需要重建和部署整個程序。隨著時間的推移，它通常很難保持良好的模塊化結(jié)構(gòu)，使得難以保持應(yīng)該：模塊內(nèi)的一個改動僅影響該模塊本身中。自適應(yīng)需要自適應(yīng)整個應(yīng)用程序，而不是它的一部分，這樣做需要更多資源。
微服務(wù)架構(gòu)
這些挫折引出了微服務(wù)架構(gòu)風(fēng)格：將應(yīng)用程序構(gòu)建為服務(wù)套件。除了服務(wù)是可獨立部署和可伸縮的事實之外，每個服務(wù)還提供了一個嚴(yán)格的模塊邊界，甚至允許用不同的編程語言編寫不同的服務(wù)。它們也可以由不同的團隊來管理。
我們并不是說微服務(wù)風(fēng)格是新穎的或創(chuàng)新的，它的根源至少可以追溯到Unix的設(shè)計原則。但我們確實認為，沒有足夠多的人考慮使用微服務(wù)架構(gòu)，如果他們使用了，那么許多軟件開發(fā)將會更好。
微服務(wù)體系結(jié)構(gòu)的特征
我們不能說對微服務(wù)架構(gòu)風(fēng)格有一個正式的定義，但是我們可以嘗試描述我們所看到的與“微服務(wù)”標(biāo)簽相符的架構(gòu)的共同特征。與任何概述共同特征的定義一樣，并不是所有的微服務(wù)架構(gòu)都具有所有的特征，但是我們確實期望大多數(shù)微服務(wù)架構(gòu)具有大多數(shù)特征。雖然我們的作者一直是這個相當(dāng)松散的社區(qū)的活躍成員，但我們的目的是嘗試描述我們在自己的工作中看到的東西，以及我們所知道的團隊的類似努力。特別地，我們并沒有給出一些符合要求的定義。
通過服務(wù)（Sevice）實現(xiàn)組件化
只要我們參與過軟件行業(yè)，這就存在一種期盼：通過將組件整合在一起來構(gòu)建系統(tǒng)，這與我們在現(xiàn)實世界中看待事物的方式非常相似。在過去的幾十年中，我們已經(jīng)見證了大部分語言平臺中常見庫的大量摘要所取得的巨大進步。在談及組件時，我們遇到了對組件構(gòu)成定義的難題。我們的定義是，組件是可獨立更換和升級的軟件單元。
微服務(wù)架構(gòu)一樣會用到各種庫，但這種架構(gòu)會把軟件給拆分成各種不同的服務(wù)來實現(xiàn)組件化。這里我們定義兩個重要的概念：庫(library) 指的是鏈接到程序的組件，通過本地函數(shù)調(diào)用來使用庫提供的功能；而服務(wù) (service) 是進程外的組件，通過網(wǎng)絡(luò)服務(wù)請求 (web service request) 或者遠程函數(shù)調(diào)用之類的機制來使用里面的功能。注意這和很多面向?qū)ο蟪绦蚶锓⻊?wù)對象的機制是不同的 [3]。
之所以在組件化的軟件里用服務(wù)，而不是庫，一個主要原因就是各個服務(wù)是可以獨立部署的。比如說，如果在同一個軟件 [4] 里用了多個庫，那么就算只是修改了其中一個，都會導(dǎo)致整個軟件要被重新部署；相反，如果用的是服務(wù)，那只需要重新部署修改過的就可以。然而，有個問題是，當(dāng)修改服務(wù)時，可能會把服務(wù)接口也給修改了，這樣一來，服務(wù)的調(diào)用者和開發(fā)者就得自己私下協(xié)調(diào)了。好的微服務(wù)架構(gòu)，就應(yīng)該盡量避免這種問題；非要修改服務(wù)契約的話，也得循序漸進，讓調(diào)用者有跡可循，不用私下協(xié)調(diào)。
使用服務(wù)作為組件的另一個后果是更顯式的組件接口。大多數(shù)語言都沒有很好的機制來定義顯式發(fā)布的接口。通常，只有文檔和規(guī)程可以防止客戶機破壞組件的封裝，從而導(dǎo)致組件之間的緊密耦合。通過使用顯式的遠程調(diào)用機制，服務(wù)可以更容易地避免這種情況。使用這樣的服務(wù)確實有缺點。遠程調(diào)用比進程內(nèi)調(diào)用更昂貴，因此遠程api需要粗粒度，這通常更難以使用。如果您需要更改組件之間的職責(zé)分配，那么當(dāng)您跨越流程邊界時，這種行為的移動就更加困難了。
我們可以觀察到服務(wù)映射到運行時進程，但這只是第一次近似。服務(wù)可能包括多個進程，這些進程將始終會一起開發(fā)和部署，例如應(yīng)用進程和服務(wù)所用到的數(shù)據(jù)庫。
根據(jù)服務(wù)能力進行管理
當(dāng)將大型應(yīng)用程序拆分為不同組件時，通常的管理側(cè)重于技術(shù)層，由技術(shù)層引領(lǐng)UI團隊、服務(wù)器端邏輯團隊和數(shù)據(jù)庫團隊的工作。當(dāng)團隊的這種生產(chǎn)線被隔離時，即使是簡單的改變也會引起跨團隊的項目耗時耗力。聰明的團隊將圍繞這一點進行優(yōu)化——僅把邏輯強加到他們所能觸及的任何方式中。換句話說，邏輯無處不在。這是Conway定律[5]的一個例子。
任何如設(shè)計系統(tǒng)（廣義定義）的組織，必將創(chuàng)造出一個設(shè)計，其設(shè)計結(jié)構(gòu)是組織的通信結(jié)構(gòu)的副本。-- Melvyn Conway, 1967
微服務(wù)架構(gòu)
在劃分層面，微服務(wù)方法是不同的，分解成圍繞業(yè)務(wù)能力所組織的服務(wù)。這些服務(wù)需要對該業(yè)務(wù)領(lǐng)域的軟件進行廣泛的實施，包括用戶界面、持久性存儲和任何外部協(xié)作。因此，團隊是跨職能的，包括開發(fā)所需的全部技能：用戶體驗、數(shù)據(jù)庫和項目管理。
微服務(wù)架構(gòu)
微服務(wù)是指開發(fā)一個單個小型的但有業(yè)務(wù)功能的服務(wù)，每個服務(wù)都有自己的處理和輕量通訊機制，可以部署在單個或多個服務(wù)器上。微服務(wù)也指一種種松耦合的、有一定的有界上下文的面向服務(wù)架構(gòu)。也就是說，如果每個服務(wù)都要同時修改，那么它們就不是微服務(wù)，因為它們緊耦合在一起；如果你需要掌握一個服務(wù)太多的上下文場景使用條件，那么它就是一個有上下文邊界的服務(wù)，這個定義來自DDD領(lǐng)域驅(qū)動設(shè)計。
相對于單體架構(gòu)和SOA，它的主要特點是組件化、松耦合、自治、去中心化，體現(xiàn)在以下幾個方面：
一組小的服務(wù)
服務(wù)粒度要小，而每個服務(wù)是針對一個單一職責(zé)的業(yè)務(wù)能力的封裝，專注做好一件事情。
獨立部署運行和擴展
每個服務(wù)能夠獨立被部署并運行在一個進程內(nèi)。這種運行和部署方式能夠賦予系統(tǒng)靈活的代碼組織方式和發(fā)布節(jié)奏，使得快速交付和應(yīng)對變化成為可能。
獨立開發(fā)和演化
技術(shù)選型靈活，不受遺留系統(tǒng)技術(shù)約束。合適的業(yè)務(wù)問題選擇合適的技術(shù)可以獨立演化。服務(wù)與服務(wù)之間采取與語言無關(guān)的API進行集成。相對單體架構(gòu)，微服務(wù)架構(gòu)是更面向業(yè)務(wù)創(chuàng)新的一種架構(gòu)模式。
獨立團隊和自治
團隊對服務(wù)的整個生命周期負責(zé)，工作在獨立的上下文中，自己決策自己治理，而不需要統(tǒng)一的指揮中心。團隊和團隊之間通過松散的社區(qū)部落進行銜接。
我們可以看到整個微服務(wù)的思想就如我們現(xiàn)在面對信息爆炸、知識爆炸是一樣的：通過解耦我們所做的事情，分而治之以減少不必要的損耗，使得整個復(fù)雜的系統(tǒng)和組織能夠快速的應(yīng)對變化。
我們?yōu)槭裁床捎梦⒎⻊?wù)呢？
"讓我們的系統(tǒng)盡可能快地響應(yīng)變化" - Rebecca Parson
讓我們的系統(tǒng)盡可能快地去響應(yīng)變化。其實幾十年來我們一直在嘗試解決這個問題。如果一定要在前面加個限制的話，那就是低成本的快速響應(yīng)變化。上世紀(jì)90年代Kent Beck提出要擁抱變化，在同期出現(xiàn)了諸多輕量級開發(fā)方法（諸如 XP、Scrum）；2001年敏捷宣言誕生，之后又出現(xiàn)了精益、看板等新的管理方式。如果說，這些是為了盡快的響應(yīng)變化，在軟件開發(fā)流程和實踐方面提出的解決方案，那么微服務(wù)架構(gòu)就是在軟件技術(shù)和架構(gòu)層面提出的應(yīng)對之道。
微服務(wù)架構(gòu)
微服務(wù)有多大?
雖然“微服務(wù)”已成為這種架構(gòu)風(fēng)格的流行名詞，但它的名稱確實導(dǎo)致了對服務(wù)規(guī)模的不當(dāng)關(guān)注，以及關(guān)于什么構(gòu)建“微”的爭論。在我們與微服務(wù)從業(yè)者的對話中，我們看到了一系列規(guī)模的服務(wù)。據(jù)報道最大的規(guī)模遵循Amazon提出的Two Pizza團隊理念（即整個團隊可以由兩個比薩餅喂飽），這意味著不超過十幾個人。在規(guī)模較小的規(guī)模上，我們已經(jīng)看到過如此的配置：一個六人團隊將支撐六種服務(wù)。這就導(dǎo)致了這樣一個問題：在這個大小范圍內(nèi)是否存在足夠大的差異，即每六人所負責(zé)的服務(wù)數(shù)目和每人負責(zé)的服務(wù)數(shù)目不應(yīng)該被集中在一個微服務(wù)標(biāo)簽下。目前我們認為將它們組合在一起會更好，但在我們進一步探索這種風(fēng)格時，我們肯定會改變想法的。
跨職能團隊負責(zé)構(gòu)建和操作每個產(chǎn)品，并將每個產(chǎn)品分成多個單獨的服務(wù)，通過消息總線進行通信。大型單塊應(yīng)用程序也可以圍繞業(yè)務(wù)功能進行模塊化，盡管這不是常見的情況。當(dāng)然，我們會敦促一個龐大的團隊構(gòu)建一個單一的應(yīng)用程序，以將自己與業(yè)務(wù)線分開。我們在這里看到的主要問題是，他們傾向于在太多的背景下組織。如果這個龐然大物跨越了許多模塊化的邊界，那么團隊的單個成員就很難將它們?nèi)谌氲剿麄兊亩唐谟洃浿小４送�，我們發(fā)現(xiàn)模塊化的代碼行需要大量的規(guī)程來執(zhí)行。服務(wù)組件所要求的更加明確的分離使得保持團隊界限變得更加容易。
產(chǎn)品不是項目
大多我們看到的應(yīng)用開發(fā)都使用一個項目模型：目標(biāo)就是將那些馬上就要完成的軟件的一部分交付出去。在軟件的完成時將它交付給一個后期運維組織，然后開發(fā)它的軟件項目組就被解散了。微服務(wù)倡導(dǎo)盡量避免這種模型，反而更傾向于另一個理念：一個團隊?wèi)?yīng)該在一個產(chǎn)品的整個生命周期都擁有它。與之相同的靈感來自于亞馬遜的“你創(chuàng)造它，你運維它”的理念，在那里一個開發(fā)團隊對產(chǎn)品中的軟件是完全負責(zé)的。這給開發(fā)者們帶來了日常聯(lián)系，讓他們知道他們的軟件在產(chǎn)品中表現(xiàn)如何，同時由于他們必須要承擔(dān)一些支持負擔(dān)，也增加了他們與用戶的聯(lián)系。
產(chǎn)品心態(tài)，與業(yè)務(wù)能力掛鉤。與其將軟件看作是一組要完成的功能，還存在一種持續(xù)的關(guān)系，其中的問題是軟件如何幫助其用戶提高業(yè)務(wù)能力。我們沒有理由不使用單一的應(yīng)用程序，但是服務(wù)的粒度越小，就越容易創(chuàng)建服務(wù)開發(fā)人員和用戶之間的個人關(guān)系。
智能端點和啞管道。
在構(gòu)建不同流程之間的通信結(jié)構(gòu)時，我們已經(jīng)看到了許多產(chǎn)品和方法，它們強調(diào)將大量的智慧投入到通信機制本身中。一個很好的例子是企業(yè)服務(wù)總線(Enterprise Service Bus, ESB)， ESB產(chǎn)品通常包括用于消息路由、編排、轉(zhuǎn)換和應(yīng)用業(yè)務(wù)規(guī)則的復(fù)雜設(shè)施。
微服務(wù)和SOA
當(dāng)我們已經(jīng)討論了微服務(wù)之后，一個常見問題為：它是不是就是我們在十年前見到的面向服務(wù)的體系架構(gòu)（SOA，Service Oriented Architecture）。因為微服務(wù)風(fēng)格與SOA所支持的一些主張非常像，這一點是有價值的。然而問題就是SOA意味著太多不同的東西，而且一般因為對ESB在用于集成大型應(yīng)用時的關(guān)注，當(dāng)大多我們遇到名為“SOA”的東西的時候，它與我們在本文所描述的風(fēng)格完全不同。尤其我們已經(jīng)看到了很多面向服務(wù)的拙劣的實踐——從在ESB[6]中總是將復(fù)雜隱藏起來的趨勢，到失敗的花費數(shù)百萬而沒有價值的多年計劃，再到總是抑制變化的集中管理模式，導(dǎo)致有時很難看到過去的這些問題。
當(dāng)然，微服務(wù)社區(qū)中許多在用的技術(shù)都是由大型組織開發(fā)者的集成服務(wù)經(jīng)驗發(fā)展而來。讀者容錯模式就是其中的一個例子。web的使用已經(jīng)為此做出了貢獻，使用簡單協(xié)議是另一種方法，它就是由這些經(jīng)驗衍生出來的——一種遠離中心標(biāo)準(zhǔn)的反應(yīng)，這些標(biāo)準(zhǔn)已經(jīng)達到了它如今所具有的一種復(fù)雜度，直白的說，相當(dāng)壯觀。（當(dāng)你需要一個實體來管理你的眾多實體的時候，你就知道你遇到大麻煩了。）與SOA的共同表現(xiàn)形式已經(jīng)讓微服務(wù)主張徹底拒絕被打上SOA的標(biāo)簽，盡管其他人認為微服務(wù)就是SOA的一種形式[7]，也許在面向服務(wù)方面是沒有錯的。無論哪種方式，SOA都意味著不同的東西，這意味著使用一個術(shù)語來更加簡明的定義這種架構(gòu)風(fēng)格是有必要的。
微服務(wù)社區(qū)相對更傾向于另一種方法：智能終端和無聲管道。使用微服務(wù)搭建的應(yīng)用旨在盡可能的分解和凝聚——他們擁有他們自己的業(yè)務(wù)邏輯，而且更像一個傳統(tǒng)Unix印象中的過濾器——接收請求，應(yīng)用合適的邏輯，并產(chǎn)生響應(yīng)。它們使用簡單REST協(xié)議而非復(fù)雜協(xié)議，就像WS-Choreography或者BPEL或者使用中央工具配置。
這兩種協(xié)議使用的比較多的是使用源API和輕量級消息的HTTP請求-響應(yīng)[8]。第一個最好的表達是
屬于web，而不落后于web --Ian Robinson
微服務(wù)團隊使用萬維網(wǎng)(以及很大程度上，Unix)構(gòu)建的原則和協(xié)議。開發(fā)者或操作人員可以通過較少的努力來緩存經(jīng)常使用的資源。
第二種常用方法是通過輕量級總線傳遞消息。選擇的基礎(chǔ)設(shè)施素來愚蠢（愚蠢是因為僅作為消息路由器）——像RabbitMQ或ZeroMQ一樣不僅僅是提供可靠的異步架構(gòu)來簡單實現(xiàn)——智能仍然存在于生產(chǎn)和消費信息的終點上；在服務(wù)中。
在整體結(jié)構(gòu)中，正在執(zhí)行中的組件通過方法調(diào)用或函數(shù)調(diào)用進行通信。將一個巨大的框架改成一個微服務(wù)框架時遇到的最大的問題在于改變通信方式。從內(nèi)存的方法調(diào)用到RPC的簡單轉(zhuǎn)換會使通信性能變差。相反，你需要用粗粒度方法來替換細粒度的通信。
分散治理
集中化治理的后果之一是在單一技術(shù)平臺上進行標(biāo)準(zhǔn)化的趨勢。經(jīng)驗表明，這種方法是壓縮的——不是每個問題都是釘子，不是每個解決方案都是錘子。我們更喜歡使用合適的工具來做這個工作，而單一的應(yīng)用程序可以在一定程度上利用不同的語言，這并不常見。將monolith的組件拆分為服務(wù)，我們在構(gòu)建它們的時候有一個選擇。要使用節(jié)點。js到standup一個簡單的報告頁面?就去做吧。一個特別接近實時的組件的c++ ?很好。您想要換一種不同的數(shù)據(jù)庫風(fēng)格，以便更好地適應(yīng)一個組件的讀取行為?我們有技術(shù)來重建他。
當(dāng)然，僅僅因為你可以做點什么，并不意味著你應(yīng)該這樣做 - 但是用這種方式劃分你的系統(tǒng)意味著你有可選項。構(gòu)建微服務(wù)的團隊也更喜歡采用不同的標(biāo)準(zhǔn)方法。相對于使用一套寫在紙上定義好的標(biāo)準(zhǔn)，他們更偏向于這種想法：生產(chǎn)有用的工具，而其他開發(fā)人員可以用此工具來解決他們所面臨的類似問題。這些工具通常是從實施中獲得的，并在更廣泛的群體中共享，有時但不完全使用內(nèi)部開源模型。既然git和github已經(jīng)成為了可選的事實上的版本控制系統(tǒng)，開源實踐正變得越來越普遍。
Netflix組織就是遵循這一理念的一個很好的例子。 貢獻出不僅實用，更重要的是經(jīng)過實踐檢驗的代碼來作為庫，來激勵其他開發(fā)者以類似的方式解決類似的問題。如果需要，還留以余地去選擇應(yīng)用不同的方法。 共享庫傾向于關(guān)注常見的問題，包括數(shù)據(jù)存儲，進程間通信以及我們將進一步討論的架構(gòu)自動化。
對于微服務(wù)社區(qū)來說，虛耗并不是特別受人關(guān)注。但這并不意味著社區(qū)不重視服務(wù)契約。恰恰相反，往往有更多的人在關(guān)注。只不過他們在尋求不同的方式來管理這些契約。例如Tolerant Reader(容錯讀取)和Consumer-Driven Contracts（消費驅(qū)動契約）模式就通常應(yīng)用于微服務(wù)。這些都會幫助服務(wù)契約去獨立演進。應(yīng)用消費驅(qū)動契約作為你構(gòu)建的一部分會提升信心，并對你的服務(wù)是否正常運行提供快速反饋。事實上據(jù)我們所知，澳大利亞的一支團隊正在推動以消費驅(qū)動契約為導(dǎo)向來搭建新服務(wù)。他們使用簡單的能夠允許他們自己定義服務(wù)契約的工具。在新服務(wù)代碼被創(chuàng)建之前，這就變成了自動構(gòu)建的一部分。這樣構(gòu)建出來的服務(wù)恰好滿足了契約 – 這是一種在創(chuàng)建新軟件時避免“YAGNI”[9]難題的很得當(dāng)方法。這些圍繞著它們發(fā)展而來的技術(shù)和工具會通過減少服務(wù)之間的時間耦合，以此來限制對中央契約管理的需要。
多語言，多選項
JVM作為平臺的發(fā)展僅僅是一個最新的在通用平臺上實現(xiàn)多語言的例子。數(shù)十年來，為了利用更高層次抽象的優(yōu)勢，更高級的語言已經(jīng)被普遍采用。正如在更底層的水平上，降低到硬件層面去編寫性能敏感的代碼一樣。然而，許多大型系統(tǒng)并不需要這個層面的性能優(yōu)化，也不需要DSL和更高層面的抽象（這讓我們感到非常沮喪）。相反，大型系統(tǒng)通常是單一語言，并且傾向于限制使用的技術(shù)數(shù)量[10]。
也許去中心化管理的最高境界就是被Amazon普及推廣的構(gòu)建/運行精神。團隊的職責(zé)是構(gòu)建軟件的各個方面，包括7*24全天候運維。雖然這種水平的責(zé)任要求轉(zhuǎn)變絕對不是規(guī)范，但我們看到越來越多的公司將責(zé)任交給開發(fā)團隊。 Netflix是另一家采用這種風(fēng)格的組織[11]。每天凌晨3點被傳呼機吵醒無疑是一種強大的動力，逼迫你在編寫代碼時更加注重代碼質(zhì)量。這些創(chuàng)意點都與傳統(tǒng)的集中化管理模式漸行漸遠。
去中心化的數(shù)據(jù)管理
數(shù)據(jù)管理的去中心化有許多不同的方式。在最抽象的層次上，這意味著世界的概念模型將在系統(tǒng)之間有所不同。在跨大型企業(yè)集成時，這是一個常見問題，客戶的銷售視圖與支持視圖不同。在銷售視圖中，一些被稱為客戶的東西可能根本不會出現(xiàn)在支持視圖中。那些有可能具有不同屬性和(更糟糕)的共同屬性，其語義略有不同。
經(jīng)過戰(zhàn)斗考驗和執(zhí)行的標(biāo)準(zhǔn)
微服務(wù)團隊傾向于避開企業(yè)架構(gòu)組所制定的嚴(yán)格執(zhí)行標(biāo)準(zhǔn)，但他們樂于使用，甚至推廣使用開放標(biāo)準(zhǔn)，如 HTTP、ATOM 和其他微格式，這是一個兩分法。
除了關(guān)于概念模型的去中心化決策之外，微服務(wù)還分散了數(shù)據(jù)存儲的決策。盡管單體式應(yīng)用程序在存儲持久性數(shù)據(jù)時更偏向單一的邏輯數(shù)據(jù)庫，但企業(yè)通常更傾向于在各種應(yīng)用程序中使用單一數(shù)據(jù)庫 —— 這些決策中的很多都是由供應(yīng)商的與許可授權(quán)相關(guān)的商業(yè)模式進行驅(qū)動的。微服務(wù)更偏向于讓每個服務(wù)管理自己的數(shù)據(jù)庫，或是相同數(shù)據(jù)庫技術(shù)的不同實例，或是完全不同的數(shù)據(jù)庫系統(tǒng) —— 一種叫做 Polyglot Persistence 的方法。你可以在單體應(yīng)用中使用 polyglot persistence，但在微服務(wù)中它使用得更頻繁。
微服務(wù)架構(gòu)
在微服務(wù)中對數(shù)據(jù)責(zé)任去中心化對于管理更新有一定影響。處理更新的通用方法是在更新多個資源時使用事務(wù)來保證一致性。這種方法經(jīng)常在單體式應(yīng)用中使用。
使用像這樣的事務(wù)有助于保持一致性，但是會增加顯著的時間耦合，這是在多個服務(wù)中都有問題的。分布式事務(wù)非常難以實現(xiàn)，因此微服務(wù)架構(gòu)強調(diào)服務(wù)之間的無事務(wù)性協(xié)調(diào)，并明確認識到：一致性可能只是最終的一致性，而問題則通過補充操作來處理。選擇以這種方式來管理不一致性對于許多開發(fā)團隊來說是一個新的挑戰(zhàn)，但它往往符合業(yè)務(wù)慣例。通常業(yè)務(wù)容忍一定程度的不一致性，以便快速響應(yīng)需求，同時采取某種逆過程來處理錯誤。只要修正錯誤的成本低于業(yè)務(wù)失敗所帶來的損失，這種折中是值得的。
基礎(chǔ)設(shè)施自動化
基礎(chǔ)設(shè)施自動化技術(shù)在過去幾年中發(fā)生了巨大變化 - 特別是云和AWS的發(fā)展降低了構(gòu)建、部署和運行微服務(wù)的操作復(fù)雜性。由微服務(wù)構(gòu)建的許多產(chǎn)品或系統(tǒng)都是由具有持續(xù)交付及其先驅(qū)（持續(xù)集成）方面有豐富經(jīng)驗的團隊所構(gòu)建的。以這種方式構(gòu)建軟件的團隊廣泛使用基礎(chǔ)設(shè)施自動化技術(shù)。這在下面所展示的構(gòu)建管道中進行了說明。
微服務(wù)架構(gòu)
鑒于這不是一篇關(guān)于持續(xù)交付的文章，我們將僅在此提請注意幾個關(guān)鍵功能。我們希望盡可能多的信心使我們的軟件能夠工作，所以我們進行了大量的自動化測試。推動可工作的軟件“上”流水線意味著我們可以自動部署到每個新環(huán)境中。
輕松做正確的事情
我們發(fā)現(xiàn)由持續(xù)交付和部署而導(dǎo)致自動化程度提高的一個副作用是創(chuàng)建有用的工具來幫助開發(fā)人員和操作人員。用于創(chuàng)建工件、管理代碼庫、創(chuàng)建簡單服務(wù)或添加標(biāo)準(zhǔn)監(jiān)測和日志記錄的工具現(xiàn)在很常見。網(wǎng)絡(luò)上最好的例子可能是Netflix的Netflix開源工具系列，但也有其他的包括我們廣泛使用的Dropwizard。
一個單體式應(yīng)用程序?qū)⑼ㄟ^這些環(huán)境非常愉快地構(gòu)建、測試、推動。事實證明，一旦你對單體式應(yīng)用的生產(chǎn)路徑做了投入，那么部署更多的應(yīng)用程序似乎不再那么可怕。請記住，CD 的目標(biāo)之一就是讓部署變得枯燥，所以無論它是一個還是多個應(yīng)用程序，只要它仍然枯燥，那就是并不重要的[12]。
我們看到團隊頻繁使用的基礎(chǔ)設(shè)施自動化的另一個領(lǐng)域是管理生產(chǎn)環(huán)境中的微服務(wù)。與我們之前的斷言相反，只要部署是很枯燥的，單體式和微服務(wù)之間沒有太大的區(qū)別，每個部門的運營環(huán)境可能會有驚人的不同。
微服務(wù)架構(gòu)
圖 6：模塊部分通常有區(qū)別
為失敗而設(shè)計
使用服務(wù)作為組件的結(jié)果是，應(yīng)用程序需要被設(shè)計，以便它們能夠容忍服務(wù)的失敗。任何服務(wù)調(diào)用都可能由于供應(yīng)商的無法使用而失敗，必須盡可能為客戶優(yōu)雅地響應(yīng)。與單塊設(shè)計相比，這是一個缺點，因為它引入了額外的復(fù)雜性來處理它。其結(jié)果是，微服務(wù)團隊不斷地反思服務(wù)失敗如何影響用戶體驗。Netflix的Simian Army在工作日中引入了服務(wù)的失敗，甚至是數(shù)據(jù)中心，以測試應(yīng)用程序的彈性和監(jiān)控。
斷路器及生存環(huán)境預(yù)備碼
斷路器在 釋放(Release It!，備注書名）一書中與其他如Bulkhead和Timeout等模式一起用于構(gòu)建通訊軟件是至關(guān)重要。這點Netflix博客 文章做了大量的解釋。
這種在生產(chǎn)中的自動化測試將足以讓大多數(shù)運營團隊不寒而栗。這并不是說單一架構(gòu)不具備復(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)指標(biāo)（例如每分鐘收到多少訂單）。 語義監(jiān)控可以提供一個預(yù)警系統(tǒng)，從而引導(dǎo)開發(fā)團隊進行跟蹤和調(diào)查。
這對微服務(wù)架構(gòu)尤其重要，因為微服務(wù)對編排和事件協(xié)作的偏好會導(dǎo)致出現(xiàn)緊急行為。 盡管許多權(quán)威人士稱贊偶然事件出現(xiàn)的價值，但事實是，緊急行為有時可能是一件壞事。 監(jiān)控對迅速發(fā)現(xiàn)不良緊急行為至關(guān)重要，只有發(fā)現(xiàn)才可能進行修復(fù)。
同步調(diào)用是有害的
每當(dāng)您在服務(wù)之間有多個同步調(diào)用時，您就會遇到停機的乘法效應(yīng)。簡單地說，就是當(dāng)您系統(tǒng)停機時間成為單個組件的停機時間時。您面臨一個選擇，使您的調(diào)用變成異步或管理停機時間。在www.guardian.co.uk上，他們已經(jīng)在新平臺上實現(xiàn)了一個簡單的規(guī)則——每個用戶在Netflix上的一個同步呼叫，他們的平臺重新設(shè)計的API已經(jīng)在API結(jié)構(gòu)中建立了異步性。我們可以構(gòu)建一個像微服務(wù)一樣透明的單體——事實上，它們應(yīng)該是這樣的。不同之處在于，您絕對需要知道在不同進程中運行的服務(wù)何時斷開。在同一過程中使用庫，這種透明性就不太可能有用了。
微服務(wù)團隊希望看到針對每個服務(wù)的精密的監(jiān)控和日志記錄設(shè)置，例如面板顯示增加/停止?fàn)顟B(tài)以及各種與運營和業(yè)務(wù)相關(guān)的指標(biāo)。有關(guān)線路斷路器的狀態(tài)、當(dāng)前吞吐量和延遲的詳細信息是我們經(jīng)常遇到的其他示例。
Evolutionary Design 演進式設(shè)計
微服務(wù)從業(yè)者通常擁有進化設(shè)計背景，并將服務(wù)分解視為下一步的工具，以使應(yīng)用程序開發(fā)人員能夠控制其應(yīng)用程序中的更改，并且不會降低變更速度。變更控制并不一定意味著變更減少 - 通過正確的態(tài)度和工具，你可以對軟件進行頻繁、快速且控制良好的變更。
無論您何時試圖將軟件系統(tǒng)分解為組件，您都面臨著如何分割這些組件的決定 - 我們決定切割應(yīng)用程序的原則是什么？組件的關(guān)鍵屬性是獨立替換和可升級性的概念[13] - 這意味著我們可以尋找重寫組件而不影響其協(xié)作者的點。事實上許多微服務(wù)群都明確預(yù)計許多服務(wù)將被廢棄，而不是長遠發(fā)展。
衛(wèi)報網(wǎng)站就是一個很好的例子，它是作為一個整體設(shè)計和構(gòu)建的應(yīng)用程序，但它一直在微服務(wù)方面發(fā)展。網(wǎng)站的核心仍然是個龐然大物，但他們更喜歡通過構(gòu)建使用龐然大物的 API 的微服務(wù)來添加新功能。這種方法對于固有臨時性的功能特別有用，例如，專門處理體育賽事的頁面。使用快速開發(fā)語言可以將網(wǎng)站的這一部分快速組合起來，并在活動結(jié)束后將其移除。我們在一家金融機構(gòu)看到了類似的方法，即在市場中存在機會的時候添加新服務(wù)并在幾個月甚至幾周后丟棄它們。
強調(diào)可替換性是模塊化設(shè)計中的一般原則的特別情況，其原則是為了在整個模式變化中驅(qū)動模塊化 [14]。你可以在相同模塊并且相同時間內(nèi)做修改。系統(tǒng)修改的那部分應(yīng)很少出現(xiàn)在不同且相互依賴的服務(wù)中。如總是兩個服務(wù)一并修改，那說明你需要要合并服務(wù)了。
將組件并于服務(wù)使得發(fā)布計劃具有更大的顆粒度。單一服務(wù)下，任何修改都需重新發(fā)布整個應(yīng)用，而微服務(wù)架構(gòu)的情況下，只需要重新發(fā)布修改的服務(wù)，所以微服務(wù)能簡化并加快發(fā)布流程。但缺點是需要擔(dān)心修改某個服務(wù)使得其消費者中斷。傳統(tǒng)整合的方案是盡量使用版本來解決這個問題，但微服務(wù)偏好使用只是將版本作為下策。將服務(wù)設(shè)計得盡可能適應(yīng)修改，也可以避免許多版本。
微服務(wù)未來？
我們寫這篇文章的主要目的是解釋微服務(wù)的主要思想和原則。通過花這么多時間，我們清楚的認為，微服務(wù)架構(gòu)風(fēng)格是一個重要的思想——一個為企業(yè)應(yīng)用認真思考的思想。我們最近使用這個風(fēng)格構(gòu)建了幾個系統(tǒng)，并認識了其他一些使用和支持這種風(fēng)格的人。
我們知道有人在某種程度上開創(chuàng)了這種架構(gòu)風(fēng)格，包括亞馬遜、Netflix、衛(wèi)報、英國政府?dāng)?shù)字服務(wù)、realestate.com.au、Forwardh和comparethemarket.com。2013年的巡回會議上充斥著公司的例子，這些公司正在轉(zhuǎn)向微服務(wù)類型——包括Travis CI。此外，有很多組織長期以來一直在做我們所說的微服務(wù)，但沒有使用這個名字。（通常標(biāo)記為SOA——盡管如此，SOA有許多矛盾的形式。[15]）
盡管有這些積極的體驗，但我們并不認為我們可以確信微服務(wù)是軟件架構(gòu)的未來方向。雖然迄今為止，相對于單體式應(yīng)用程序，我們的體驗是積極的，但我們意識到一個事實：要做出充分的判斷所過去的時間并不是很充足。
微服務(wù)架構(gòu)
我們的同事Sam Newman在2014年的大部分時間里寫了一本關(guān)于構(gòu)建微服務(wù)并記錄我們體驗的書。如果你想深入探討這個話題，這應(yīng)該是你的下一個目標(biāo)。
通常你做的架構(gòu)決策只會在幾年之后才真正顯現(xiàn)出效果。我們看到過一個項目，項目擁有一個好的團隊，并強烈渴望模塊化，但構(gòu)建出來的巨大架構(gòu)，在這些年已經(jīng)衰敗了。一些人相信微服務(wù)不會出現(xiàn)這種衰敗現(xiàn)象，因為服務(wù)界限是明確的并且很難修復(fù)。然而，直到我們看到了足夠多足夠老的系統(tǒng)，我們?nèi)詿o法正確的評價微服務(wù)框架怎樣算成熟。
有人期望微服務(wù)的成熟度不佳是有原因的。在組件化的任何努力中，成功需要依賴軟件如何很好的適應(yīng)組件。很難確切的指出組件的邊界在哪。進化設(shè)計意識到獲取正確的邊界是困難的，因此能輕易的重構(gòu)他們是重要的。但是，當(dāng)你的組件通過遠程通信來服務(wù)時，重構(gòu)起來比在進程中的庫更困難。通過服務(wù)邊界移動代碼是困難的，參與者之間需要協(xié)調(diào)每一個接口變化，需要添加向后兼容層，并且測試會變得更加復(fù)雜。
如果組件不能干凈編排那將引起其他問題，這時你所做的所有事情就是轉(zhuǎn)移復(fù)雜度，將組件內(nèi)部的連接轉(zhuǎn)移到組件之間。這不僅僅是移動復(fù)雜度，轉(zhuǎn)移的地方將更不清晰，且更難控制。當(dāng)你查看一個簡單的小組件內(nèi)部時，你會很容易想到事情是好的，而忽略了服務(wù)之間的混亂連接。最后，還有團隊技能的因素。新技術(shù)往往會被更熟練的團隊所采用。但是對于一個更熟練的團隊來說，一種更有效的技術(shù)不一定對那些不太熟練的團隊起作用。我們已看到很多不太熟練的團隊構(gòu)建混亂的單一架構(gòu)的案例，但是，當(dāng)這種情況發(fā)生在微服務(wù)中時，需要時間來看看會發(fā)生什么。糟糕的團隊總會創(chuàng)建一個差勁的系統(tǒng)——但很難判斷微服務(wù)是否能減少了這種情況下的混亂或是否能使情況變得更糟。
我們聽到的一個合理的論點是你不應(yīng)該從微服務(wù)架構(gòu)開始，而應(yīng)從單一（龐大）的項目開始，一旦這一項目遇到問題，就拆分模塊，劃分不同的微服務(wù)。（雖然這個建議并不理想，因為一個好的進程接口通常不是一個好的服務(wù)接口。）所以我謹慎樂觀地寫下了這篇文章。到目前為止，我們已看到足夠多文章認為微服務(wù)是一條值得走的路。我不能確定最終如何，但這是軟件開發(fā)的一個挑戰(zhàn)——只能根據(jù)你目前必須掌握的不完美的信息做出決定。
簡法一：為什么不把這坨該死的代碼拆開？每當(dāng)代碼打包發(fā)布的時候，一個上百兆的部署文件讓我深感憂慮。我的擔(dān)憂并非空穴來風(fēng)，一次又一次的瓶頸讓我驗證了這該死的擔(dān)憂。面對這樣一個龐然怪物，就算無數(shù)個“通宵”也削減不了我對它的力不從心，“分解”成為了我當(dāng)時的唯一想法。因為“分解”是我們?nèi)祟愄幚韽?fù)雜的一種常識化手段，它能讓我把一條復(fù)雜的數(shù)學(xué)題逐一破解，也能讓我把一項艱巨的任務(wù)分而治之，更讓我看到了人類從“自給自足”到“專業(yè)化分工”的魅力。
專業(yè)化分工
簡法二：除了MVC，我還能如何選擇？無可否認，MVC是互聯(lián)網(wǎng)時代的“王者榮耀”，但隨著移動互聯(lián)網(wǎng)的發(fā)展，我試圖尋找另一種更適合多端消費的服務(wù)化抽象模式。如果我只是單純地把沉重的SSH切換到當(dāng)時較為流行且輕量的SSM，其實并沒有太多本質(zhì)上的區(qū)別。我們當(dāng)時的這種“服務(wù)化”分解其實更多地想給“消費者”提供一種輕量化、標(biāo)準(zhǔn)化、抽象化的服務(wù)支撐，如果要用專業(yè)術(shù)語來形容，可能SOA（面向服務(wù)架構(gòu)）更為貼切。但ESB和WS作為當(dāng)時SOA的主流實現(xiàn)和工具，它們的“沉重”讓我望而卻之。
服務(wù)化分解
簡法三：繼續(xù)找合適的“輪子”還是“自造”輪子？有想法對于一個年輕人來說再正常不過，但把能把這想法付諸實現(xiàn)還是需要一定的付出、勇氣和機遇。才疏學(xué)淺的我在當(dāng)時并未看到“服務(wù)化”的普及，選擇一款成熟且契合自己思路的工具也不是一件容易的事，又或許是我內(nèi)心當(dāng)時那份熱血澎湃的重構(gòu)欲望在日益膨脹。幸運的是，開放的平臺給了我足夠開放的心態(tài)、空間和信心去打造屬于我們的“輪子”。
欲望驅(qū)動
簡法四：輪子的思考“簡單”是我們設(shè)計的首要原則，因為簡單賦予了靈活，提高了效率、增強了可控，而且自主研發(fā)的約束范圍也會遠遠大于工具的選擇，為“簡化”創(chuàng)造了無限可能。開源工具的思考邊界可能更多地會集中在技術(shù)引擎和技術(shù)規(guī)范二者之間，因為它必須抽象在應(yīng)用場景之下才能達到一定的通用性，所以開源的考慮會非常周到且功能齊全，但會存在一定的“臃腫”和“個性化”局限，這也是我們“自造輪子”的重要考慮之一，但更重要的還是從本質(zhì)出發(fā)。
系統(tǒng)邊界思考
簡法五：技術(shù)引擎的思考“服務(wù)化”的設(shè)計理念會把應(yīng)用根據(jù)“領(lǐng)域邊界”分解成一個個獨立的“服務(wù)進程”。其實，劃分后的應(yīng)用系統(tǒng)跟操作系統(tǒng)還是有幾分相似之處，服務(wù)好比進程，線程好比服務(wù)的業(yè)務(wù)執(zhí)行單元。事實上，它們在運行過程中就是這樣一種上下層的對應(yīng)關(guān)系。
服務(wù)與進程
線程的執(zhí)行是基于棧幀的“跳進跳出”，而業(yè)務(wù)的執(zhí)行是基于“流程”的線性執(zhí)行�！傲鞒獭笔菢I(yè)務(wù)執(zhí)行的線性抽象，對“流程”的分解、定義、組織和管控恰恰就是我們對“技術(shù)引擎”設(shè)計的關(guān)鍵所在。
技術(shù)引擎流程抽象過程
簡法六：技術(shù)引擎的實現(xiàn)對流程的抽象并非想說明我們“輪子”的獨特之處，而是嘗試對流程本質(zhì)進行重新理解。因為本質(zhì)，所以無論SSH還是SSM都能作為該抽象流程的一種實現(xiàn)。但是，我們要做的是嘗試重新透過現(xiàn)象看本質(zhì)，然后基于本質(zhì)之上一磚一瓦重新打造出我們“服務(wù)化”理念的另一種實現(xiàn)。
系統(tǒng)層次分解思考
一張白紙的背后可能隱藏著數(shù)十道工序的運作，我們“輪子”每磚瓦的堆砌同樣少不了對系統(tǒng)從始至終、由里到外的無數(shù)次觀察和思考。每一次的重構(gòu)都千差萬別，每一次的放棄都異常掙扎，但每一次都更接近于自己的內(nèi)心。
服務(wù)技術(shù)引擎結(jié)構(gòu)
除了服務(wù)交互協(xié)議層外（Service Interaction protocal），我們把框架總體劃分為框架服務(wù)（Framework Service）、基礎(chǔ)服務(wù)（Base Service）和業(yè)務(wù)服務(wù)（Business Service）三個層次，各層次服務(wù)都是由定時器模塊組件（Timer）、初始化模塊組件（Initor）、銷毀模塊組件（Destoryer）、業(yè)務(wù)前置模塊組件（ SB_Module）、業(yè)務(wù)后置模塊組件（SA_Module）以及業(yè)務(wù)實現(xiàn)模塊組件（Services）組成。從結(jié)構(gòu)上看，每一層的服務(wù)都內(nèi)嵌于它上一層的服務(wù)之中，讓各種模塊組件形成了一種高約定、標(biāo)準(zhǔn)化、插拔式的切面規(guī)則。
微服務(wù)是什么？快速理解微服務(wù)架構(gòu) |
收藏
分享
支持
反對
提升卡
置頂卡
沉默卡
喧囂卡
變色卡
千斤頂
照妖鏡