我正在开发 ICommunicationClient 的实现以及用于HTTP协议通信的附带内容，它应该与SF反向代理兼容 . 对我来说最微妙的部分是重试政策 . 根据Azure docs for 404错误，反向代理依赖于在决定是否应该重试时从Web服务返回的X-Service-Fabric头 .
ASP.NET Core提供middleware用于与反向代理集成，后者为每个404响应添加X-Service-Fabric标头 .
假设我们有 ServicePartitionClient 缓存 endpoints 的情况，无状态服务侦听端口3001.在某些时候，此服务可能会移动到另一个节点 . 在第一个节点上，Service Fabric运行时使用自己的 endpoints 分配不同的服务，但使用相同的中间件并在同一个3001端口上侦听 .
当客户端尝试在其旧（缓存）地址调用原始服务时，它将收到包含 X-Service-Fabric 标头的404响应 . 根据反向代理策略，它不应该尝试重新解析 endpoints .
我在文档中找不到关于此案例的任何信息，我在这里想念一下吗？依赖此标准中间件是否安全，并且不使用X-Service-Fabric：ResourceNotFound标头重试404错误？
2 回答
在所描述的情况下，通过保持连接到错误的服务将使通信客户端无效 . 对于具有动态分配端口的服务，使用唯一URL前缀来处理这些方案是recommended by Microsoft .
在ASP.NET中，程序员可以利用ServiceFabricMiddleware检查URL前缀，如果不匹配则返回410 Gone . 然后，如果启用了反向代理集成，
ICommunicationClient的HTTP实现可以仅针对410个响应重新解析 endpoints ，并且不会使用X-Service-Fabric: ResourceNotFound头执行404响应的任何重试 .在您的给定方案中，当您的客户端遇到404时，
X-Service-Fabric:ResourceNotFound标头不是您的代码在决定是否重试某些操作时可以检查的唯一属性 .为了简单地解决您的客户赢得't be able to tell the difference between a 858792 node and a 858793 node, and since you'已经使用http标头的问题，您可以向传出响应添加自定义HTTP标头，以识别请求来自您的应用程序 . 当客户端收到404时，您只需检查是否存在自定义标头即可回答是否为"legit"重试的问题 . 当然，仅为了验证检查而添加自定义HTTP标头可能更像是本地问题的全局解决方案 . Ed：不言而喻，这不应该用于由应用程序做出安全决策
更优雅和更复杂的方法是使用HTTP标头和响应属性的不同组合来推断相同的结果（例如，查看是否有其他标头是预期的/意外的），但这也可能是超本地的解决问题的方法 .