资源规划建议

1. 文档目的

本文档用于指导私有化部署场景下的服务器与中间件资源规划，供实施工程师、运维工程师及售前技术支持人员参考。

文档内容基于历史项目容量规划、样例配置和中间件基线整理形成，可用于售前测算、资源申请、实施部署及后续扩容评估。

2. 适用范围与使用说明

2.1 适用范围

本文档适用于私有化部署场景下，不同用户规模对应的应用节点与中间件资源初步规划。

2.2 使用说明

本文档中的配置均为建议配置，用于项目初期容量评估与资源规划。

应用节点资源与中间件资源应分别测算，不建议混合规划。

大规模用户场景下，中间件资源需结合业务峰值、并发模型、容量压测结果及生产监控数据进一步校准。

正式生产环境建议预留扩容余量，并优先采用高可用建设方式。

如采用国产 CPU 架构服务器，建议按标准规格的 2 倍进行整体资源估算。

3. 规划原则

3.1 应用与中间件部署原则

1 万以下用户场景，可结合项目实际情况评估是否将部分中间件部署在 K8s 集群内部。

1 万及以上用户场景，建议应用节点与中间件完全分离部署。

数据库、缓存、消息队列、检索服务等核心中间件，建议优先采用高可用架构部署。

条件允许时，建议优先使用成熟的公有云托管中间件服务，以提升稳定性和可维护性。

3.2 对象存储规划原则

优先采用公有云对象存储服务，如阿里云 OSS、华为云 OBS、腾讯云 COS、AWS S3。

若采用私有化部署对象存储，必须使用 SSD 磁盘，还需重点评估容量增长后的性能、稳定性与运维可控性。

若业务存在大量大文件上传、下载、预览、大表格多人协作编辑场景，建议优先使用独立对象存储服务。

4. 应用节点规划

4.1 应用节点规格划分

规格 A

推荐规格：24C / 48G / >=500G SSD * N

适用范围：1 万以下用户

适用特点：

可支撑中小规模业务场景

中间件可视项目情况部署在 K8s 环境内

单节点承载较高，节点异常时影响范围相对较大

规格 B

推荐规格：16C / 32G / >=300G SSD * N

适用范围：1 万及以上用户

适用特点：

适合规模化、高可用部署场景

必须使用独立中间件

采用小规格多节点方式，调度更均衡，扩缩容更灵活

节点维护或异常时，对整体业务影响更小

4.2 应用节点测算口径

根据既有项目样例与容量测算规则，应用节点建议按以下公式预估：

节点数 = 用户数 × 0.03 ÷ 160

可简化理解为：

节点数 ≈ 用户数 ÷ 5300

其中：

并发用户系数按 0.03 估算。

单台 16C / 32G 节点承载能力约为 150 ~ 180 QPS。

建议按 160 QPS/节点 作为测算基准。

测算结果建议向上取整，并额外预留扩容余量。

4.3 应用节点推荐配置表

用户规模（人）	节点规格	推荐数量	部署建议
500	24C / 48G / 500G SSD	1 台	可单机部署；如需高可用，建议至少 3 台服务器部署
3000	24C / 48G / 500G SSD	3 台	集群模式，高可用部署（集群部署的最低规格阈值）
1 万	24C / 48G / 500G SSD	3 台	集群模式，高可用部署；可结合项目情况评估使用外部中间件
3 万	16C / 32G / 300G SSD	5 台	集群模式，高可用部署，使用独立中间件
5 万	16C / 32G / 300G SSD	10 台	集群模式，高可用部署，使用独立中间件
10 万	16C / 32G / 300G SSD	18 ~ 20 台	建议按 18 台起配，并预留扩容余量，使用独立中间件
20 万	16C / 32G / 300G SSD	38 ~ 40 台	建议分阶段建设与投产
30 万	16C / 32G / 300G SSD	56 ~ 60 台	建议分阶段建设与投产
50 万	16C / 32G / 300G SSD	94 ~ 100 台	建议独立资源池规划，分阶段建设与投产
70 万	16C / 32G / 300G SSD	132 ~ 140 台	建议独立资源池规划，分阶段建设与投产

4.4 应用节点规划结论

1 万以下用户建议采用规格 A。

1 万及以上用户建议采用规格 B。

10 万用户规模可按样例锚点 18 台起配，其余规模按统一公式估算并向上取整。

对于持续增长型项目，建议按阶段性扩容策略推进建设，避免一次性过量投入。

