如何管理微服務失敗？

Question

比方說，我有幾個微服務（REST API），問題是，如果一個服務是無法訪問的（我們稱之爲服務「A」）將其發送給服務「A」將被保存在臨時數據庫中的數據。服務完成後，數據將再次發送。 問題： 1.我應該每10秒鐘創建一次服務「A」服務來知道服務工作嗎？或者是否可以通過任務隊列來完成？有什麼建議麼？

Answer 1

輪詢是浪費帶寬。你想使用一個事務性的隊列。

擲所有出站隊列中的消息，並有一些其他的進程來處理消息。

這將如何工作 - 後您的過程從隊列中讀取，並試圖發送到REST服務：

• 如果它工作，提交事務（隊列）
• 如果不起作用，不要犯。開始延遲（分鐘，秒 - 你最清楚），直到你再次從隊列中讀取。

Answer 2

有多個維度對您的問題。首先，您需要考慮使用提供彈性的基礎架構並使用self healing。這意味着您要部署容器集羣，所有容器均包含您的服務A.現在，您可以在服務前使用負載平衡器或API網關來分配呼叫/加載。它還會定期檢查您的服務的健康狀況。當它檢測到容器沒有正確響應時，它可以殺死容器並啓動另一個容器。這可以通過一個容器的基礎設施，如kubernetes /泊塢窗羣等

現在，這並不保護丟失任何請求提供。如果容器發生故障，那麼在故障與下一次健康檢查之間仍然會有很短的時間，因爲請求可能無法提供。在許多應用程序中，這是可以接受的，客戶端將重新請求並擊中另一個（健康容器）。如果您的應用程序要求絕對不會丟失請求，則必須將請求緩存在例如API網關中，並確保其保留到服務完成之前（也稱爲Circuit Breaker）。 Netflix Zuul和Hystrix就是一個示例技術。使用這種內置容錯的關守可以進一步提高彈性。作爲一個方面說明 - 使用API​​網關還可以解決中央認證/授權，路由和監控問題。

的另一種方法來添加彈性/解耦是使用快速流/消息隊列，如Apache卡夫卡，用於記錄所有傳入消息，並且具有準備的消息處理器處理他們時。然後，訣竅是隻在您的請求完全投放時將消息標記爲已處理。這也有助於在由於服務無法實時處理大量請求而導致出現故障的情況下（Asynchronous Decoupling with Cache）。

Answer 3

您可以使用斷路器模式，例如，來自netflix的hystrix斷路器。

有可能在超時或者當服務調用失敗或難以接近打開斷路器基。

Answer 4

服務可用時「A」應該解僱「就緒」事件。只聽那個，然後重新發送你的請求。