4. 集群规划与设计：容量规划、硬件选型、网络设计、存储设计、高可用设计
4.1 核心原理：规划是集群生命周期的“第一道防线”
集群故障的根源往往不在运维期，而在规划期。一个在容量、网络或存储架构上存在先天缺陷的集群，后续无论投入多少监控与应急手段，都只能“亡羊补牢”。集群规划的本质，是在业务需求、成本约束与故障风险之间寻找最优平衡点。规划阶段需要回答四个核心问题：需要多少资源？用什么硬件承载？数据如何流动与存储？故障发生时如何继续服务？这四个问题分别对应容量规划、硬件选型、网络与存储设计、高可用设计，它们相互耦合，必须作为一个整体进行决策。
规划黄金法则：以“未来18～24个月业务峰值”为设计基准，而非当前负载。同时为每类资源预留至少30%的冗余缓冲，用于应对突发流量、数据倾斜和故障转移时的资源重分配。
4.2 方法流程：五步规划法
集群规划遵循“采集→预测→映射→验证→迭代”的闭环流程，每一步都有明确的输入与输出。
- 业务指标采集：梳理核心链路的QPS、数据增量、请求延迟分位数（P99）、每日活跃用户数等。例如，一个电商订单系统需要明确大促期间峰值QPS为日常的5～8倍。
- 容量预测建模：根据历史增长曲线（如每季度数据量增长40%）推算未来两年的总量。公式：
目标容量 = 当前容量 × (1 + 增长率)^周期数 × 峰值系数。 - 资源映射：将业务指标转换为物理资源需求。例如：
每秒1万次写入 ≈ 需要8核CPU/32GB内存的节点3台（取决于具体软件栈）。 - 方案选型与设计：结合约束条件（成本、运维能力）确定硬件规格、网络拓扑、存储架构与高可用策略。
- 压测验证与调优：在测试环境模拟峰值流量，验证规划是否满足SLA，找出瓶颈并调整配置。
| 规划步骤 | 关键输入 | 输出物 | 常用工具/方法 |
|---|---|---|---|
| 指标采集 | 业务监控、日志 | 指标清单 | Prometheus、ELK |
| 容量预测 | 历史趋势、业务计划 | 容量模型 | 线性回归、指数平滑 |
| 资源映射 | 基准测试数据 | 资源需求表 | sysbench、fio、wrk |
| 方案设计 | 预算、SLA要求 | 架构设计文档 | 架构评审、TCO分析 |
| 压测验证 | 测试用例、流量模型 | 压测报告 | JMeter、Locust、tc |
4.3 案例/场景：一个金融支付集群的规划实战
某支付平台计划新建一套核心交易集群，要求支撑日均1亿笔交易，峰值TPS 2万，全年可用性99.99%。规划团队按以下步骤执行：
- 容量计算：每笔交易产生约50条日志（每条200字节）和2次数据库写入。峰值TPS 2万意味着数据库写入TPS为4万，日志写入速率约200MB/s。据此估算：需要应用服务器20台（8核32GB）、数据库集群12台（16核64GB）、日志存储每日约17TB。
- 硬件选型：数据库节点选用高主频CPU（3.5GHz以上）+NVMe SSD，确保随机读写IOPS超过10万；应用服务器使用普通SSD即可，但网卡必须采用25GbE，避免网络成为瓶颈。
- 网络设计：采用“Spine-Leaf”两层架构，所有服务器接入25GbE ToR交换机，Spine层使用100GbE互联，跨机架延迟控制在1ms以内。数据库集群与缓存集群之间单独划分VLAN，避免广播风暴。
- 存储设计：数据库采用“本地NVMe + 分布式存储备份”的双层策略——本地盘保证低延迟，分布式存储（如Ceph）提供跨机架副本；日志类数据直接写入对象存储，冷热分层，30天后的日志自动转冷存储。
- 高可用设计：应用层无状态，通过负载均衡多活；数据库采用“一主三从”部署在3个可用区，启用半同步复制；每个可用区独立电力与网络，故障时通过DNS切换流量，RPO≤1秒，RTO≤30秒。
关键决策：该方案初期成本比单机房方案高约35%，但避免了因机房级故障导致的业务中断。上线后经历了一次可用区级别的电力闪断，集群在25秒内完成自动切换，业务无感知，验证了规划的有效性。
4.4 误区/复盘：规划中常见的五个“坑”
即使有完善的流程，规划阶段仍容易陷入以下误区，导致集群交付后频繁故障或资源浪费。
| 误区 | 典型表现 | 后果 | 正确做法 |
|---|---|---|---|
| 只按峰值规划 | 所有资源按最大峰值购买 | 成本浪费40%以上 | 区分“弹性资源”与“固定资源”，峰值部分靠扩容 |
| 忽略数据倾斜 | 假设数据均匀分布 | 部分节点过热，拖垮整体 | 设计分区键时考虑热点，预留拆分能力 |
| 网络带宽估算不足 | 只算业务流量，忽略副本同步、备份流量 | 高峰期网络拥塞，延迟飙升 | 总带宽 = 业务带宽 × 2 + 冗余带宽 |
| 存储只考虑容量 | 忽略IOPS与延迟要求 | 磁盘成为瓶颈，数据库响应慢 | 按IOPS与延迟选型，而非仅看容量 |
| 高可用设计“纸上谈兵” | 只做主备，不演练切换 | 真实故障时切换失败 | 每季度进行故障注入演练，验证RTO/RPO |
复盘案例：某互联网公司曾为节省成本，将数据库与大数据集群部署在同一机架，共享万兆网络。当大数据任务跑批时，瞬间占满带宽，导致数据库主从同步延迟超过5分钟，触发误切换，造成数据不一致。复盘结论：不同重要级的集群必须物理隔离或使用独立网络通道，并建立带宽监控告警。
集群规划不是一次性的静态工作，而是一个随业务演进而持续调整的动态过程。建议每半年进行一次容量复核，每年进行一次全面的架构评审。将规划文档纳入版本管理，每次变更都记录原因与预期效果，形成“规划→建设→运维→复盘→再规划”的正向循环。只有将规划视为一项持续投资，才能让集群在生命周期内始终保持健康、稳定与高效。