5. 中间件规划

5.1 中间件分档原则

当前中间件资源规划按两档基线执行：

3000 以下用户：采用小规模基线配置。

3000 及以上用户：采用大规模基线配置。

对于 1 万、3 万、5 万、10 万、20 万、30 万、50 万、70 万等更大规模场景，建议统一按“3000 及以上用户”基线起配，并结合业务增长情况动态扩容。

5.2 中间件规格基线表

中间件	推荐版本	3000以下用户	3000以上用户	高可用要求
MySQL	MySQL 8.0	4C / 8G / 200G SSD	8C / 16G / 200G SSD	主从切换高可用字符集：utf8mb4 时区：Asia/Shanghai 或 UTC 连接数：max_connections ≥ 1000
MongoDB	MongoDB 4.4	2C / 8G / 100G SSD	4C / 16G / 100G SSD	副本集高可用集群
Redis	Redis 6.2.21	2C / 4G / 100G SSD	2C / 8G / 100G SSD	主从/哨兵高可用，数据持久化；不支持 Cluster 模式的集群；DB 数需 >= 64
Kafka	Kafka 3.5	2C / 4G / 300G SSD	4C / 8G / 300G SSD	broker >= 3，默认副本数 3 消息保留：72 小时（可根据业务需求调整） Topic 最大单条消息大小：10 MB 鉴权：支持 SASL 加密访问（PLAIN、SCRAM-SHA-256、SCRAM-SHA-512）
Elasticsearch	ES 8.18.5	2C / 4G / 200G SSD	4C / 8G / 200G SSD	节点数 >= 3 必需安装： analysis-ik（中文分词）、 analysis-pinyin（拼音分词） SDK 产品不需要部署 Elasticsearch
对象存储	S3 协议兼容	兼容 S3	兼容 S3 协议	优先公有云，需对外支持 HTTPS访问

说明：

以上中间件规格需要根据实际负载按需扩容

6. 实施与运维建议

6.1 部署实施建议

MySQL、MongoDB、Redis、Kafka、Elasticsearch 建议优先采用高可用集群模式部署。

条件允许时，建议优先使用公有云托管数据库和中间件服务，以提高稳定性和可维护性。

1 万及以上用户场景，建议应用节点与中间件分离部署。

Kafka 建议使用独立实例，避免与其他业务共享资源。

6.2 对象存储实施建议

推荐优先采用公有云对象存储产品。

若采用私有化对象存储，必须使用 SSD 磁盘。

若团队空间存在大量大文件上传、下载、预览场景，应将对象存储容量、吞吐和带宽作为重点评估项。

6.3 扩容关注点

在以下业务场景下，建议优先评估并追加中间件资源：

大量附件上传、下载、预览

高频全文检索

消息堆积或异步任务密集

高峰期批量写入、统计分析

日志量持续增长

重点关注指标包括：

数据库：CPU、内存、磁盘 IO

Redis：连接数、命中率、带宽使用率

Kafka：Broker 数量、消息堆积、磁盘空间

Elasticsearch：节点数、索引规模、存储容量

对象存储：读写性能、请求吞吐、容量、带宽

7. 结论

小规模场景（1 万以下用户）建议采用规格 A 应用节点配置，可结合项目情况评估是否将部分中间件部署在集群内部。

中大规模场景（1 万及以上用户）建议采用规格 B 应用节点配置，并配套独立中间件与高可用架构。

中间件建议按“3000 以下用户”和“3000 及以上用户”两档基线起配，大规模项目在此基础上结合压测与监控数据持续扩容。

正式实施前，应同时完成资源规划确认、兼容性校验和容量压测，避免部署规格与实际支持范围不一致。

若采用国产 CPU 架构服务器，建议按标准规格的 2 倍进行资源预估。

本说明用于安装前选型，不替代现场压测与最终实施定版。

1. 文档目的#

2. 适用范围与使用说明#

2.1 适用范围#

2.2 使用说明#

3. 规划原则#

3.1 应用与中间件部署原则#

3.2 对象存储规划原则#

4. 应用节点规划#

4.1 应用节点规格划分#

规格 A#

规格 B#

4.2 应用节点测算口径#

4.3 应用节点推荐配置表#

4.4 应用节点规划结论#

5. 中间件规划#

5.1 中间件分档原则#

5.2 中间件规格基线表#

6. 实施与运维建议#

6.1 部署实施建议#

6.2 对象存储实施建议#

6.3 扩容关注点#

7. 结论#