Service Fabric 应用程序故障行为答案

【问题标题】：Service Fabric application failure behaviourService Fabric 应用程序故障行为
【发布时间】：2017-03-01 08:51:02
【问题描述】：

我只是在本地测试 Service Fabric。我测试了许多失败场景，但其中一个我无法验证。当节点运行良好但应用程序崩溃时，SF 如何表现？例如，我有无状态的 web api，并且在单个请求之后它失败并关闭（几乎不可能，但这只是假设）。 SF 应该知道它，并且在对同一节点的下一个请求中，它应该重定向对任何其他节点中托管的相同应用程序类型的请求，直到应用程序不再启动？我对吗？在有状态的情况下它应该做同样的事情，但它应该使用副本而不是重定向到其他节点？

我尝试使用 Restart-ServiceFabricDeployedCodePackage 模拟此示例，但它可能重启太快，我无法验证我的假设 - 我超时了。

【问题讨论】：

标签： azure-service-fabric

【解决方案1】：

除非您使用内置的反向代理，否则 Service Fabric 会将请求重定向到服务的假设通常是不正确的（您会知道是否使用它，因为您需要以某种方式构造请求 URL ）。

假设您没有使用内置的反向代理，那么您的服务会在 IP:port 端点上直接相互连接和通信。 Service Fabric 不在请求路径中。 Service Fabric 仅提供服务发现。

SF 检测到进程崩溃。您还可以通过服务代码报告故障。在这些情况下，SF 将重新启动崩溃的进程或报告故障的副本。它们可能会在不同的节点上重新启动。有状态的服务副本几乎总是会故障转移到另一个节点，在该节点可以将活动的辅助节点提升为主节点。如果服务是无状态的，客户端负责解析新的服务端点或切换到不同的实例。

【讨论】：

感谢您的回答。这使高可用性的配置有点复杂。以前我只是想我配置了 HAProxy（负载均衡器），它在端口 19000 上进行节点健康检查，并且不仅为我验证该节点是否处于活动状态，而且该节点是否正在运行 SF 服务。任何其他东西，比如在应用程序失败或升级时重定向到其他节点，我认为这将由 SF 解决。对于客户端来说，仅使用带有 SF 的负载均衡器是非常清楚的（他们这边的任何逻辑，任何反向代理）。我可以在午夜部署应用程序，但当应用程序失败时，我必须接受一点工作漏洞。