微服務(wù)極大的改變了服務(wù)端引擎的架構(gòu)方式。微服務(wù)不是一個(gè)單一的巨型的用來(lái)托管應(yīng)用程序所有業(yè)務(wù)邏輯的代碼庫(kù)，而是反映了分布式系統(tǒng)模型，在該模型中，一組應(yīng)用程序組件協(xié)同工作來(lái)滿足業(yè)務(wù)需求。通過(guò)遵循十項(xiàng)基本的微服務(wù)最佳實(shí)踐，你可以實(shí)現(xiàn)一個(gè)高效的微服務(wù)生態(tài)系統(tǒng)，從而避免不必要的架構(gòu)復(fù)雜性。

微服務(wù)架構(gòu)的收益

當(dāng)從單體應(yīng)用正確的遷移到微服務(wù)架構(gòu)的時(shí)候，可以獲得以下收益：

1. 你可以根據(jù)自己的意愿選擇一門語(yǔ)言開(kāi)發(fā)微服務(wù)，按照自己的節(jié)奏獨(dú)立發(fā)布它，并獨(dú)立擴(kuò)展。
2. 組織中的不同團(tuán)隊(duì)可以獨(dú)立的擁有自己特定的微服務(wù)，并且隨著并行開(kāi)發(fā)以及重用的增加，產(chǎn)品發(fā)布的時(shí)間會(huì)更快。
3. 可以更好的隔離故障，因?yàn)榘l(fā)生在特定微服務(wù)中的錯(cuò)誤會(huì)在對(duì)應(yīng)的服務(wù)中被處理掉，因此不會(huì)影響到生態(tài)系統(tǒng)中的其他服務(wù)。

但是，如果在構(gòu)建微服務(wù)時(shí)未遵循正確的原則，則最終可能會(huì)陷入像糾纏在一起的意大利面一樣的狀態(tài)。

這讓維護(hù)變得非常困難，因?yàn)檫@需要不同的團(tuán)隊(duì)一起協(xié)作來(lái)做變動(dòng)，發(fā)布或者實(shí)現(xiàn)容錯(cuò)。

充分利用微服務(wù)是一門科學(xué)并且需要一些刻意練習(xí)。以下微服務(wù)最佳實(shí)踐和設(shè)計(jì)原則將幫助你構(gòu)建松散耦合，分布式和優(yōu)化的微服務(wù)，以實(shí)現(xiàn)最佳價(jià)值。

10個(gè)微服務(wù)最佳實(shí)踐

1.單一責(zé)任原則

就像代碼中的類一樣，它僅僅在單個(gè)原因情況下改變，微服務(wù)也是采用類似的方式建模。構(gòu)建可能會(huì)改變一個(gè)以上的業(yè)務(wù)這種臃腫的服務(wù)是一個(gè)壞的實(shí)踐。

例如：你正在構(gòu)建用于訂購(gòu)披薩的微服務(wù)。你可以基于功能構(gòu)建下面這些組件，諸如InventoryService，OrderService，PaymentService，UserProfileService，DeliveryNotificationService等。InventoryService僅僅有獲取或更新披薩種類或配料庫(kù)存相關(guān)的API，同樣的，其他也只會(huì)提供對(duì)應(yīng)功能的API。

2.獨(dú)立的數(shù)據(jù)存儲(chǔ)

如果你的所有微服務(wù)都共享一個(gè)數(shù)據(jù)庫(kù)，這就違背了使用微服務(wù)的目的。對(duì)這個(gè)數(shù)據(jù)庫(kù)的任何的改變或者故障都會(huì)影響使用該數(shù)據(jù)庫(kù)的所有微服務(wù)。根據(jù)微服務(wù)的需要選擇正確的數(shù)據(jù)庫(kù)，定制化基礎(chǔ)設(shè)施以及對(duì)應(yīng)數(shù)據(jù)的存儲(chǔ)，并且讓你的服務(wù)獨(dú)占它。理想情況下，任何需要訪問(wèn)該數(shù)據(jù)的其他微服務(wù)只能通過(guò)擁有寫權(quán)限的微服務(wù)提供的API來(lái)訪問(wèn)。

3.使用異步通信實(shí)現(xiàn)松散耦合

