Hystrix：定製電路斷路器和恢復邏輯

Question

我剛剛閱讀Hystrix指南，並試圖圍繞默認斷路器和恢復期如何操作，然後如何定製其行爲。顯然，如果電路跳閘，Hystrix將自動調用命令的getFallBack()方法;這我瞭解。但是首先要考慮的是什麼標準？理想情況下，我想嘗試多次提供支持服務（例如，最多3次嘗試），然後再考慮服務處於離線/不健康狀態並斷開斷路器。 我怎麼能實現這一點，並在哪裏？

但我想如果我重寫默認斷路器，我還必須重寫任何機制處理默認恢復期。如果某後備服務下山的時候，可能有以下幾個原因之一：

• 有
• 這項服務是部署錯誤客戶端和服務器之間的網絡中斷，使得它不能返回有效的迴應客戶
• 客戶端部署與這使得它無法發送有效的請求到服務器
• 有些怪異，瞬時服務打嗝的（也許是服務做了重大的垃圾回收等）
錯誤
• 等

在大多數情況下，恢復期僅等待N秒，然後再次嘗試是不夠的。如果該服務存在缺陷，或者有人在數據中心中拉出了一些網絡電纜，我們將總是從該服務中失敗。只有在少數情況下，客戶服務機構纔會自動自我修復，而無需人爲干預。

所以我想我的下一個問題是局部的，但我想這主要是「如何自定義默認的恢復週期策略？」：「如何使用蝟當服務已關閉通知DEVOPS和需要人工干預「

Answer 1

基本上有四大原因蝟調用備用方法：異常，超時太多並行請求，或在前面的呼叫過於許多例外。

如果返回代碼或從服務接收到的異常表明重試有意義，您可能需要在run（）方法中重試。

在您的回退方法中，您可能會在發生超時時重試 - 當發生太多並行請求或太多異常時，再次調用同一服務通常沒有意義。

還問如何通知devops：您應該連接監測系統Hystrix，調查斷路器的狀態和成功和失敗的呼叫比率。您可以使用提供的metrics publishers，JMX或使用Hystrix的API編寫您自己的適配器。我已經爲Riemann和Zabbix在tutorial I prepared中編寫了兩個適配器;你會爲此添加幾行代碼。

本教程還有一個示例應用程序和一個加載驅動程序來嘗試一些場景。

Br， Alexander。