我正在为HTTP协议通信提供ICommunicationClient和随附内容的实现，这些内容应该与SF反向代理兼容。对我来说，最微妙的部分是重试策略。根据 Azure 文档的 404 错误，反向代理在决定是否应重试时依赖于从 Web 服务返回的 X-Service-Fabric 标头。
ASP.NET Core 提供中间件，用于与反向代理集成，反向代理将 X-Service-Fabric 标头添加到每个 404 响应。
假设我们有这样一种情况，即ServicePartitionClient缓存了侦听端口 3001 的无状态服务的终结点。在某些时候，此服务可能会移动到另一个节点。在第一个节点上，Service Fabric 运行时使用自己的终结点分配不同的服务，但使用相同的中间件并侦听相同的 3001 端口。
当客户端尝试在其旧(缓存)地址调用原始服务时，它将收到包含X-Service-Fabric标头的 404 响应。根据反向代理策略，它不应该重试，但对我来说，客户端似乎将永远连接到错误的服务，并且不会尝试重新解析端点。
我在文档中找不到有关此案例的任何信息，我在这里错过了什么吗？依赖此标准中间件并且不使用 X-Service-Fabric： ResourceNotFound 标头对 404 错误进行重试尝试是否安全？
在所述情况下，通信客户端将因连接到错误的服务而失效。Microsoft建议对具有动态分配端口的服务使用唯一的 URL 前缀来处理这些方案。
ASP.NET 核心程序员可以利用ServiceFabricMiddleware来检查URL前缀，如果它们不匹配，则返回410 Gone然后，如果启用了反向代理集成，则ICommunicationClient的 HTTP 实现只能对 410 响应使用重新解析终结点重试，并且不会对带有X-Service-Fabric: ResourceNotFound标头的 404 响应执行任何重试。
在给定的方案中，当客户端遇到 404 时，X-Service-Fabric:ResourceNotFound标头不是代码在决定是否重试某些操作时可以检查的唯一属性。
为了简单地解决您的问题，即您的客户端将无法区分"友好"节点和"新到达"节点，并且由于您已经在使用 http 标头，因此您可以向传出响应添加自定义 HTTP 标头，以确定请求来自您的应用程序。 当客户端收到 404 时，您只需检查自定义标头是否存在，以回答它是否是"合法"重试的问题。当然，仅仅为了此验证检查而添加自定义 HTTP 标头可能更像是本地问题的全局解决方案。Ed：不言而喻，这不应该用于应用程序做出安全决策
实现相同目的的更优雅和更复杂的方法是使用HTTP标头和响应属性的不同组合来推断相同的结果(例如，查看其他一些标头是否是预期的/意外的)，但这也可能是问题的超本地解决方案。