管理來賓可執行文件依賴性-內部Service Fabric

Question

我們最近決定開始使用本地Service Fabric，並且遇到了“依賴性”問題。

我們有幾個來賓可執行文件，它們之間具有依賴性，如果不重新啟動它們就無法從重新啟動它們依賴的服務中恢復。

一個清楚的例子：

在下面的圖表中，服務B依賴於服務A。如果服務A遇到意外錯誤並重新啟動，則服務B將進入“錯誤”狀態（不會報告給光纖網）。 這意味着服務B盡管處於錯誤狀態，但仍將報告OK健康狀態。

我們正在考慮以下方面的解決方案：

提出一個獨立的服務，該服務監視群集中所有副本/分區/應用程序的運行狀況事件，並包含整個依賴關系樹。

當服務的健康狀態更改時，它將重新啟動其直接依賴關系，這將導致事件的多米諾骨牌效應->重新啟動，直到重置整個子樹為止（如下面的“事件”->“操作”流程圖所示）。

問題是healthReport事件不會在短時間內發送（這意味着我的整個系統無法正常工作，而且幾分鍾后我也不知道）。 我將監視運行狀況，但是我確實需要了解歷史記錄（即使該狀況現在處於健康狀態，也並不意味着它之前沒有處於錯誤狀態）。

另一個問題是事件可以在任何服務級別（副本/分區）彈出，並且需要我匯總所有事件。

我真的很感激此事。 對於這個問題，我也完全持開放態度，即使這是完全相反的方向。

Answer 1

通常，可以通過在服務之間的通信邊界處引入容錯功能來避免服務中的級聯故障。 實現此目的的一些策略：

• 為失敗的操作引入重試，之間有一定的延遲。 延遲之間的時間可能成倍增長。 如果您當前在服務之間進行大量的遠程過程調用（RPC）風格的通信，則這是一個易於實現的選項。 如果您的依存服務重新啟動的時間不長，這可能會非常有效。 Polly是一個著名的實現重試的庫。

• 使用斷路器來關閉與失敗服務的通信。 在這個比喻中，在正常通信的兩個服務之間形成了閉路。 斷路器監視通信。 如果它檢測到一定數量的通信失敗，則會“斷開”電路，導致進一步的通信立即失敗。 然后，斷路器將定期查詢發送到故障服務以檢查其運行狀況，並在故障服務開始運行后關閉電路。 這比重試策略要復雜得多，因為您有責任防止開路導致服務崩潰，並負責確定構成健康服務的內容。 Polly還支持斷路器

• 使用隊列在服務之間形成完全異步的通信。 將出站操作排隊到服務B中的A，而不是直接從服務B與A進行通信。在其自己的線程中處理隊列-不允許通信失敗逃逸到隊列處理器。 您還可以向服務A添加入站隊列，以從服務B的出站隊列接收消息，以將消息處理與網絡完全隔離。 這可能是最持久的，也是最復雜的，因為它需要與RPC完全不同的體系結構，並且您還必須決定如何處理反復失敗的消息。 您可以立即重試失敗的消息，在延遲后將它們發送到隊列的后面，將它們發送到無效信件集合以進行手動處理，或者完全刪除該消息。 由於您使用的是來賓可執行文件，因此沒有足夠的可靠集合來幫助完成此過程，因此，如果您決定采用這種方式，那么像RabbitMQ這樣的第三方解決方案可能會很有用。