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

　　去年寒假那项目，甲方CTO半夜三点在群里发了个60秒语音方阵，我原以为又是哪个接口超时了，结果点开听——前三十秒在夸我们系统稳，后三十秒说“就是那个登录页的按钮能不能再大两像素？”我盯着手机屏幕看了半天，突然想起十二年前刚入行时，带我的架构师说过的话：“高可用？先把甲方的‘就改一点点’扛住再说。”

　　那会儿我们刚做完第一轮全链路压测，Redis集群扛住了每秒三万七的请求，K8s的HPA自动扩缩容比闹钟还准，连数据库主从切换的延迟都压到了八十毫秒以内。结果甲方验收前一周，运营突然说“用户反馈登录按钮太小，手机上看容易点错”，产品经理当场拍板：“改！就改这一个按钮！”我盯着UI稿上的“+2px”标注，心里直犯嘀咕——这改动连后端代码都不用动，怎么就成“高可用风险点”了？可甲方爸爸的“就改一点点”，从来都是连锁反应的起点。

　　第二天晨会，前端说“按钮大了得重新调布局”，测试说“布局变了得全回归”，运维说“回归测试得加机器”。我原以为这些都能在两天内搞定，结果产品经理又补了一句：“对了，登录页的背景图也换了吧，用户说太暗。”得，UI稿从“改按钮”变成了“重构登录页”，前端从“调CSS”变成了“切新图”，测试从“回归核心流程”变成了“全量测试”。最绝的是甲方CTO，验收前一天突然问：“你们的高可用方案里，登录页的缓存策略是啥？”我翻出文档指给他看：“静态资源走CDN，动态数据走Redis，TTL设的是五分钟。”他点点头：“那要是背景图换了，CDN缓存怎么清？”我当场愣住——这问题文档里没写啊！

凌晨两点，我在机房里盯着Nginx的配置文件，手机突然震动——甲方财务发来张转账截图，备注写着“尾款已付，请查收”。我盯着屏幕上的数字看了半天，突然想起十二年前第一次接高可用项目时，带我的架构师说过：“尾款到账那天，才是真正的高可用考验开始。”当时不懂，现在懂了——钱到账了，需求就开始“就改一点点”了。

　　那项目最后倒是顺利验收了，但“就改一点点”的连锁反应让我记了十二年。后来我总结了个规律：甲方说的“就改一点点”，90%会变成“得改一整套”，剩下的10%会变成“先改着，后面再优化”。就像去年寒假那个项目，登录页的按钮从“+2px”变成了“重构登录页”，最后连登录接口的限流策略都改了——因为测试发现，按钮大了之后，用户点击频率高了，原来的每秒一千请求的限流不够用了。

　　我原以为高可用是技术问题，结果发现是需求管理问题。十二年前带我的架构师，现在已经是某大厂的CTO了，上次吃饭时他说：“现在的高可用，早不是当年那种‘系统不宕机’了，是‘需求再变态，系统也能扛’。”我夹了口菜，没接话——他说的对，但没说全。系统能扛是一回事，架构师能不能扛是另一回事。就像去年寒假那个项目，要不是我在晨会上拍桌子说“登录页改动必须走变更流程”，估计连数据库连接池都得重新调。

　　上周跟个做SaaS的朋友吃饭，他说他们最近接了个项目，甲方要求“系统可用率99.99%”，结果需求文档里写着“用户中心要支持自定义字段”。我喝了口酒，笑了：“这哪是高可用啊，这是高弹性。”他摇摇头：“弹性个屁，甲方说的‘自定义字段’，最后肯定变成‘每个字段都要能搜、能排、能导出’。”我点点头——这我懂，十二年前我就经历过。

　　现在我再看“高可用”这三个字，第一反应不是“限流、熔断、降级”，而是“需求变更管理”。去年寒假那个项目，要是没扛住甲方的“就改一点点”，别说稳如磐石了，连“不宕机”都悬。所以每次有新人问我“高可用架构怎么设计”，我都说：“先学会说‘不’，再学会说‘得加钱’，最后学会说‘这得走变更流程’。”他们笑我太现实，我笑他们太年轻——等他们扛过三次甲方的“就改一点点”，就知道我说的是实话了。

文章配图，仅供参考

（编辑：站长网）

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