健康檢查和負載均衡
因為故障或部署、自動擴展等原因，服務實例會不停啟動，重新啟動及停止。這使得服務暫時或一直停用。為了避免發(fā)生這些問題，在負載均衡中應該在路由中設置忽略這些實例，因為它們無法為子系統(tǒng)或用戶提供服務。
我們可以通過外部觀察去判斷應用實例是否健康。你可以多次調(diào)用
Get /health的端點（endpoint）或者通過自身服務的報告獲得相關信息。現(xiàn)在的
服務發(fā)現(xiàn)解決方案會持續(xù)從實例中收集健康信息，并且設置負載均衡的路由，讓其只指向健康的實例組件。
自我修復
自我修復能幫助恢復應用。我們討論下當應用遇到崩潰狀態(tài)后，如何通過相關的步驟去自我修復。在大多數(shù)情況下，是通過外部系統(tǒng)監(jiān)控實例的狀態(tài)，當服務出現(xiàn)故障一段時間后則會重啟服務。在大多數(shù)情況下，自我修復的功能是相當有用的，然而，在某些情況下由于不斷地重啟服務會帶來相關的問題。例如當服務過載或者數(shù)據(jù)庫連接超時，則會導致應用不能反饋正確的服務健康狀態(tài)。
對于一些場景-比如數(shù)據(jù)庫鏈接丟失，這個時候?qū)崿F(xiàn)高級的自我修復功能是頗為棘手的。在這種情況下，需要為應用添加額外的邏輯去處理這些特例，并且讓外部系統(tǒng)知道服務的實例不需要立即重新啟動。
故障轉(zhuǎn)移緩存（Failover Caching）
因為網(wǎng)絡問題和系統(tǒng)中的變更，服務通常會出現(xiàn)故障。然而，這些故障中斷大多是暫時的，這要歸功于自我修復和高級負載平衡的功能，我們應該找到一個解決方案，能使服務即使在出現(xiàn)故障的時候也能工作。這就是故障轉(zhuǎn)移緩存（Failover Caching），它能幫助為我們的應用提供必需的數(shù)據(jù)。
失效轉(zhuǎn)移緩存通常使用兩個不同的過期日期：其中更短的日期指示在正常情況下能使用緩存的時間，而更長的一個日期則指示在故障失效的時候，能使用緩存中的數(shù)據(jù)時長。
故障轉(zhuǎn)移緩存
特別需要提醒的是，只有當提供過時的數(shù)據(jù)比沒有數(shù)據(jù)更好的情況下，才能使用故障轉(zhuǎn)移緩存。
要設置緩存和故障轉(zhuǎn)移緩存，可以在HTTP中使用標準響應頭。
例如，使用max-age頭可以指定某個資源為新資源的最大時間（譯者注：意即設定max-age后，瀏覽器不再發(fā)送請求到服務器）。可以使用stale-if-error 頭去確定在出現(xiàn)故障的情況下，從緩存獲取資源的時間長短。
現(xiàn)在的CDN和負載均衡器提供了各種緩存和故障轉(zhuǎn)移的解決方案，但是你也可以在你的公司中建立一個共享庫，其中包括這些標準的可靠性解決方案。
重試邏輯（Retry Logic）
在某些情況下，我們可能無法緩存數(shù)據(jù)，或者想對數(shù)據(jù)進行變更，但是操作最終失敗了。在這種情況下，我們就可以選擇重試操作，因為我們可以預期資源將在一段時間后恢復，或者負載均衡會將請求發(fā)送到健康的實例上。
你應該小心地為應用程序和客戶端添加重試邏輯，因為更大量的重試操作可能會使事情變得更糟，甚至阻止應用程序恢復。
在分布式系統(tǒng)中，微服務系統(tǒng)重試可能會觸發(fā)多個其他請求或重試操作，并導致級聯(lián)效應。為減少重試帶來的影響，你應該減少重試的數(shù)量，并使用指數(shù)退避算法（exponential backoff algorithm）來持續(xù)增加重試之間的延遲時間，直到達到最大限制。
由于重試是由客戶端（瀏覽器，其他微服務等）發(fā)起的，并且客戶端在處理請求前后是不知道草走失敗的，你應該為你的應用程序提供冪等處理能力。例如，當你重試購買操作時，不應該向客戶收兩次錢。給每個事務使用唯一的冪等鍵（idempotency-key）是解決重試問題的方法。
限流器和負載開關（Rate Limiters and Load Shedders）