服務結構應用程序失敗行爲

我只是在本地測試服務結構。我測試了許多故障情況，但其中一個我無法驗證。節點運行良好時SF的行爲如何，但應用程序崩潰了？例如，我有無狀態的Web API，並且在單個請求後它失敗並關閉（幾乎不可能，但它只是假設）。 SF應該知道它，並且在下一次請求同一節點時，它應該重定向請求，以支持其他節點中託管的相同應用程序類型，直到應用程序不再啓動爲止？我對嗎？在有狀態它應該做同樣的事情，而不是重定向到其他節點它應該使用副本？服務結構應用程序失敗行爲

我嘗試模擬使用重啓ServiceFabricDeployedCodePackage這個例子，但它可能重新啓動太快，我無法驗證我的假設 - 我得到超時。

來源

2017-03-01 tom

假設服務結構會將請求重定向到服務通常是不正確的，除非您使用內置的反向代理服務器（您會知道是否使用它，因爲您需要構建特定的請求URL辦法）。

假設您未使用內置的反向代理服務器，那麼您的服務將在IP：端口端點上彼此直接連接並進行通信。服務結構不在請求路徑中。服務結構僅提供服務發現。

SF檢測到進程崩潰。您也可以從服務代碼中報告錯誤。在這些情況下，SF將重新啓動崩潰的進程或報告錯誤的副本。它們可能會在不同的節點上重新啓動。有狀態的服務副本將幾乎總是故障切換到另一個活動輔助節點可以提升爲主節點的節點。如果服務是無狀態的，客戶端負責解析新的服務端點或切換到不同的實例。

來源

2017-03-01 20:42:23

感謝您的回答。這使得高可用性的一點點配置變得複雜。以前我只是想，我配置HAProxy（負載平衡器），它可以在端口19000上進行節點運行狀況檢查，並且不僅可以驗證該節點是否處於活動狀態，而且也是SF服務正在運行。任何其他的東西，如重定向到應用程序故障或升級時的其他節點，我認爲這將由SF解決。對於客戶端（任何邏輯，任何反向代理），對SF只使用負載均衡器非常明確。我可以在午夜部署應用程序，但當應用程序失敗時，我必須接受一點工作漏洞。 – tom

服務結構應用程序失敗行爲

回答

相關問題