ASP.NET Core 404 响应中的 Service Fabric 反向代理集成

Question

我正在研究ICommunicationClient 的实现以及用于 HTTP 协议通信的相关内容，这些内容应该与 SF 反向代理兼容。对我来说最微妙的部分是重试策略。根据 Azure docs for 404 errors，反向代理在决定是否应重试时依赖于从 Web 服务返回的 X-Service-Fabric 标头。

ASP.NET Core 提供 middleware 用于与反向代理集成，该反向代理向每个 404 响应添加 X-Service-Fabric 标头。

假设我们有这样的场景：ServicePartitionClient 为侦听端口 3001 的无状态服务缓存端点。在某些时候，该服务可能会移动到另一个节点。在第一个节点上，Service Fabric 运行时分配具有自己的终结点的不同服务，但使用相同的中间件并侦听相同的 3001 端口。

当客户端尝试在其旧（缓存）地址调用原始服务时，它将收到包含 X-Service-Fabric 标头的 404 响应。根据反向代理策略，它不应该重试，但对我来说，客户端似乎会永远保持连接到错误的服务，并且不会尝试重新解析端点。

我在文档中找不到有关此案例的任何信息，我在这里遗漏了什么吗？依赖此标准中间件并且不对带有 X-Service-Fabric: ResourceNotFound 标头的 404 错误进行重试尝试是否安全？

Answer 1

在所描述的情况下，通信客户端将因保持连接到错误的服务而失效。 recommended by Microsoft 为具有动态分配端口的服务使用唯一的 URL 前缀来处理这些场景。

在 ASP.NET Core 中，程序员可以利用 ServiceFabricMiddleware 检查 URL 前缀，如果不匹配则返回 410 Gone。然后，ICommunicationClient 的 HTTP 实现可以仅针对 410 响应使用重新解析端点重试，并且如果启用了反向代理集成，则不对带有 X-Service-Fabric: ResourceNotFound 标头的 404 响应执行任何重试。

Answer 2

在您给定的场景中，当您的客户端遇到 404 时，X-Service-Fabric:ResourceNotFound 标头并不是您的代码在决定是否重试某些操作时可以检查的唯一属性。

为了简单地解决您的担忧，即您的客户端将无法区分“友好”节点和“新到达”节点之间的区别，并且由于您已经在使用 http 标头，您可以添加自定义传出响应的 HTTP 标头，以标识请求来自您的应用程序。 当客户端收到 404 时，您可以简单地检查您的自定义标头是否存在，以回答它是否是“合法”重试的问题。当然，仅仅为了验证检查而添加自定义 HTTP 标头可能更像是针对本地问题的全局解决方案。 Ed：不用说，这不应该被应用程序用来做出安全决策

一个更优雅和更复杂的方法是使用 HTTP 标头和响应属性的不同组合来推断相同的结果（例如，查看是否有一些其他标头是预期的/意外的），但这也可能是问题的超本地解决方案。