Azure Traffic Manager+Application Gateway架构：后端Web应用故障路由异常咨询

你的推测完全命中了核心——Azure Traffic Manager默认只会探测Application Gateway的默认后端池，根本不会感知到App Gateway内部基于路径路由的其他后端池状态。这就是为什么当某个路径对应的后端池故障时，Traffic Manager还一个劲地把流量往这个App Gateway上导，导致请求持续失败。

为啥会出现这种情况？ #

• Traffic Manager的健康探测是直接打向App Gateway的公网IP/域名，而App Gateway自身的健康状态默认只由默认后端池的状态决定。只要默认后端池还活着，App Gateway就会给Traffic Manager返回「健康」状态，完全不管其他路径对应的后端池是不是已经挂了。
• App Gateway的路径路由规则是流量到了它之后才做转发的，Traffic Manager没法穿透到这一层去感知具体后端的状态。

几个可行的解决办法 #

方案1：给每个路径后端池单独配置Traffic Manager终结点 #

• 别把整个App Gateway当成一个终结点，而是把每个需要独立健康检查的Web应用（或者说每个路径对应的后端池）都设为Traffic Manager的单独终结点。
• 这样Traffic Manager就能直接探测每个Web应用的健康状态，哪个后端挂了，就自动把对应流量切到其他可用的终结点上。
• 注意：这种方式需要每个Web应用有独立的可探测地址（比如子域名），同时得调整Traffic Manager的路由规则来匹配。

方案2：自定义App Gateway的健康探测与状态反馈 #

• 给App Gateway配置自定义健康探测，让它不光检查默认后端池，还要关联上其他路径的后端池状态。
• 更关键的是，在App Gateway上搞一个专用的健康检查端点（比如/health），这个端点的状态要综合所有核心后端池的健康情况——只要有一个核心后端池挂了，这个端点就返回「不健康」。
• 然后把Traffic Manager的健康探测指向这个专用端点，这样只要任何关键后端池出问题，App Gateway就会给Traffic Manager报「不健康」，Traffic Manager就会把流量切到另一个App Gateway上。

方案3：用Azure Monitor+自动化触发Traffic Manager切换 #

• 用Azure Monitor监控App Gateway后端池的健康状态（比如通过BackendHealth指标）。
• 一旦检测到某个后端池故障，就通过Azure Automation Runbook或者Logic Apps自动修改Traffic Manager的优先级规则，把出问题的App Gateway优先级调低，让流量自动切到健康的那个。
• 这种方式适合复杂场景，需要做一些自动化配置，但灵活性拉满。

额外提醒 #

• 如果你用的是Traffic Manager的优先级路由，一定要确保备用App Gateway的后端池是完全冗余的，这样切过去之后用户体验才不会受影响。
• 可以把健康探测的频率调快一点（比如从默认30秒改成10秒），这样故障检测和切换的速度会更快，但也别调太狠，避免过度探测消耗过多资源。

内容的提问来源于stack exchange，提问作者Azure Ninja