高可用架构那些没人提前说的事

上周跟前公司的运维老周吃烤串，他撸着串骂到第三瓶冰可乐的时候，还在说前年那次大促的事故。

当时他们团队提前3个月就搭好了对外吹的“金融级高可用架构”，双活机房、熔断规则、降级预案全配得整整齐齐，架构评审会上全是掌声。结果大促零点刚到，订单量刚冲到平时的12倍，整个支付链路直接挂了17分钟。

没人提前想到问题出在哪。

别把高可用当玄学

很多人对高可用的理解，从一开始就走偏了。

觉得只要上了分布式集群、买了企业级负载均衡、跟机房服务商签了SLA，就算把高可用做扎实了。根本没人沉下心来，顺着真实的用户请求链路，从用户点下“支付”按钮开始，一路数过去：经过了哪些网关，调了哪些服务，查了几次数据库，同步了多少日志，哪个环节的带宽、性能、容量，根本扛不住峰值的冲击。

老周说那次事故之前，他们压测只测过单节点的性能，从来没在真实的大促流量模型下跑过全链路。压测的时候流量是均匀打的，真实用户的请求是零点瞬间从全国各地涌进来的，网关的连接数直接冲到了压测值的3倍，第一个超时的环节根本不在他们写好的预案里。

说真的，太多团队做架构方案的时候，总照着行业最佳实践抄，根本不摸自己家的实际流量特征。南方的用户和北方的用户访问延迟差多少，凌晨三点的流量和零点的流量差多少，这些细碎的、没人写在教科书里的细节，才是真出事的时候能要了系统命的东西。

你以为的冗余，可能是摆设

那次复盘的时候，老周他们才发现，之前花了大价钱搭的双活机房，根本就是个摆在PPT上的摆设。

两个机房之间的数据同步专线，平时跑的流量还不到带宽的20%，没人想过真到峰值的时候，订单数据从主机房同步到备机房的带宽会直接被打满。大促当天主机房出问题要切流量的时候，备机房的订单数据滞后了整整3分钟——相当于用户付了钱，系统里根本查不到对应的订单记录，就算切过去，也根本不敢接用户的请求。

更离谱的是他们配的熔断规则，所有的阈值都是按服务自身的QPS设的，根本没考虑下游第三方支付通道的实际限流能力。那天第三方通道本身只给了他们平时5倍的峰值配额，结果他们的系统还在拼命往通道里塞请求，最后通道直接把他们的IP临时拉黑了，连手动重试的机会都不给。

别觉得这种事离自己很远。我见过太多团队的容灾演练，都是在流量最低的凌晨，把一个服务节点手动停掉，看集群能不能自动把流量切走。从来没人模拟过“核心数据库主节点挂了+同步带宽打满+第三方接口超时”这种叠加故障，更没人算过，真遇到这种情况，系统到底能撑多久。

那些看起来配得整整齐齐的冗余，只要没在真实的故障场景下跑过一遍，跟没配根本没区别。

高可用不是堆钱，是算明白账

很多人一提高可用，第一反应就是要砸钱，要上三机房，要搞秒级自动故障切换，要追求四个九、五个九的可用性指标。

根本不算账。

老周他们后来复盘的时候算了一笔账：之前花了快200万搭的双向同步双活机房，80%的场景根本用不上。他们的用户90%都集中在华东区域，华南机房平时的流量占比还不到5%，完全没必要做双向实时同步。把那笔钱省下来，给主链路的出口带宽扩容3倍，再跟第三方支付通道提前谈好峰值的专属配额，最后算下来，总花费还不到之前的1/5，系统的实际可用性反而比之前高了两个档次。

别信PPT上的完美架构。那些在技术大会上吹得天花乱坠的跨地域三中心、秒级故障自动切换的方案，放到小团队的业务里，光日常运维的成本就能把技术团队压得喘不过气。

我之前见过一个刚拿了天使轮的创业团队，团队总共5个技术，第一件事就是照着大厂的架构图抄，上了K8s集群，搞了服务网格，结果连个专职运维都没有。最后集群的SSL证书过期了，全网站挂了3个小时，几个人围着屏幕找了半天，连问题出在哪都没摸清楚。

不是说复杂的架构不好。是你得先想明白，自己的业务到底能承受多长时间的故障，为了减少那点故障时间，要付出多少的人力、物力成本。比如你是个用户量不到10万的初创团队，根本没必要去搞什么跨地域多机房，把核心数据库做个定时异地备份，缓存做个多级兜底，出问题的时候能10分钟内恢复，对用户来说就已经足够好了。

老周说现在他们团队搞高可用，最先做的不是买新设备，是把所有核心链路都画在白板上，每一个环节可能出什么问题，出问题了谁来处理，多久能恢复，都写得明明白白。每个季度拉全团队做一次不打招呼的故障演练。上次演练的时候，他们发现平时用来切流量的DNS配置，TTL值设成了10分钟，真出问题的时候，要等10分钟才能把流量切走——这要是真在大促的时候出问题，损失根本扛不住。

毕竟啊，高可用从来不是什么摆在架构图上的炫酷名词。

是真出事的时候，你能不慌。