高可用架构从来不是堆机器

上周跟做电商运维的老陈撸串，他拍着大腿说去年618亏了三百万，原因说出来都丢人——他们提前半个月按三倍流量备了服务器，机房租了双线路，所有能加的监控都拉满了，结果零点刚过，订单系统直接卡成PPT。 不是流量超了。 是订单回调的消息队列，把所有积压的消息一股脑甩给了刚扩容完的库存服务，直接把库打挂了。

别把”多备几台机器”当高可用

真的蠢。 很多团队一提高可用，第一反应就是加节点、上集群，把主从架构搭起来就觉得万事大吉，甚至觉得只要节点数够多，就算某几台挂了剩下的也能扛住流量。可真遇到故障的时候，才发现算容量的时候只算了平稳流量下的CPU、内存占用，从来没考虑过故障触发的连锁反应——比如主库切主的几十秒里，所有请求的重试排队、消息积压的消费洪峰，这些流量根本不是线性增长的，是会指数级炸开的。 老陈他们当时就是，扩容的时候压根没给消息队列设消费速率的上限。平时流量平稳的时候啥问题没有，一到零点，所有用户同时点支付，队列里瞬间堆了二十万条消息，消费端一开始拉满跑，数据库的连接数直接顶到上限，整个服务顺着依赖链一路雪崩。

你说这钱花得冤不冤？硬件买了，带宽租了，监控也搭了，最后栽在一个没设上限的配置上。

高可用的核心是”容错”不是”零故障”

很多人对高可用的认知走了极端，觉得要追求99.999%的可用性，算下来一年累计宕机时间不能超过五分钟，听着就唬人。可实际业务里，真有几个场景值得砸大价钱追这个五个九？ 比如公司内部的员工报销系统，99%的可用性都绰绰有余——就算每月宕机七小时，大家晚两天提交报销单，根本不影响核心业务赚钱。反过来要是真为了追五个九，花几百万上三地域的异地多活，最后一年的多活运维成本，比系统全年宕机造成的总损失高十倍，这账怎么算都亏。 之前帮一家做社区团购的团队做架构梳理，他们之前想抄头部大厂的异地多活方案，算下来光三个地域的机房托管费一年就两百万。最后我们给他们调整的方案是，核心的下单链路做同城双机房冗余，非核心的评价、推荐模块全部加一键降级开关，遇到流量高峰的时候直接把推荐模块占的资源切给下单链路，整个方案一年成本不到原来的三分之一。去年大促的时候峰值流量超了预估的40%，系统愣是没挂。

容错的本质从来不是让系统永远不出错，而是错真的发生的时候，你清楚哪部分可以暂时停服，哪部分必须死保，不会让一个小故障顺着依赖链滚成拖垮全系统的大崩溃。 别追求完美。真的。

落地的时候别跳过最朴素的验证环节

我见过太多团队，架构图画得天花乱坠，从入口的负载均衡到中间的服务网格，再到数据库的分库分表，每一层都标了冗余节点，每一个组件都写了备份策略，可从来没真刀真枪演练过故障场景。 之前碰到过一个团队，拍着胸脯说自己的主从切换已经做到全自动化，结果第一次实战演练就露了怯：主库被强制停掉之后，从库的账号权限没配全，切过去之后所有的写请求全报权限错误，整个系统硬扛了四十分钟才恢复。还有更离谱的，他们说自己每天做全量数据库备份，真要恢复的时候才发现，之前的备份脚本写漏了逻辑，存了半年的备份文件全是损坏的，连个能正常读的数据块都找不出来。 说实话，很多团队把架构评审当走流程，PPT上写得滴水不漏，真到故障来的时候，连个明确的值班联系人列表都找不全。根本不需要上复杂的混沌工程平台，最朴素的故障演练就够解决80%的问题：每个季度找个业务低峰的时间，随机抽一个服务节点把它停掉，看看整个系统会不会自动切流量，会不会有非核心服务因为依赖挂了直接雪崩；再随机抽一个存了一个月的数据库备份文件，真的恢复到测试环境跑一遍，看看能不能正常读写数据。就这么简单的事，很多团队就是懒得做。 老陈说今年618之前，他们没搞那些花里胡哨的扩容方案，就每周随机拔一台生产服务器的网线，练了三次故障切换，把消息队列的消费速率上限调到了数据库能扛的安全阈值，加了三个降级开关——只要库存服务的响应时间超过200ms，就先把非核心的优惠券计算逻辑暂时关掉，优先保支付链路。结果今年618当天流量比去年高了一倍，系统全程稳得一批，没出一次故障。 前几天刷到有人说高可用架构是大厂的专属配置，小公司根本玩不起。 扯什么呢。 高可用从来不是比谁花的钱多，比谁的架构图画得复杂。你要先搞清楚自己的业务最怕什么故障，把最核心的那部分链路做扎实，把能提前想到的坑都踩过一遍，比你抄十份大厂的架构文档都管用。