為了避免構(gòu)建出一個(gè)緊密耦合的組件網(wǎng)格（mesh），可以考慮在微服務(wù)之間使用異步通信。

a.對(duì)依賴的服務(wù)異步調(diào)用，如下例子。

例如：有一個(gè)服務(wù)A依賴服務(wù)B的例子。當(dāng)服務(wù)B返回響應(yīng)消息，服務(wù)A再返回成功給調(diào)用服務(wù)A的調(diào)用者。如果調(diào)用者對(duì)服務(wù)B的內(nèi)容不關(guān)心，那么服務(wù)A可以異步調(diào)用服務(wù)B，并且這個(gè)時(shí)候可以立即返回成功給調(diào)用者。

b.一個(gè)更好的選擇是在微服務(wù)通信之間使用事件機(jī)制。你的微服務(wù)可以發(fā)布一個(gè)事件消息到消息總線上，可以用來(lái)通知一個(gè)狀態(tài)的改變或者一個(gè)失敗事件，并且任何對(duì)該事件感興趣的微服務(wù)都可以獲得該消息然后做出相應(yīng)的處理。

例如：上面提到的披薩訂單系統(tǒng)中，當(dāng)客戶的訂單被接收到或者訂單已經(jīng)完成以及運(yùn)輸?shù)臓顟B(tài)消息都可以使用異步通信給客戶發(fā)送通知消息。通知服務(wù)可以監(jiān)聽(tīng)訂單提交的消息事件然后將相應(yīng)的通知推送給客戶。

4.使用熔斷器快速實(shí)現(xiàn)故障容錯(cuò)

如果你的微服務(wù)依賴于另一個(gè)系統(tǒng)來(lái)提供響應(yīng)，并且該系統(tǒng)需要很長(zhǎng)時(shí)間才會(huì)響應(yīng)，那么你的總體響應(yīng)SLA將會(huì)受到影響。為了避免這種場(chǎng)景并且快速做出響應(yīng)，你需要遵循的一個(gè)簡(jiǎn)單的微服務(wù)最佳實(shí)踐是使用熔斷器來(lái)使外部的調(diào)用超時(shí)，然后返回一個(gè)默認(rèn)響應(yīng)或者錯(cuò)誤。熔斷器模式可以參考最下面的引用。這種方式可以隔離故障服務(wù)，而不會(huì)導(dǎo)致級(jí)聯(lián)故障，可以讓你的服務(wù)保持在健康的狀態(tài)。你可以選擇使用流行的產(chǎn)品，比如Netflix開(kāi)發(fā)的 Hystrix 。這要比使用HTTP CONNECT_TIMEOUT和READ_TIMEOUT設(shè)置更好，因?yàn)樗粫?huì)啟動(dòng)超出配置范圍的其他線程。

5.通過(guò)API網(wǎng)關(guān)代理微服務(wù)請(qǐng)求

相比于系統(tǒng)中的每個(gè)微服務(wù)都單獨(dú)提供API授權(quán)，請(qǐng)求/相應(yīng)日志以及限流功能，使用一個(gè)單獨(dú)API網(wǎng)關(guān)做這些事情會(huì)更有價(jià)值。調(diào)用你微服務(wù)的客戶端可以連接到API網(wǎng)關(guān)而不是直接調(diào)用微服務(wù)接口。這種方式可以讓你的微服務(wù)避免做那些額外的調(diào)用，并且微服務(wù)內(nèi)部URL可以被隱藏，這可以讓你更靈活的從API網(wǎng)關(guān)重定向流量到一個(gè)微服務(wù)的更新版本。當(dāng)允許第三方訪問(wèn)你的微服務(wù)時(shí)，那么更有必要使用這種方式，因?yàn)槟憧梢栽谡?qǐng)求到達(dá)微服務(wù)之前對(duì)傳入流量進(jìn)行限流以及拒絕來(lái)自API網(wǎng)關(guān)的未授權(quán)請(qǐng)求。你也可以選擇一個(gè)單獨(dú)的外部網(wǎng)關(guān)，讓它可以接收外部網(wǎng)絡(luò)的流量。

6.確保API變更向后兼容

