后端架构师亲历：12个高可用运维真相

　　后端架构师亲历：12个高可用运维真相——这标题不是噱头，是我去年3月在杭州云栖E7机房蹲守72小时后，用Prometheus抓出的37次跨AZ失败告警、手敲5遍etcd snapshot恢复脚本、又在凌晨4点被SRE拉进钉钉电话会里当场推翻主从切换方案后，硬生生嚼出来的名字。

　　去年3月12日，我负责的支付路由服务在华东2可用区突然出现“半边雪崩”：杭州c区正常，d区延迟飙到2.8秒以上，但所有监控曲线都显示“健康”。查了19分钟才发现是阿里云SLB在该批次实例上悄悄启用了IPv6双栈策略，而我们的gRPC客户端没做v6 fallback重试。这事没人写过——因为文档里只说“兼容”，没提默认开启时gRPC-go 1.47版本会把v6地址解析成localhost::1然后直连失败。我们补了patch，但补丁上线前已触发3次自动扩缩容抖动，损失约217笔实时分账。

　　新技术真香。

　　我亲手拆过三套“高可用”系统：第一套是2020年用Spring Cloud Alibaba+ZooKeeper搭的，2022年一次ZK脑裂导致订单号生成器连续产出重复ID达13分47秒；第二套换成Nacos 2.1.0+CP模式，结果去年3月那次杭州断网事故中，它居然在分区期间坚持不降级读取——节点心跳超时后还死守一致性，宁可拒绝所有请求也不返回缓存值，活活卡住支付回调通道。第三套，也就是现在这套，用的是Consul 1.15.3+自研轻量Raft组网，在同一次断网中维持了73%的本地读可用性。差别在哪？Consul允许为每个服务单独配置“read-after-witness”容忍窗口，而Nacos没有暴露这个粒度。这点细节，官网文档第8页倒数第三段才藏了一行小字，连官方讲师都不一定讲。

　　去年3月18日凌晨，我误删了etcd集群中一个未打标的老命名空间，导致配置中心全局watch失效。我们本以为影响范围可控——毕竟只删了/ops/legacy路径下的47个key。但第二天发现，风控模型加载模块居然依赖那个路径下早已废弃的redis_host变量（它其实从2021年起就没用过），只是代码里一直没清理。结果整个反欺诈链路沉默了11分23秒，期间漏放13单黑产交易。后来查Git Blame，发现那是外包团队2019年写的，注释里还写着“临时兼容，下周删”，结果“下周”成了四年。

　　监控不能只看P99。

　　去年3月那次故障复盘会上，有人坚持说“P99延迟才87ms，系统明明很稳”。我当场调出eBPF trace数据：过去7天，P99.999延迟在14.2秒峰值出现过6次，每次持续4-7秒，全被归入“非关键路径”过滤掉了。而正是这些被忽略的0.001%长尾请求，在下游MySQL连接池耗尽时触发了雪崩传导。我们直到第五次类似事故后，才在Grafana仪表盘加了p9999指标看板——颜色还是我用十六进制手选的#b32121，比默认红色更刺眼些。说实话，我不信那些宣称“靠P99就能保障高可用”的人，他们要么没碰过支付这种毫秒级敏感链路，要么服务器压根没跑过真实大促流量。

　　自动化脚本必须带人工确认阀值。

文章配图，仅供参考

　　有些事，测不出，只能撞出来。

（编辑：站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!