本文首先介紹微服務(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ù)是互相依賴的。這就是為什么你需要減少故障并且盡可能降低它們的負面影響。為了應(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ù)期后，才將負責(zé)均衡的流量指向新的應(yīng)用，這種方法稱為“藍-綠發(fā)布”或者“紅-黑發(fā)布”。
回退代碼并不是壞事情。你不應(yīng)該在生產(chǎn)環(huán)境中部署有問題的代碼，并且應(yīng)該琢磨哪里出錯了。當(dāng)必要時候應(yīng)該果斷回退代碼，這越早越好。