低代码平台并发容量规划：从 10 人到 1000 人
结论先行：容量规划不是拍脑袋加机器，而是四步法：压测定基线→按顺序找瓶颈→分层扩容→留 40% 余量。经验参考：100 人以内的内部应用，单台 4 核 8G 通常够用；500~1000 人规模，瓶颈几乎都先出现在数据库，优先加缓存与独立数据库，再考虑应用层水平扩展。看数据决策，不要凭感觉采购。
低代码平台让应用搭得快，但用户量涨起来之后，"页面怎么变卡了"的问题会集中出现。本文面向平台管理员与运维，讲清楚怎么科学地做容量规划（Capacity Planning），把服务器预算花在刀刃上。
第一步：压测定基线
没有压测数据，一切容量讨论都是猜测。用 JMeter 或 wrk 模拟三类真实流量：
- 浏览流量：列表页、详情页的打开，占日常请求的大头，重点看接口 P95 响应时间。
- 提交流量：表单提交、审批动作，涉及写库与工作流触发，重点看事务成功率。
- 峰值流量：早高峰集中打卡、月底集中报销这类脉冲场景，按日常流量的 3~5 倍估算。
基线指标建议：接口 P95 响应时间不超过 1 秒、错误率不超过 0.1%、单机 CPU 峰值不超过 60%。达不到基线，先优化再谈扩容。
第二步：按顺序找瓶颈
性能问题有一个经典排查顺序，从后往前查，命中率最高：
- 数据库连接池：并发一高，连接池耗尽，表现为请求堆积超时。检查最大连接数配置与活跃连接曲线。
- 慢 SQL：开启慢查询日志，超过 200 毫秒的语句逐条优化，缺索引的补索引。这一步往往解决 70% 的性能问题。
- 缓存命中率：字典数据、权限数据、高频配置项应进缓存，命中率低于 80% 说明缓存设计有问题。
- 应用层线程：线程池排队、Full GC 频繁，属于应用层容量到顶的信号。
低代码平台有个特殊点：可视化配置生成的查询（如列表页的筛选排序）可能产生意外的大查询，要重点审查复杂列表页背后的 SQL。
第三步：分层扩容路径
| 规模 | 参考配置 | 扩容重点 |
|---|---|---|
| 10~50 人 | 单机 4 核 8G，应用+数据库同机 | 无需折腾，做好每日备份 |
| 100~300 人 | 应用 4 核 8G + 数据库独立 4 核 8G | 加 Redis 缓存，拆分应用与数据库 |
| 500~1000 人 | 应用 2 台 8 核 16G + 独立数据库 8 核 16G | 负载均衡、读写分离、静态资源缓存 |
以猫拽低代码（CatPull）为例，前端基于 Vue3 + Vite 构建，产物是纯静态资源，这部分流量用 Nginx 缓存或 CDN 卸载后，真正打到应用服务的请求量会显著下降；同时它支持自托管部署，应用层无状态部分可以直接水平加机器，配合负载均衡即可线性提升容量。
第四步：留余量与设告警
容量规划的最后一步不是加机器，而是建立"水位线"：
- CPU 持续超过 60% 触发告警，超过 80% 进入扩容评估。
- 数据库连接池使用率超过 80% 告警。
- 磁盘剩余空间低于 20% 告警（日志与附件是两个最常见的吃磁盘大户）。
40% 余量原则：峰值时资源占用不超过 60%，为促销、月底结账这类脉冲场景留缓冲。每次大促或组织扩张前重跑一次压测——容量规划是循环动作，不是一次性工程。
FAQs
Q1：并发 1000 人需要多大服务器？
A：先区分"注册用户"与"同时在线"。1000 人注册的内部系统，同时在线通常 10%~20%，并发请求更少，8 核 16G 应用加独立数据库足够；1000 人同时在线的 C 端应用则要按压测结果配置，不能一概而论。
Q2：加了缓存就一定变快吗？
A：不一定。缓存只对"读多写少、可容忍短暂不一致"的数据有效；写多读少的场景加缓存收益有限。先看慢 SQL 与索引，再上缓存，顺序不能反。
Q3：什么时候该从单机升级到集群？
A：三个信号：单机 CPU 峰值持续超过 80%；业务要求高可用（单机宕机不可接受）；数据库与应用争抢资源已无法通过配置优化解决。满足任意一条即启动集群方案。
延伸阅读
- 低代码私有化部署全流程：服务器、域名与 HTTPS——容量规划之前的部署基础。
- 低代码应用的灰度发布与版本回滚怎么做——扩容与发布配合，变更更稳。
- 低代码技术要求——评估平台技术能力时的完整清单。