我不会直接画架构图，会先确认目标、规模和一致性要求。从容量、并行度、故障恢复和堆开销规划主分片与副本。主分片决定数据水平切分，副本提供冗余并可分担查询。分片数要让单分片大小、节点分布和故障恢复时间可控，同时避免大量小分片消耗堆、文件句柄和调度资源；副本数根据可用性、查询吞吐与存储成本选择。 主分片数量不是“节点数乘某个固定值”，应使用真实文档、映射和查询压测估算。

容量有了以后，再把入口、核心处理和数据落点串起来。沿着「路由文档到主分片 → 主分片校验并写入 → 并行复制到副本 → 搜索协调各分片 → 故障后副本晋升与重分配」观察输入、状态与输出，这些阶段都可以从日志、指标或源码里验证。 路由文档到主分片 routing 值经哈希映射到固定主分片，主分片数通常不能简单原地修改。 主分片校验并写入 主分片确定操作顺序并执行版本检查，然后把操作复制给当前 in-sync 副本。 OperationRouting：routing 到分片。 cat/shards/cluster/allocation/explain：分片与恢复。 我会先确认请求实际走到了哪条路径，再用运行数据验证，不会只看类名或配置猜测。

关键参数要从峰值流量和资源上限反推。按 5/20/100 分片回放相同数据与并发，比较扇出、堆和恢复时间。

正常链路之外，还要设计失败补偿和可验证的恢复流程。每日数据只有几 GB，却累计数万个小分片，Cluster State、文件句柄和堆开销远大于数据本身。通过模板减少主分片、ILM rollover 按大小滚动并合并历史索引后恢复。 把副本当写扩展：分片大小与数量：按目标 10-50GB 分片验证。 过度分片消耗堆与协调开销：主副本写延迟：副本跨故障域。 固定输入和基线 先在没有故障注入的环境执行上述配置，固定数据规模、并发度、运行时版本和预热时间。以「每请求分片数」为主基线，记录值应满足「记录稳态基线」；同时保存 分片大小与数量、主副本写延迟，使后续变化能够回到同一时间轴比较。

最后再讲扩容、成本和方案边界。方案：更适合的场景：主要收益：代价与边界。 增加主分片：单索引数据/写吞吐需并行：扩展写入和数据分布：查询扇出与固定开销增加。 增加副本：读吞吐和高可用：搜索副本与故障接管：存储、复制与恢复成本。 拆索引/时间流：生命周期与租户边界明确：易管理冷热和删除：跨索引查询与模板治理。 选型至少带上 文档规模、分片数、字段基数、查询并发和写入速率，并用上面的量化基线验证；未知数据应明确为待测假设。