如何应对Azure Frontdoor服务宕机停机问题？

不要在Azure Front Door（下文简称AFD）前端额外部署流量接入组件，这种架构会额外引入单点故障、增加访问延迟、抬升运维复杂度，反而会降低整体服务可用性，完全得不偿失。应对AFD服务宕机，可采用以下经过生产验证的方案：

• 不推荐在AFD前叠加入口组件的核心原因：AFD本身是基于全球任播IP的边缘网络，节点覆盖全球主流运营商区域，如果在它前端再部署反向代理、第三方流量网关类组件，相当于把原本分布式的全球入口收敛到你部署组件的固定点位，不仅会丢失AFD边缘节点就近接入的低延迟优势，你自行部署的前置组件本身就会成为新的单点，一旦组件故障，哪怕AFD本身运行正常，用户也无法访问你的服务。
• 采用跨边缘服务商的DNS级多活调度：不要将所有入口流量完全绑定在AFD单服务商上，至少接入两家不同厂商的全球边缘加速/CDN服务作为互备。在DNS服务商处配置健康检查规则，同时对AFD和备用边缘服务的接入点做可用性探测，一旦检测到AFD的5xx错误占比超过阈值、服务不可用，就自动将DNS解析权重全部切到备用边缘服务，备用服务直接回源到你后端部署的Web应用集群，完全绕开故障的AFD链路。注意要把对应域名的DNS TTL设置为60秒以内，保证故障发生时全球解析节点能快速更新记录，缩短故障影响窗口。
• 用好AFD原生的高可用能力：首先要区分故障边界，如果是你配置的源站故障而非AFD本身服务异常，AFD原生支持多源站组配置，你可以跨可用区、跨区域部署后端源站，开启源站健康检查后AFD会自动将流量切到可用的源站节点；如果要降低AFD单实例故障的影响，可以部署多个独立的AFD配置文件，将流量按比例拆分到不同AFD实例上，避免单实例故障导致全量服务中断。
• 配置静态降级兜底能力：提前将Web应用的静态资源（首页、静态脚本、图片、服务维护提示页）同步到独立的静态托管节点，一旦检测到AFD全量服务不可用且备用边缘链路也出现异常，直接将域名解析切到静态兜底站点，避免用户直接看到连接超时、无法访问的报错，降低故障的用户感知。

注意：所有故障切换策略必须提前做模拟演练，不要等生产故障发生时才发现切换逻辑失效、DNS TTL配置过长、备用服务回源规则错误，建议每季度至少开展一次模拟AFD故障的流量切换演练，验证切换时效和业务可用性。

内容的提问来源于stack exchange，提问作者Dan Møller