我正在开发 ICommunicationClient 的实现以及用于 HTTP 协议(protocol)通信的附带内容，这些内容应与 SF 反向代理兼容。对我来说最微妙的部分是重试策略。根据 Azure 文档，404 错误反向代理在决定是否应该重试时依赖于从 Web 服务返回的 X-Service-Fabric header 。
ASP.NET Core 提供 middleware用于与反向代理集成，它将 X-Service-Fabric header 添加到每个 404 响应中。
假设我们有这样的场景:ServicePartitionClient 缓存了监听端口 3001 的无状态服务的端点。在某些时候，该服务可能会移动到另一个节点。在第一个节点上，Service Fabric 运行时分配具有自己的终结点的不同服务，但使用相同的中间件并监听相同的 3001 端口。
当客户端尝试在其旧(缓存)地址调用原始服务时，它将收到包含 X-Service-Fabric header 的 404 响应。根据反向代理策略，它不应该重试，但对我来说，客户端似乎将永远保持连接到错误的服务，并且不会尝试重新解析端点。
我在文档中找不到有关此案例的任何信息，我是否在这里遗漏了某些内容？依赖此标准中间件并且不对 X-Service-Fabric: ResourceNotFound header 的 404 错误进行重试尝试是否安全？
最佳答案
在所描述的情况下，通信客户端将因保持连接到错误的服务而失效。是recommended by Microsoft为具有动态分配端口的服务使用唯一的 URL 前缀来处理这些场景。
在 ASP.NET Core 中，程序员可以利用 ServiceFabricMiddleware它检查 URL 前缀，如果不匹配则返回 410 Gone。然后，ICommunicationClient 的 HTTP 实现可以仅对 410 响应使用重新解析端点进行重试，并且不会对带有 X-Service-Fabric: ResourceNotFound header 的 404 响应执行任何重试，如果反向代理集成已启用。
关于c# - ASP.NET Core 404 响应中的 Service Fabric 反向代理集成，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/49038290/