本文首先介紹微服務(wù)架構(gòu)存在的風(fēng)險，然后針對如何避免微服務(wù)架構(gòu)的故障，提出了多種有效的微服務(wù)架構(gòu)中的方法和技術(shù)，其中例如服務(wù)降級、變更管理、健康檢查和修復(fù)、斷路器、限流器等。

微服務(wù)架構(gòu)通過定義明確的服務(wù)邊界，能有效地隔離故障。 和其他分布式系統(tǒng)一樣，微服務(wù)在網(wǎng)絡(luò)、硬件和應(yīng)用層上都會存在更多的問題。由于服務(wù)之間是互相依賴，因此任何組件都可能出錯導(dǎo)致用戶不能訪問。為盡可能減少部分中斷帶來的影響，我們需要構(gòu)建容錯能力強的服務(wù)，以從容應(yīng)對發(fā)生的某些中斷。

本文在RisingStack’s Node.js Consulting & Development experience一文基礎(chǔ)上，介紹了構(gòu)建和運維高可用的微服務(wù)架構(gòu)系統(tǒng)中最常用的技術(shù)和架構(gòu)模式。

如果讀者不熟悉上文中的模式，那并沒什么大礙。構(gòu)建可靠的系統(tǒng)不是一踞而就的。

微服務(wù)架構(gòu)的風(fēng)險

微服務(wù)架構(gòu)將應(yīng)用邏輯拆分成服務(wù)，服務(wù)之間通過網(wǎng)絡(luò)交互。由于是通過網(wǎng)絡(luò)調(diào)用，而不是在進程中調(diào)用，因此這給需要在多個物理和邏輯組件間進行協(xié)作的系統(tǒng)帶來了潛在的問題和復(fù)雜性。分布式系統(tǒng)變得越來越復(fù)雜，也導(dǎo)致網(wǎng)絡(luò)特定故障發(fā)生的可能性增大。 

相比傳統(tǒng)應(yīng)用龐大的結(jié)構(gòu)，微服務(wù)架構(gòu)最大的一個優(yōu)點是團隊能獨立地設(shè)計、開發(fā)和部署各自的服務(wù)。團隊能掌控各自服務(wù)的整個生命周期。這也意味者團隊無法控制服務(wù)的依賴關(guān)系，因為這些依賴的服務(wù)可能是由其他團隊管理。在微服務(wù)架構(gòu)體系下，我們要牢記提供的服務(wù)由于是其他人控制，因此可能會由于發(fā)布、配置、和其他變更等原因，從而導(dǎo)致服務(wù)暫時不可用，而且組件之間互相獨立。 

優(yōu)雅的服務(wù)降級

微服務(wù)架構(gòu)最大的優(yōu)點之一就是當(dāng)組件出現(xiàn)故障時，能隔離這些故障并且能做到優(yōu)雅地服務(wù)降級。比如，在圖片分享應(yīng)用中，當(dāng)出現(xiàn)故障時，用戶可能無法上傳圖片，但他們依然能瀏覽、編輯和分享已上傳的圖片。 

微服務(wù)故障獨立（理論上）

在大多數(shù)情況下，是很難實現(xiàn)上圖這種優(yōu)雅地服務(wù)降級的，因為在分布式環(huán)境下，應(yīng)用都是互相依賴的，開發(fā)者需要實現(xiàn)若干錯誤處理的邏輯（該部分在本文稍后部分討論）去應(yīng)對短暫的故障和中斷。

服務(wù)互相依賴，如果無故障轉(zhuǎn)移的邏輯，則會同時失效

變更管理

Google的網(wǎng)站可靠性團隊發(fā)現(xiàn)大概70%的故障都是由于變更而引起的。當(dāng)對服務(wù)進行修改時—例如發(fā)布代碼的新版本或者改變一些配置，則總會有可能引起故障或者引入新的錯誤。

在微服務(wù)架構(gòu)中，服務(wù)是互相依賴的。這就是為什么你需要減少故障并且盡可能降低它們的負(fù)面影響。為了應(yīng)對變更帶來的問題，你可以實施變更策略管理并且實現(xiàn)其自動回滾。

比如，國外域名 免費域名，當(dāng)部署新的代碼或者修改配置時，應(yīng)該分步將這些變更部署到服務(wù)實例群中的部分實例中，并且進行監(jiān)控，如果發(fā)現(xiàn)關(guān)鍵指標(biāo)出現(xiàn)問題則能自動進行回滾。

變更管理－回滾部署

另一個解決方案是運行兩套生產(chǎn)環(huán)境。部署的時候只部署變更的應(yīng)用到其中一套環(huán)境中，并且在驗證了新發(fā)布的版本符合預(yù)期后，才將負(fù)責(zé)均衡的流量指向新的應(yīng)用，這種方法稱為“藍(lán)-綠發(fā)布”或者“紅-黑發(fā)布”。

回退代碼并不是壞事情。你不應(yīng)該在生產(chǎn)環(huán)境中部署有問題的代碼，并且應(yīng)該琢磨哪里出錯了。當(dāng)必要時候應(yīng)該果斷回退代碼，這越早越好。

健康檢查和負(fù)載均衡

因為故障或部署、自動擴展等原因，服務(wù)實例會不停啟動，重新啟動及停止。這使得服務(wù)暫時或一直停用。為了避免發(fā)生這些問題，在負(fù)載均衡中應(yīng)該在路由中設(shè)置忽略這些實例，因為它們無法為子系統(tǒng)或用戶提供服務(wù)。 

我們可以通過外部觀察去判斷應(yīng)用實例是否健康。你可以多次調(diào)用 

Get /health的端點（endpoint）或者通過自身服務(wù)的報告獲得相關(guān)信息?，F(xiàn)在的 

服務(wù)發(fā)現(xiàn)解決方案會持續(xù)從實例中收集健康信息，并且設(shè)置負(fù)載均衡的路由，讓其只指向健康的實例組件。

自我修復(fù)

自我修復(fù)能幫助恢復(fù)應(yīng)用。我們討論下當(dāng)應(yīng)用遇到崩潰狀態(tài)后，如何通過相關(guān)的步驟去自我修復(fù)。在大多數(shù)情況下，是通過外部系統(tǒng)監(jiān)控實例的狀態(tài)，當(dāng)服務(wù)出現(xiàn)故障一段時間后則會重啟服務(wù)。在大多數(shù)情況下，自我修復(fù)的功能是相當(dāng)有用的，國外域名 免費域名，然而，在某些情況下由于不斷地重啟服務(wù)會帶來相關(guān)的問題。例如當(dāng)服務(wù)過載或者數(shù)據(jù)庫連接超時，則會導(dǎo)致應(yīng)用不能反饋正確的服務(wù)健康狀態(tài)。