4. 业务需求分析与容量规划
在完成集群总体架构选型之后，真正决定硬件规格、节点数量、网络带宽和存储容量的，不是技术偏好，而是业务需求。业务需求分析与容量规划的核心任务，是把“业务部门说出来的期望”翻译成“集群可以落地的量化指标”。这一节围绕业务连续性、性能和扩展性三条主线，说明如何完成需求调研，并给出初步容量估算的方法。
一、从业务语言到技术指标
业务方通常不会说“我需要 99.99% 可用性”，而是说“这套系统不能停，停了会影响生产”。需求调研的第一步，就是把这些模糊表述转成可度量的技术指标。常用的转换维度包括：
- 业务连续性：允许中断的时间窗口、RTO（恢复时间目标）、RPO（恢复点目标）、是否需要同城双活或异地容灾。
- 性能：并发用户数、峰值 TPS/QPS、单笔交易响应时间上限、批处理窗口时长。
- 扩展性：未来 1～3 年业务增长率、是否需要在线扩容、扩容粒度是节点级还是机柜级。
- 合规与约束：数据驻留要求、等保级别、备份保留周期、审计日志保存时间。
调研时建议采用“业务访谈 + 现有系统监控数据 + 历史工单”三源交叉验证。业务访谈给出目标，监控数据给出当前基线，历史工单暴露真实故障模式。三者结合，才能避免把需求估得过高或过低。
二、业务连续性需求分析
业务连续性需求直接决定集群的冗余层级。可以按以下顺序逐层确认：
- 业务是否允许计划内停机？若允许，窗口多长？
- 单节点故障时，业务是否必须无感知？
- 单机柜或单可用区故障时，业务是否必须继续运行？
- 发生区域性灾难时，可接受的 RTO 和 RPO 分别是多少？
例如，某制造企业 MES 系统要求：单节点故障无感知，单机柜故障时 30 分钟内恢复，RPO 不超过 5 分钟。这意味着集群至少需要跨机柜部署，数据库层需要同步或半同步复制，且备份策略必须支持时间点恢复。若业务方回答“停机 4 小时也可以接受”，则不必为极致冗余付出成本，可以把预算投向性能或扩展性。
三、性能需求与容量估算
性能需求分析的关键是找到“峰值”而不是“平均值”。容量规划若按平均负载设计，遇到业务高峰必然过载。建议按以下步骤估算：
- 收集当前系统的日均请求量、峰值请求量和峰值持续时间。
- 根据业务增长率，推算未来 1～3 年的峰值。
- 将峰值请求量换算为集群需要承载的 TPS/QPS。
- 结合单节点处理能力，计算所需节点数，并预留冗余。
下面给出一个教学示例。假设某业务系统当前日均请求 200 万次，峰值集中在 2 小时内，峰值请求量约为日均的 30%，即 60 万次。峰值 TPS 约为 600000 ÷ 7200 ≈ 83。若业务年增长率为 40%，三年后峰值 TPS 约为 83 × 1.4³ ≈ 228。若单节点在目标响应时间内可稳定处理 80 TPS，则至少需要 3 个节点承载，再考虑 N+1 冗余，实际部署 4 个节点。若要求跨机柜冗余，则每个机柜至少 2 个节点，共 4 个节点分布在 2 个机柜。
存储容量估算同样需要区分“原始数据量”和“可用容量”。以数据库为例，若当前数据量为 2 TB，年增长 40%，三年后约 5.5 TB。考虑索引、临时表、日志和备份，实际占用通常是原始数据的 2～3 倍，即约 11～16 TB。若采用三副本，则物理容量需求约为 33～48 TB。若再考虑快照和备份保留，建议按 60 TB 规划。
四、扩展性需求分析
扩展性需求决定集群的“生长方式”。需要确认：
- 扩容是纵向（加 CPU/内存）还是横向（加节点）？
- 扩容是否需要停机？能否在线完成？
- 扩容的最小单位是什么？单节点、单机柜还是整组？
- 网络、存储、供电是否预留了扩展空间？
例如，若业务预计每年增长 40%，且要求在线扩容，则集群应选择支持横向扩展的分布式架构，并在初始规划时预留至少 30% 的机柜空间、网络端口和供电余量。若采用传统主备架构，纵向扩展很快会遇到单机上限，后期改造成本极高。
五、需求调研与容量估算的落地流程
把上述分析串起来，可以形成一条从调研到估算的完整链路。下图展示了业务需求如何逐层转化为集群的量化配置：
六、需求调研表与容量估算表
为了让调研结果可追溯、可评审，建议直接使用结构化表格记录。以下是一份可直接参考的示例，字段可根据项目实际情况增删。
| 调研项 | 业务描述 | 量化指标 | 对集群的影响 |
|---|---|---|---|
| 业务连续性 | 单节点故障无感知，单机柜故障 30 分钟内恢复 | RTO ≤ 30min，RPO ≤ 5min | 跨机柜部署，数据库半同步复制 |
| 性能峰值 | 峰值集中在 2 小时，峰值请求量为日均 30% | 当前峰值 TPS ≈ 83，三年后 ≈ 228 | 至少 3 节点承载，N+1 后 4 节点 |
| 存储容量 | 当前数据 2TB，年增长 40% | 三年后原始 5.5TB，含副本约 33～48TB | 按 60TB 物理容量规划 |
| 扩展性 | 要求在线扩容，年增长 40% | 预留 30% 机柜、端口、供电余量 | 选择支持横向扩展的分布式架构 |
| 合规约束 | 数据本地驻留，等保三级 | 日志保留 180 天，备份保留 1 年 | 增加备份存储和审计日志容量 |
需要强调的是，上述数字均为教学示例，实际项目中必须用真实监控数据和业务访谈结果替换。容量估算的精度不要求一次到位，但必须做到“有依据、可复核、可调整”。建议在估算表中同时记录假设条件，例如“假设年增长率为 40%”“假设单节点稳定处理 80 TPS”，这样当假设变化时，可以快速重新推算。
七、评审与确认
需求调研和容量估算完成后，必须组织业务方、运维方和架构方共同评审。评审重点不是数字是否精确，而是假设是否合理、冗余层级是否匹配业务连续性要求、扩展预留是否足够。评审通过后，输出《集群需求规格说明书》和《初步容量估算表》，作为后续详细设计和设备选型的输入。若评审中发现业务方对 RTO/RPO 的回答前后矛盾，应回到业务访谈重新确认，而不是在技术侧强行折中。
至此，业务需求分析与容量规划完成了从“业务语言”到“技术指标”的转化，为后续的集群详细设计、设备选型和部署实施提供了可量化、可验证的依据。