我有一个使用 WCF 服务处理某些数据的 Azure 网站 (website.mycompany.com)。WCF 服务位于以“优先模式”运行的 Azure 流量管理器 (service.mycompany.com) 的后面，有 2 个服务实例用于故障转移处理。使用优先模式，主服务器总是首先提供数据，除非它不可用。如果不可用，第二个实例将回复.. 依此类推。
我们最近遇到了一些实例，其中 service.mycompany.com 的主要端点处于脱机状态。对于指向 service.mycompany.com 的“合作伙伴”，他们检测到了切换，一切都很好。然而，最近我们自己的网站（website.mycompany.com）没有检测到流量管理器开关，并且由于服务无法回复，网站出现错误。
我们在这些实例中的故障转移终结点已启动，并且过去 Azure 网站检测到该开关，直到最近我们才遇到此问题。有没有人遇到过类似的问题？我们是否需要在 Azure 网站中调整任何 DNS 更改以帮助它检测 TTL？
有没有人遇到过类似的问题？
您的意思是流量管理器不能立即切换到另一个端点？
流量管理器工作在 DNS 级别，以下是流量管理器无法立即切换的原因：
缓存的持续时间由每个 DNS 记录的“生存时间”(TTL) 属性确定。较短的值会导致更快的缓存过期，从而导致更多往返流量管理器名称服务器。更长的值意味着将流量从失败的端点引导出去可能需要更长的时间。
流量管理器端点监视器影响响应时间。有关 azure 流量管理器如何工作的更多信息，请参阅链接。
以下时间表是对监控过程的详细描述。
我们还可以在 Windows 中使用 nslookup 和 ipconfig 检查流量管理器配置文件。关于如何验证流量管理器设置，请参考链接。
顺便说一句，由于流量管理器在 DNS 级别工作，它不会影响到任何端点的现有连接。当它在端点之间引导流量时（通过更改的配置文件设置，或者在故障转移或故障回复期间），流量管理器将新连接引导到可用端点。但是，其他端点可能会继续通过现有连接接收流量，直到这些会话终止。为了使流量从现有连接中排出，应用程序应限制与每个端点一起使用的会话持续时间。
我将在这里向您推荐我的答案，因为虽然情况并不完全相同，但似乎可以有相同的解决方案。总而言之，我发现您可能有一个连接未正确关闭的关闭服务。此连接独立于 TTL，后者仅处理 DNS 缓存，因此完全绕过流量管理器。