一套监控系统接入的项目越来越多以后，我们发现服务端开始丢失数据。
初步判断并不复杂：上游持续写入，服务端消费能力没有跟上。通常遇到这种情况，最直接的方案是增加机器或提高配置。
但当时的监控显示，机器 CPU 和内存都没有达到瓶颈。系统处理不过来，资源却没有被充分使用。
资源指标没有解释全部问题
CPU 使用率不高，并不意味着程序还有等比例的处理能力。
一次处理可能受到单线程、锁竞争、队列、网络连接或固定任务模型限制。只要关键路径无法并行，增加更多空闲核心也不会自动提高吞吐。
我们的数据处理流程中，项目指标会进入一个分析节点。随着数据增长，单个分析节点逐渐成为串行瓶颈。其他资源仍有余量，但关键处理路径已经无法继续扩展。
这也解释了为什么直接增加相同机器不一定有效：如果数据仍然落到同一个分析节点，新增资源没有进入受限路径。
从单分析节点变成分析器组
最终的改造思路，是把单个分析节点扩展为一组可配置的分析器。
项目按照稳定规则选择其中一个分析器，同一项目的数据仍然进入固定节点，不同项目则能够分散处理。分析器数量可以根据总量调整，消费能力不再受单节点限制。
改造以后，单位时间处理能力提高了约一半，数据丢失问题也得到控制。后续开源版本采用了相近的扩展方式，侧面验证了这个方向。
为什么没有一开始这样设计
回头看，水平扩展是很自然的答案。但系统早期数据量有限，单节点结构更简单，开发和运维成本也更低。
为所有可能增长提前设计复杂扩展能力，并不一定合理。真正需要做的是知道单节点方案的上限，并在数据接近边界时能够观察到。
这次问题的不足，不在于最初选择单节点，而在于容量增长以后，对关键路径的处理上限缺少提前验证。
性能问题先找受限路径
资源监控仍然重要，但它只能说明一部分现象。
遇到吞吐不足时，应该继续确认请求在哪个阶段排队，哪些任务能够并行，哪些状态要求串行，以及增加资源是否真正进入瓶颈路径。
扩容是一种手段，不是诊断结论。机器是否繁忙，与系统是否还能处理更多数据，并不总是一回事。