3. 单体架构的痛点与扩容困境

在日志平台建设初期，单集群架构凭借部署简单、运维成本低的优势快速上线。然而，随着业务规模增长与日志量激增，单体架构的瓶颈逐渐暴露，成为制约平台稳定性的核心矛盾。本节将系统分析单体架构在索引、磁盘、查询及扩展性四个维度的痛点，并引出分集群改造的必然需求。

3.1 索引性能瓶颈：写入吞吐量受限

单集群中，所有日志流共享同一套索引管道。当业务高峰期（如电商大促、故障恢复）日志产生速率超过集群写入阈值时，索引队列迅速堆积，导致以下问题：

• 写入拒绝：Elasticsearch 协调节点触发 429 限流，客户端重试加剧网络拥堵。
• 分段爆炸：频繁 flush 产生大量小分段，合并线程抢占 CPU，进一步降低写入速度。
• 主副同步延迟：副本分片无法跟上主分片写入速率，集群健康状态变黄甚至变红。

3.2 磁盘 I/O 争抢：读写混合干扰

单体架构下，索引写入、分段合并、查询读取共用同一组磁盘资源。当写入压力大时，磁盘队列深度急剧上升，查询请求因等待 I/O 而超时。具体表现为：

• 写入饥饿：大量小分段合并操作占用随机写带宽，顺序写性能下降 60% 以上。
• 读取抖动：查询请求被 I/O 调度器降级，P99 查询延迟从 500 ms 恶化至 8 s。
• 缓存污染：操作系统页缓存被写入数据频繁替换，热数据命中率从 85% 降至 30%。

# 磁盘 I/O 争抢典型监控指标（iostat 输出）
Device:   rrqm/s   wrqm/s   r/s     w/s    rkB/s    wkB/s  await  svctm  %util
sda       0.00     1200.00  150.00  800.00  4800.00  25600.00  45.00  1.20  99.80
# await 超过 30 ms，%util 接近 100%，磁盘已饱和

3.3 查询延迟升高：资源隔离缺失

单体集群中，所有业务线共享查询资源。一个慢查询（如全量扫描、大聚合）会耗尽线程池和内存，阻塞其他正常查询：

• 线程池耗尽：搜索线程池被慢查询占满，新查询进入队列等待，超时后被丢弃。
• 内存竞争：聚合查询占用大量堆内存，触发 GC 频繁暂停，影响所有查询响应。
• 缓存失效：节点查询缓存被不同业务反复覆盖，命中率从 70% 降至 15%。

3.4 水平扩展受限：单集群协调节点瓶颈

单体集群的协调节点承担全局路由、请求分发、结果归并等职责。随着节点数增加，协调节点成为新的瓶颈：

• 网络扇出：一个查询需要广播到所有分片，协调节点网卡带宽被占满。
• 内存归并：大量查询结果在协调节点内存中排序、聚合，堆内存频繁触发 Full GC。
• 集群状态膨胀：节点数超过 50 后，集群状态更新延迟超过 30 s，元数据不一致风险升高。

3.5 痛点总结与分集群需求引出

单体架构的四大痛点相互叠加，形成恶性循环：索引性能瓶颈导致写入积压，磁盘 I/O 争抢加剧查询延迟，协调节点瓶颈限制水平扩展。当单集群无法通过垂直扩容（增加节点规格）或水平扩容（增加节点数量）解决问题时，分集群架构成为必然选择。