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

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

本文在RisingStack’s Node.js Consulting & Development experience一文基礎上，介紹了構建和運維高可用的微服務架構系統中最常用的技術和架構模式。

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

微服務架構的風險

微服務架構將應用邏輯拆分成服務，服務之間通過網絡交互。由于是通過網絡調用，而不是在進程中調用，因此這給需要在多個物理和邏輯組件間進行協作的系統帶來了潛在的問題和復雜性。分布式系統變得越來越復雜，也導致網絡特定故障發生的可能性增大。 

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

優雅的服務降級

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

微服務故障獨立（理論上）

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

服務互相依賴，如果無故障轉移的邏輯，則會同時失效

變更管理

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

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

比如，國外域名 免費域名，當部署新的代碼或者修改配置時，應該分步將這些變更部署到服務實例群中的部分實例中，并且進行監控，如果發現關鍵指標出現問題則能自動進行回滾。

變更管理－回滾部署

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

回退代碼并不是壞事情。你不應該在生產環境中部署有問題的代碼，并且應該琢磨哪里出錯了。當必要時候應該果斷回退代碼，這越早越好。

健康檢查和負載均衡

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

我們可以通過外部觀察去判斷應用實例是否健康。你可以多次調用 

Get /health的端點（endpoint）或者通過自身服務的報告獲得相關信息。現在的 

服務發現解決方案會持續從實例中收集健康信息，并且設置負載均衡的路由，讓其只指向健康的實例組件。

自我修復

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