我正在研究ICommunicationClient的实现以及HTTP协议通信的附带内容，它应与SF反向代理兼容。对我来说最微妙的部分是重试政策。根据Azure docs for 404错误，反向代理依赖于在决定是否应该重试时从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错误？
答案 0 :(得分：2)
在描述的情况下，通信客户端将通过保持连接到错误的服务而无效。 recommended by Microsoft对于具有动态分配端口的服务使用唯一的URL前缀来处理这些情况。
在ASP.NET Core中，程序员可以利用ServiceFabricMiddleware来检查URL前缀，如果不匹配则返回410 Gone。然后，ICommunicationClient的HTTP实现只能对410个响应重新尝试解析端点，并且如果启用了反向代理集成，则不会对带有X-Service-Fabric: ResourceNotFound头的404响应执行任何重试。
答案 1 :(得分：0)
在您的给定方案中，当您的客户端遇到404时，X-Service-Fabric:ResourceNotFound标头不是您的代码在决定是否重试某些操作时可以检查的唯一属性。
简单地解决您的问题，即您的客户端无法区分“友好”节点和“新到达”节点之间的区别，并且由于您已经在使用http标头，因此您可以添加自定义传出响应的HTTP标头，用于标识请求来自您的应用程序。 当客户端收到404时，您只需检查是否存在自定义标头，即可回答是否为“合法”重试的问题。当然，仅为了验证检查而添加自定义HTTP标头可能更像是本地问题的全局解决方案。 Ed：不言而喻，这不应该用于通过应用程序做出安全决策
更优雅和复杂的完成相同的方法是使用HTTP标头和响应属性的不同组合推断出相同的结果（例如，看看是否有其他标头是预期/意外的），但这也可能是超本地解决问题。