高可用架构

一、为什么“能跑起来”不等于“生产就绪”？——我们被凌晨三点的告警教做人 还记得上线首周那个周三凌晨2:47吗？我正裹着毯子刷手机，钉钉弹出第7条红色告警：“ad-bidding-service-03 连接池满，Connection refused”。三分钟后，运维老张发来一张图：黑底白字的终端日志叠着半干的咖啡渍，工牌一角被浸得发软——那张图后来成了我们团队的“耻辱墙”头图。 故障链很短，但后果极重：单点MySQL连接池（HikariCP max=20）被广告计划轮询任务打穿 → 连接堆积阻塞线程池 → Spring Boot Actuator健康检查失败 → K8s liveness probe连续失败 → Pod被批量驱逐 → 新Pod启动又抢连接 → 雪崩。37%的广告计划在11分钟内停投，客户侧CTR数据断崖式下跌。 我们当时最大的错觉，是把“Postman能调通”当成了交付终点。直到被现实按在地上摩擦才明白：“能跑起来”只证明代码没语法错误；“生产就绪”是系统在CPU飙到95%、磁盘IO堵死、网络延迟跳变200ms时，依然能呼吸、能喊疼、能自己止血。 这不是上线后补监控、加熔断的“优化项”，而是架构设计第一天就必须画进图里的生存底线。我们后来用故障时间线倒逼出三大支柱的落地节奏： T+0部署：服务启动成功（/actuator/health 返回UP） T+12h首次OOM：JVM堆外内存泄漏，Prometheus发现process_resident_memory_bytes突增 → 引入-XX:NativeMemoryTracking=detail + jcmd <pid> VM.native_memory summary 定期巡检 T+48h灰度中断：因未配置@SentinelResource(fallback = "defaultBid")，下游画像服务超时直接抛异常 → 全链路强制 fallback 合规检查纳入CI流水线 💡 行动建议：下次写完第一个接口，别急着提测。打开终端，执行这三行： # 模拟连接池耗尽（HikariCP） curl -X POST http://localhost:8080/actuator/health # 查看当前活跃连接数 echo "show status like 'Threads_connected';" | mysql -u root -p -h 127.0.0.1 | grep Threads_connected # 触发一次OOM（仅测试环境！） curl -X POST http://localhost:8080/debug/oom-trigger 如果这三步里有任何一步让你手心冒汗——恭喜，你刚摸到了生产就绪的门槛。 ...