后端架构师亲历：12个容器高可用真相

　　去年中考那几天，运维群里突然炸锅——某教育平台QPS暴涨三倍，容器集群直接跪了半数。我原以为又是负载均衡策略没调好，结果扒了日志才发现，是某个后端架构师坚持用的“优雅降级”方案，把健康检查阈值设得比实际资源还高。那场面，监控大屏上红绿交替的警报，跟中考考场外家长举的应援牌似的，晃得人眼晕。

　　当时我在工位上啃着冷掉的煎饼果子，群里@我的消息叮咚响个不停。那架构师还在嘴硬，说“高可用不是靠堆机器，是靠容错设计”。我直接甩了张截图——他所谓的“容错”，是把故障探测间隔从十秒改成了三十秒，结果容器刚挂，健康检查还没触发，流量已经把剩下的节点冲垮了。这哪是容错？这是把错误捂在被窝里等它发酵。

　　后来复盘的时候，我盯着那十二条他总结的“高可用真相”，第一条就写着“优胜劣汰：让不健康的容器自然淘汰”。我差点把咖啡喷在键盘上——自然淘汰？中考期间每秒几千的请求，你跟我说让容器慢慢死？这就像说“火灾来了别慌，等火把房子烧完自然就灭了”。他可能没想过，容器挂掉的瞬间，流量会像潮水一样涌向其他节点，那些“健康”的容器，可能下一秒就被压垮了。

　　不过话说回来，他那套“优胜劣汰”的逻辑，在平时确实有点道理。比如我们之前遇到过一个场景，某个容器的CPU使用率突然飙到90%，但健康检查没报错（因为阈值设得高）。如果是他的方案，这容器会继续接收流量，直到彻底挂掉，然后被K8s重新调度。但现实是，等它挂掉的时候，下游服务可能已经积压了上万请求，恢复时间直接从秒级变成分钟级。我后来改了策略，把健康检查和资源监控绑在一起，CPU超过80%就标记为不健康，直接踢出负载均衡池。那架构师还说我“过度干预”，结果下次大促，他的方案又坑了一次——这次是内存泄漏，容器没挂，但响应时间从200ms涨到2秒，健康检查依然没触发。

　　说到这，我想起上周三下午，机房空调突然坏了，温度飙到40度。监控群里跳了条报警，说某节点CPU温度过高。我原以为只是硬件问题，结果查了一圈，发现是容器里跑的一个Java服务，GC策略没调好，老年代占满后频繁Full GC，CPU直接打满。那架构师又在群里说“这是预期内的性能波动，不用处理”。我直接远程登录，把GC参数改了，三分钟后CPU使用率从95%掉到30%。他后来私聊我，说“你这样会破坏系统的自愈能力”。我回他：“自愈的前提是得先活着，你都快烧成炭了，还自愈个屁。”

　　其实他那十二条“真相”里，有几条我挺认同的。比如“避免单点故障”，这确实是高可用的基础。但问题在于，他总把“避免单点”和“自然淘汰”混为一谈。比如他主张用多个小集群代替单个大集群，说这样“故障影响范围小”。我原以为他是怕大集群崩溃后恢复慢，结果他说“小集群挂了，流量会自动转到其他集群，符合优胜劣汰”。可现实是，我们的业务有状态依赖，流量转过去后，用户会话可能就断了，体验直接崩盘。后来我们改用多可用区部署，配合全局会话同步，才算解决了这个问题。他到现在还在说“多可用区太复杂，不如小集群简单”，可简单不代表可靠啊。

文章配图，仅供参考

　　其实有时候我也挺困惑的。高可用到底该怎么做？是像他那样，相信系统能自己“优胜劣汰”，还是像我这样，主动干预，把风险扼杀在萌芽里？我原以为答案很明确，可越干越觉得，这行没有绝对的对错。比如他那套“自然淘汰”，在资源充足、流量平稳的时候确实能跑通，但遇到突发流量或者硬件故障，分分钟教你做人。而我这种“过度干预”的风格，虽然能避免大部分问题，但一旦判断失误，也可能把小问题变成大事故。比如上次我把一个容器的资源限制调得太紧，结果它因为OOM被K8s杀掉了，反而引发了连锁反应。

　　现在想想，高可用可能就像走钢丝——太松会掉下去，太紧会绷断。那架构师的“优胜劣汰”，就像是在钢丝上闭着眼睛走，说“我相信自己的平衡感”；而我的“主动干预”，就像是在旁边扶着栏杆，说“我怕摔”。哪种更好？我说不准。但至少我知道，闭着眼睛走的人，摔下来的概率肯定更高。至于扶栏杆的人，虽然累点，但至少能活着走到终点。

（编辑：站长网）

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