我有一个使用Azure Devops部署的多层应用程序。它使用了"蓝绿"部署方法。(即两个相同的堆叠并排。)这很好。while lot由Azure Front Door前置，这样一个URL(称为"Prod")指向一个应用程序堆栈，另一个URL(称为"ProdNew")指向另一个应用程序堆栈。
appProd.contoso.com——比;后端产品
appProdNew.contoso.com——比;后端ProdNew
测试人员测试appProdNew.contoso.com，当它全部工作时，有一个切换管道改变前门规则:
appProd.contoso.com——比;后端ProdNew
(不要担心飞行事务，它们都由一些数据库智能处理。)
问题是，前门继续指向后端Prod，即使在配置保存后。如果放置几个小时(我不知道多少小时，但它意味着一夜)，最终，它确实使用新的后端。
- 缓存和会话关联被禁用，但问题仍然存在。
- 停止后端Prod只会导致前门说后端下降。换句话说，它甚至不会尝试使用新的后端。
- 我在这里读到https://learn.microsoft.com/en-us/azure/frontdoor/front-door-faq"因为前门不工作在虚拟机/容器级别，所以它不能做连接排水"。好的，我明白了，但是连接最终还是会超时的，不是吗?
- 同一网站还说:"大多数新的前门创建和更新需要大约3到20分钟才能部署到我们全球所有的边缘位置。"对路由或后端池等的任何更新都是无缝的，并且将导致零停机(如果新的配置是正确的)。然而，即使一个小时后，它仍然试图使用相同的旧后端。 我们已经尝试禁用和重新启用规则。但是当重新启用后，它仍然尝试使用旧的后端，即使规则明确指向新的后端。
在《前门》之前，我们使用DNS cname并翻转它们。这种方法的问题是，在转换过程中，有些人会使用旧的，有些人会使用新的，这给蓝/绿部署带来了问题。使用"前门"的一个想法是在切换过程中获得更多的控制。
问题:我们是否以错误的方式处理问题，或者我们是否可以向前门抛出一个命令来强迫它使用新的后端?
问题中描述的行为似乎不是预期的行为。根据第二天的额外测试，当Front Door用新的后端更新时，它就开始使用它了——即使没有缓存清除。因此，问题似乎是一个"小故障"。在前门，可能只是延迟应用新的配置。