高可用架构不是堆服务器的游戏

上周帮老东家排完大促前的最后一轮压测，从机房出来的时候裤腿上还沾着机房门口的三花奶猫掉的毛。说真的，做了快八年技术，见过太多团队把高可用架构做成了汇报PPT上的漂亮数字，真到流量冲过来的时候，连个能自动切换的备用节点都找不到。

先搞清楚你要扛的到底是哪类故障

很多人一提到高可用，第一反应就是多机房、多活、上云，恨不得把所有能花钱买的组件全堆上去。去年碰到一个做职场简历工具的创业团队，CTO拍板花了几十万搞三地五中心的部署架构，结果上个月核心接口因为宿主机内存泄漏挂了，整套多活系统居然一点反应都没有——翻了半天才发现，健康检查的阈值只设了CPU使用率超过80%才触发告警，内存漏到92%都没进入告警逻辑，最后还是运维从监控群的截图里发现接口超时，手动把流量切到了备用节点。

说白了，故障从来不是统一模板的。从影响范围拆，无非三类：单机宕机、单个可用区网络故障、整个区域级的机房断网。不是所有故障都需要用最贵的方案硬扛。比如你给公司内部做个OA系统，单机挂了多副本在同个机房兜底就够，真要是整个华东机房断网，全公司停两小时OA，老板也不会跳起来拍桌子。但要是你做的是电商大促的订单支付链路，那单个可用区的故障你就得自动扛过去，不然几百万订单飞了，谁都担不起这个责。 我之前跟那个简历工具的CTO聊，他说当时就是照着大厂的架构文档抄的，根本没算过自己的业务峰值——平时日活才两万，大促撑死也就二十万，峰值流量是平时的三倍，纯纯拿宝马的保养方案养家里的电动自行车，光云资源一年的成本就占了营收的30%，图啥啊。

那些藏在代码缝隙里的可用性黑洞

太多团队对高可用的理解还停留在“买够服务器、配好负载均衡”的层面，根本不管代码链路里藏着的暗坑。我去年排过一个最离谱的故障：大促当天订单接口的响应时间从50ms涨到了2s，最后排查下来，是订单服务调库存服务的超时时间设成了10秒，库存服务被流量冲的响应变慢，订单服务的线程池被慢慢占满，连锁反应把整个交易链路的所有服务全堵死，整个页面卡了整整12分钟。 超时、重试、熔断这三个组件，是高可用架构里最不起眼但最容易出人命的零件。很多人配重试的时候根本不做指数退避，下游服务刚挂，所有上游的请求都在疯狂重试，本来1000QPS的正常流量，直接翻了四倍冲到下游，本来能慢慢恢复的服务，直接被重试流量打挂到完全起不来。还有人把熔断的阈值设成错误率50%才触发，结果大促的时候，请求排队导致的超时慢慢把错误率推到40%，还没到熔断线，整个系统的线程池已经全堵死了。

对吧？你仔细想想，你上次碰到的线上重大故障，真的是因为服务器买少了吗？我碰到的十次里有八次，都是这些没人愿意花半小时仔细调的小参数攒出来的。之前有个做本地生活的团队，把所有接口的重试次数设成了3次，压测的时候才发现，本来1000QPS的请求，经过三层服务的重试，最后冲到最底层的数据库的时候，流量已经翻了快10倍，直接把数据库的连接池打满，整个系统直接瘫了。这哪是搭高可用架构，这是给自己的系统上刑啊。

没演练过的备用方案就是一张废纸

还有个最普遍的误区：很多团队觉得只要做了主从备份、配了灾备，就算高可用了。之前碰到个做连锁奶茶品牌的技术团队，说自己的线上点单系统做了同城双活，结果去年夏天路边施工把机房的主光纤挖断，切备用节点的时候才发现，CDN的域名解析配置根本没同步，用户点进去全是404，最后当天下午的营收直接少了60%，老板在群里骂了整整三个小时。 没有经过全链路演练的高可用方案，本质上就是一张写满字的废纸。我之前待过的团队，每个月固定搞一次故障演练，故意把某个核心节点的服务停掉，把某条网络链路掐断，看整个系统能不能在没有人工干预的情况下自动恢复。一开始演练的时候，各种问题全冒出来：主从数据库的同步延迟已经三个小时了，切过去直接丢三小时的订单数据；负载均衡的健康检查没配对，备用节点早就挂了还在往上面转流量；告警系统的通知通道是坏的，故障发生了半小时运维都没收到消息。 这些问题你不演练，永远不知道它藏在哪。真等真实故障发生的时候，你手忙脚乱翻配置文档的那几分钟，造成的损失可能是你半年的技术预算。 上周跟那个简历工具的CTO聊天，他把之前花大价钱搭的三地五中心砍成了同机房的双副本，每个月的云资源成本省了小十万，上周搞压测，峰值流量翻了五倍，系统连个告警都没触发。 你看，高可用架构从来不是比谁花的钱更多，比谁抄的大厂架构更像。是你真的知道自己的业务哪条线不能断，哪块掉点链子根本没人在乎。