后端架构师12年高可用实践：从宕机到稳如磐石

文章配图，仅供参考

　　老陈后来在复盘会上摔了键盘，说“这锅我背，但你们得听我讲完这十二年”。他说2010年刚入行时，高可用就靠双机热备，主库挂了切备库，结果有次切过去发现备库数据延迟了十八秒，客户下单时库存还是满的，等发现超卖已经晚了三百多单。后来学聪明了，搞分布式锁，结果锁粒度没设计好，某个接口被锁了半小时，整个服务链卡成PPT。再后来上容器化，他又被K8s的滚动更新坑过——新版本部署时，旧Pod没等健康检查就销毁，导致部分请求直接丢包，客户骂街的电话把客服主管手机打没电了。

　　但最离谱的是2018年那次。当时我们用某云厂商的负载均衡，架构师非说“云原生最可靠”，结果人家后端节点故障，自动扩容时把新实例全挂到了同一个可用区。那天暴雨，我蹲在办公室啃冷掉的煎饼果子，看监控曲线跟心电图似的上下跳——故障持续了二十七分钟，等云厂商修复完，我们自己写的熔断机制已经把一半流量切到了备用链路，结果备用链路的缓存没预热，又引发了一波雪崩。老陈说这事儿时，运维小哥在旁边拆快递，拆出个“稳如老狗”的贴纸，啪一声贴在了工位挡板上。

　　我原以为这些坑都是技术债，结果老陈说不是——是优胜劣汰。他说早期大家连“高可用”这个词都没统一，有人觉得双机热备就是终极方案，有人觉得得搞异地多活，吵得面红耳赤。后来出了几次大事故，双机热备的团队被优化了，搞异地多活的团队活了下来；再后来容器化普及，那些死磕物理机部署的架构师又陆续转行了。现在剩下的，都是被故障喂出来的“人形熔断器”——比如他，现在看任何架构图第一眼先找单点，第二眼看降级策略，第三眼才看业务逻辑。他说这话时，测试小妹举着手机从旁边经过，屏幕上是她刚拍的工位照，配文“这破班上得，连绿植都养不活”。

　　不过说实话，我现在也信这套了。去年双十一前，我们新上了一个推荐服务，架构师非要试“无状态化”，说这样扩容快。我原以为他又要搞幺蛾子，结果人家提前三个月就开始压测，把每个接口的QPS、延迟、错误率都标得清清楚楚，连第三方API的限流阈值都摸透了。双十一当天，流量涨了五倍，服务稳得像块石头——倒是隔壁团队的缓存服务扛不住，直接熔断了三次，客户在群里骂“推荐的都是什么鬼东西”。后来复盘，老陈说这就是优胜劣汰的证明：那些没被故障锤过的架构师，写的方案看着漂亮，一上真刀真枪就露怯；被锤过的，方案里全是“补丁”，看着丑，但能扛事。

　　现在我也学乖了。上周新来的实习生写了个定时任务，没加重试机制，我直接让他回去改——不是因为我多懂，是我见过太多“没想到”的故障：网络抖动、依赖服务超时、磁盘IO突增……这些事儿在生产环境里就跟吃饭喝水一样平常。老陈说，高可用不是靠某个“银弹”解决的，是靠一代代架构师被故障锤出来的经验堆出来的。这话我信——毕竟，谁没在凌晨三点被监控警报叫醒过呢？

　　对了，上周老陈离职了，说要去小公司当CTO，把“稳如磐石”的方案再验证一遍。走之前他塞给我一本笔记，封皮上写着“十二年宕机实录”，我翻了两页，全是各种故障的截图和复盘记录——其中有一页的角落里，还粘着那年机房空调坏了时，运维小哥擦汗用的纸巾碎片。

（编辑：站长网）

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