你可以安全的對(duì)API進(jìn)行變更并且快速的發(fā)布它們，只要這些改變不影響已有的調(diào)用者。一種可能的選項(xiàng)是通知你的調(diào)用者，讓他們通過(guò)集成測(cè)試來(lái)對(duì)做出的變更進(jìn)行驗(yàn)證。但是，這種代價(jià)會(huì)比較高，因?yàn)樗幸蕾図?xiàng)都需要在一個(gè)環(huán)境中排隊(duì)，這會(huì)使你的協(xié)調(diào)工作變慢。一個(gè)更好的選項(xiàng)是對(duì)你的API使用合約測(cè)試。你的API消費(fèi)者對(duì)API提供預(yù)期響應(yīng)結(jié)果的合約。作為API提供者的你可以集成這些合約測(cè)試作為你構(gòu)建的一部分并且這些可以安全的保證重大的API變更。消費(fèi)者可以測(cè)試你發(fā)布的存根（stubs）作為他們構(gòu)建的一部分。這種方式可以讓你通過(guò)獨(dú)立測(cè)試合約變更來(lái)更快速的發(fā)布產(chǎn)品。

7.版本化微服務(wù)重大變更

不可能讓變更總是保持向后兼容。當(dāng)你做了一個(gè)重大的變更的時(shí)候，同時(shí)需要繼續(xù)支持老的接口，這時(shí)候可以暴露一個(gè)新版本的接口。消費(fèi)者可以在方便的時(shí)候選擇新的版本。但是有太多版本的API對(duì)于維護(hù)相應(yīng)的代碼人來(lái)說(shuō)會(huì)是一場(chǎng)噩夢(mèng)。因此，有一種規(guī)范的方法是通過(guò)和客戶端一起協(xié)作或在內(nèi)部將流量重新路由到較新的版本，從而棄用較舊的版本。

8.使用專用基礎(chǔ)設(shè)施托管微服務(wù)

你已經(jīng)開(kāi)發(fā)出了滿足所有檢查的最好的微服務(wù)，但是使用了一個(gè)很差的托管平臺(tái)，那么最終的效果依然會(huì)表現(xiàn)的很差。將你的微服務(wù)基礎(chǔ)設(shè)施與其他組件隔離可以實(shí)現(xiàn)故障隔離和最佳性能。隔離微服務(wù)依賴的組件基礎(chǔ)設(shè)施也同樣重要。

例如：上面披薩訂單的案例中，庫(kù)存微服務(wù)使用庫(kù)存數(shù)據(jù)庫(kù)。使用專用的托管機(jī)器不僅對(duì)于庫(kù)存微服務(wù)很重要，而且對(duì)于庫(kù)存數(shù)據(jù)庫(kù)同樣也很重要。

9.創(chuàng)建獨(dú)立的發(fā)布通道

你的微服務(wù)需要有一個(gè)單獨(dú)的發(fā)布通道，這個(gè)通道不和你所在組織中的其他組件關(guān)聯(lián)。這樣的話你就不會(huì)和別人有沖突以及浪費(fèi)和多個(gè)團(tuán)隊(duì)協(xié)調(diào)的時(shí)間。

10.建立組織效率

盡管微服務(wù)給你提供了獨(dú)立開(kāi)發(fā)和發(fā)布的自由，但是對(duì)于跨領(lǐng)域關(guān)注（cross cutting concerns）來(lái)說(shuō)，某些標(biāo)準(zhǔn)還是需要遵循的，這樣才不會(huì)讓每個(gè)團(tuán)隊(duì)都花費(fèi)時(shí)間為這些問(wèn)題創(chuàng)建獨(dú)特的解決方案。這在諸如微服務(wù)分布式架構(gòu)中是非常重要的，在這種架構(gòu)中，你需要能夠連接難題（puzzle）中的所有部分才能看清全局。因此，對(duì)于API安全，日志聚合，監(jiān)控，API文檔，秘鑰管理，配置管理，分布式追蹤等，企業(yè)級(jí)解決方案是必須要有的。

***

通過(guò)遵循這些微服務(wù)最佳實(shí)踐，你可以獲得一個(gè)松散耦合，分布式以及獨(dú)立的微服務(wù)系統(tǒng)，同時(shí)你可以獲得本文開(kāi)頭列出的微服務(wù)架構(gòu)的真正好處。