高可用架构的故障域设计别只做表面冗余
2026-11-13 02:46:43
作者：
fawen
去年双11前帮一个做生鲜电商的朋友排查架构隐患，他们的架构图上标着跨三个城市的三中心容灾，每个中心都有全量的交易、库存和支付能力，算下来年在基础设施上的投入快两千万，按说怎么都不该在大促的时候出大问题。结果排查到一半，我发现三个机房的公网出口全挂在同一家运营商的同一个城域网核心节点上，甚至供电回路都接的同一个变电站的出线。我当时看完，差点把手里的冰美式喷出来。
你以为的隔离，根本没碰到真正的故障边界
很多团队对故障域的理解，还停留在“物理上隔了几百公里就算隔离”的阶段。觉得多开几个机房、多买几个可用区的资源，就算把高可用做到位了。
说真的，这种认知真的会害死人。
所有可能被同一个故障同时击中的资源集合，才叫真正的故障域边界。你在墙上划的机房分隔线不算数，墙外面的共享链路、共享供应商、共享依赖，才是最容易把所有隔离设计击穿的破洞。
就拿刚才那个生鲜电商的例子，他们觉得三个城市的机房是三个独立的故障域，实际上只要那个共享的城域网节点出问题，三个机房同时断对外连接，跟把所有服务器放在同一个机房里没有任何区别。之前还有个做在线教育的客户，在某云上买了三个可用区的弹性计算资源，结果某次云厂商的跨可用区分布式存储集群出故障，三个可用区的应用同时读不到用户上传的课件，整整两个小时没法上课，之前做的可用区隔离设计，全成了摆设。
三地三中心数据中心网络链路拓扑图
别拿静态清单当动态的故障域地图
我见过太多团队的故障域设计，是项目上线的时候拉个会，画完架构图就存到文档库的最深处，之后再也没人更新。
这根本没用。
架构是一直在变的。你今天刚把核心服务拆到三个独立的故障域，过两个月运维为了统一管理，把所有服务的日志都集中传到同一个日志集群，结果日志集群的带宽被大促的流量打满，所有服务的日志写入超时，触发了自己写的熔断逻辑，全链路直接挂死。这时候你之前画的故障域边界，早就被新冒出来的共享依赖戳得千疮百孔。
之前跟一个做跨境支付的技术团队聊，他们每次架构评审，都会专门拉上网络组、运维组、甚至是负责对接外部供应商的商务，一起过最近三个月的所有架构变更。上次评审的时候他们就发现，自己本来以为做了双备份的两个支付通道，背后对接的是同一家第三方支付机构的同一个清算节点——这俩通道根本就是同一个故障域，真的遇到清算节点故障，两个通道会同时挂，完全起不到冗余的作用。
微服务架构跨域依赖链路排查示意图
落地的细节，从来都在架构图的边角料里
真要把故障域设计做扎实，别总想着搞什么高大上的理论框架，几个边角的细节盯牢了，效果比砸几千万买冗余资源好得多。
比如冗余资源的责任边界，绝对不能全押在同一家供应商身上。三个机房的出口分别接三家运营商的不同城域网节点，供电回路要接两个不同变电站的进线，哪怕是买云服务，也要选两个不同云厂商的可用区做核心链路的冗余，别全凑在同一个厂商的同一个大区里。
再比如故障演练的场景，别每次都演同一个机房断电的老剧本。要敢想那些你觉得概率极低的场景：比如某个运营商的骨干网割接影响了三个机房的出口，比如某个跨可用区的云存储集群同时出故障，甚至是负责接告警的值班同事手机没电失联的情况。别觉得这些演练是瞎折腾。上次我见过一个团队，演练的时候才发现，他们写的故障自动切换脚本里，告警联系人还是半年前离职的老员工，真出事的时候根本没人能收到通知。
当然，也别走到另一个极端。很多人觉得故障域拆的越细越好，恨不得把每个服务实例、每个进程都划成独立的故障域。完全没必要。故障域的拆分粒度，要和业务的损失承受能力匹配。核心交易链路的故障域可以拆到很细，毕竟每宕一分钟都是真金白银的损失；但内部的OA系统、员工培训平台，就算所有服务都放在同一个故障域里，出问题也不会影响核心收入，拆得太细反而会把运维团队压垮。
说实话，做架构这么多年，见过太多团队在冗余上砸了大价钱，结果因为一个没注意的共享依赖，所有投入都打了水漂。故障域设计从来不是什么需要拿学位才能搞懂的高深学问，就是你每次做架构决策的时候，多问一句：如果这个东西坏了，哪些东西会跟着一起坏？
就这一句话。
能帮你避开90%的坑。
免责声明：市场有风险，选择需谨慎！此文仅供参考，不作买卖依据。如有侵权请联系删除。
文章名称：
高可用架构的故障域设计别只做表面冗余
文章链接：https://m.itcdj.com/news/768.html