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