当 Profiling 变成现实检验

Source: Dev.to

部署与意外的延迟

昨天我终于把微服务栈部署到生产环境，却收到用户报告称出现突发的延迟峰值和 429 错误洪流。问题的根源并不是新库或热重载，而是我在构建应用时忽视的一个简单的“交接”。

开发与生产设置的差异

在开发时，我只在笔记本上跑了一个实例，因此数据库连接池大小、缓存淘汰策略以及 HTTP 客户端重试次数都被设定为本地最佳性能。但在真实的横向可扩展环境中，这些硬编码的数值反而成了瓶颈：

• 连接池限制了所有工作线程，
• 内存缓存被填满后触发垃圾回收，
• 重试逻辑把空闲的网络时间转化为级联故障。

深刻教训

深刻教训： 永远要为集群而不是笔记本电脑进行优化。编写能够启动多个实例或模拟负载的测试，并对整个系统进行剖析，而不仅仅是单个组件。即使是请求处理器中的一个简单 time.sleep 也可能暴露共享缓存中的隐藏竞争条件，而一个无限循环则会在节点池上卡住事件循环。

监控与预演

添加一个小的“底层”监控，报告连接池使用情况、缓存命中率和重试次数，结果证明这是在系统崩溃前捕获问题的最快方式。简而言之，把你的预演环境当作生产的真实副本，让指标在你正式上线前揭示真实世界的约束。