保證系統能穩定地運作在生産環境是第一要務，就算是服務品質下降，隻要仍在工作，那就是萬幸。
常見服務問題
-
服務逾時
依賴的第三方服務因為某種不可抗力逾時了？資料庫慢查詢拖垮了整個資料庫？
-
服務錯誤
某個服務挂了？
-
服務負載高
突然陡增的通路量？
解決方法
-
限時
針對服務逾時，可以通過逾時控制保證接口的傳回，可以通過設定逾時時間為1s，盡快傳回結果，因為大多數情況下，接口逾時一方面影響使用者體驗，一方面可能是由于後端依賴出現了問題，如負載過高，機器故障等。某個網際網路公司曾經說，當系統故障時，fail fast。
-
fallback
有些情況下，即使服務出錯，對使用者而言，也希望是透明的，無感的，設定一些fallback，做一些服務降級，保證使用者的體驗，即使這個服務實際上是挂掉的，傳回内容是空的或者是舊的，在此故障期間，程式員能趕緊修複，對使用者幾乎沒有造成不良體驗。
-
電路熔斷
這裡的電路熔斷是對于後端服務的保護，當錯誤、逾時、負載上升到一定的高度，那麼負載再高下去，對後端來說肯定是無法承受，好像和電路熔斷一樣，這三個因素超過了門檻值，用戶端就可以停止對後端服務的調用，這個保護的措施，幫助了運維人員能迅速通過增加機器和優化系統，幫助系統度過難關。
工具
Hystrix能保護用戶端，服務降級，它的dashboard上有一句智語，defend your app，确實，當後端程式能對異常，逾時，錯誤等進行處理，那麼用戶端能獲得的資料能更加穩定統一，同時它也是對後端服務的保護，hystrix有上述的電路熔斷機制和使用者可以自定義fallback，對服務限時等功能。
hystrix運作流程可見How it works
以建構一個對内部RPC調用的HystrixCommand為例:
- 建構一個HystrixCommand用于RPC調用，設定逾時時間為1s，fallback為傳回空資料
- 如果緩存打開，結果優先從緩存中擷取
- 如果電路被熔斷，嘗試fallback
- 如果并發量超過限制，嘗試fallback
- 不然，運作實際的RPC調用，如果調用失敗或者逾時，嘗試fallback
根據實際情況設定
hystrix的逾時時間，fallback，并發量都可以根據需要封裝的指令進行設定，可以說非常靈活，根據自己的具體業務進行合适的設定，能優化使用者體驗。
例如：文章清單API依賴的服務逾時，可以通過服務降級拉取緩存中的舊資料進行傳回，雖然即時性稍遜，但是起碼使用者能讀到幾分鐘前的文章，在此期間，趕緊修複問題。