企业即时通讯系统选型：容量与并发能力怎么评估

选型会上，厂商说系统支持万人同时在线，听起来足够。真到上线，早高峰登录排队、全员通知延迟、视频会议卡顿，问题才暴露。原因往往不是谁故意含糊，而是双方说的“支持”不是同一件事。企业即时通讯系统的容量评估，不能只看一个数字，要把它拆成用户数、连接数、消息并发、群扩散、带宽和存储，再放回自己的使用场景里验证。

我参与过几次私有化 IM 的选型，常见的分歧是采购按员工总数问配置，运维按在线人数算资源，厂商按实验室峰值报容量。三套口径对不上，项目就很难验收。下面这套方法，目的就是把三套口径拉到同一张表上。

一、先分清四个数

容量讨论的第一个障碍，是“用户”这个词太模糊。至少要把四个数分开看。

• 注册用户：系统里建了多少账号，包含离职未删、长期不登录的账号。
• 在线用户：某一时刻成功登录并保持连接的账号数。
• 并发连接：服务端实际维持的长连接数。一个人用电脑和手机同时在线，就会占两条连接。
• 消息并发：单位时间内发送的消息数；如果看服务端实际投递量，还要乘以每条消息的接收方数量。

厂商宣传的“支持 X 人”，可能指注册用户、在线用户、并发连接，也可能指特定硬件和特定消息模型下的测试值。没有说明测试条件，这个数字无法直接比较。

举个简单的例子。5000 个账号，高峰在线率 60%，就是 3000 人在线；平均每人 1.5 台设备在线，连接数约 4500。假设高峰期人均每秒发 0.05 条消息，发送量约 150 条/秒。看起来不大。但一个 500 人群里，如果每秒有 10 条消息，服务端要投递 5000 条/秒；一条全员通知发给 1000 人，瞬间就是 1000 次投递。 群消息扩散会把“发送并发”放大成另一个数量级的“投递并发”。

所以，容量不是“能装多少人”，而是在指定硬件、网络、消息模型、群规模、延迟和成功率要求下，能稳定支撑多少负载。 “支持多少人”只有在说明测试条件后才有比较意义。

二、把企业规模换算成容量需求

企业 IM 的容量评估，先把业务量换算成负载。不需要多复杂的模型，先把几个关键量算出来。下面这组公式可以用 Excel 完成，假设值必须来自你们自己的历史数据或试点，不能直接套行业平均值。

指标	估算方式	需要的数据
峰值在线用户	总账号 × 峰值在线率	历史登录曲线、班次、移动办公比例
峰值连接数	峰值在线用户 × 平均在线设备数	电脑、手机、平板同时在线情况
消息发送 TPS	峰值在线用户 × 人均发送条数/秒	高峰时段消息量
消息投递 TPS	单聊发送×2 + 群消息发送×群成员数×群内在线比例	群规模分布、活跃群数量
音视频带宽	并发会议路数 × 单路码率	会议数量、参会人数、是否开摄像头
存储年增量	日增消息与文件 × 留存天数 × 副本备份系数	文件平均大小、留存政策、备份策略

以 5000 个账号为例，假设高峰在线率 60%、平均 1.5 台设备在线、高峰人均每秒发送 0.05 条消息、有一个 500 人群每秒产生 10 条消息、每天新增文件 10GB、留存 3 年。算下来是 3000 人在线、4500 条连接、150 条/秒发送、5000 条/秒群投递；文件原始数据约 11TB，按两份副本加备份规划，存储要按 30TB 量级考虑。

这些数字是示例，不是行业标准。真正有价值的是把假设换成你们自己的数据，再做一次敏感性分析：在线率提高 10 个百分点、群规模翻倍、留存从 1 年改成 3 年，分别会把哪一项资源先压满。 先找到更敏感的那个变量，再决定配置和测试重点。

音视频要单独算。喧喧IM 官方给出的单路估算口径是，音频会议每人约 0.5Mbps，音视频会议每人约 1Mbps；音视频服务器建议带宽 8Mbps 以上。前者用来估算会议室总带宽，后者是服务器的基础建议值。100 人同时开音视频，按单路口径要按 100Mbps 量级规划，多间会议室还要累加。最终以实测码率为准。音视频会议的并发能力，可以对照 音视频会议页面的说明。

三、评估容量时该看哪些指标

即时通讯的并发能力，最终要落到连接、消息、资源和稳定性四层指标上。只看连接数，容易漏掉消息层的瓶颈；只看消息延迟，又可能忽略资源水位和故障恢复。

1. 连接层

• 最大并发连接数。
• 登录成功率、连接建立成功率。
• 断线重连成功率，以及重连风暴下的恢复时间。
• 心跳占用的内存和带宽。

2. 消息层

• 发送 TPS、投递 TPS。
• 端到端延迟，至少看 P95 和 P99。
• 投递成功率、错误率、超时率。
• 重复、乱序、离线消息补全、多端同步。
• “消息必达”要定义清楚，是在线送达、离线存储，还是多端已读同步。

3. 资源层

• CPU、内存、磁盘 IO、带宽利用率。
• 消息队列积压、数据库连接池、GC 频率。
• 单连接内存开销、文件描述符使用率。

4. 稳定性

• 24-72 小时长稳，内存是否持续增长。
• 连接是否泄漏。
• 服务重启、节点故障、网络中断后的恢复时间。
• 限流、降级、告警是否有效。

平均延迟会掩盖长尾。用户不会记住平均 200ms，只会记住那几次 5 秒才到的消息。 容量评估要看“在什么延迟和成功率下支撑多少负载”，而不是只看最大连接数。

端到端延迟的定义也要统一。是从发送方点击发送，到接收方看到消息，还是只算服务端处理时间？前者包含网络和客户端渲染，更接近用户体验；后者适合定位服务端瓶颈。验收时写清楚口径，避免各说各话。

四、厂商说“支持万人”，要让它拿出什么证据

厂商的公开参数可以作为初筛，但进入候选后，要拿到能复现的证据。可以让厂商提供最近一次压测报告，重点看以下内容。

• 测试条件：软件版本、部署拓扑、服务器配置、操作系统和数据库、网络带宽、客户端类型。
• 业务模型：消息大小、单聊与群聊比例、群规模分布、在线比例、多端比例、文件传输占比、测试时长。
• 测试结果：最大稳定连接、发送 TPS、投递 TPS、P95/P99 延迟、成功率、错误率、CPU/内存/带宽水位。
• 瓶颈说明：先压满的是哪一层，消息队列、数据库、网关还是带宽；过载后如何限流和降级。
• 测试性质：实验室还是生产环境，单机还是集群，是否测到性能拐点，报告日期和版本是否对应。

有些报告只写“支持 10 万并发”，不写消息频率、群规模和延迟要求。这种数字只能说明连接层曾经建立过这么多连接，不能说明你们的全员通知和大群讨论也能按时送达。 没有测试条件的“支持 X 人”，只能当参考，不能当承诺。

还要区分“能扩展”和“现在能扩”。横向扩展是否需要停机、是否要改部署架构、数据库和文件存储是否支持、许可费用是否增加、运维复杂度是否可控，这些都要在选型阶段问清楚。否则上线后遇到瓶颈，才发现扩展是一条长周期改造。

五、用 POC 把容量变成可验收的数字

POC 本质上是一次针对你们场景的 IM 压力测试，不是看厂商演示一遍功能。场景不用多，但要覆盖会压垮系统的几个点。

1. 登录洪峰

让 80% 以上的账号在 10 分钟内集中登录，观察登录成功率、登录耗时、连接建立速度和失败重试。早高峰容易暴露连接层瓶颈。

2. 日常混合聊天

按真实比例混合单聊、小群、文件、图片和消息检索，持续 1-2 小时。这个场景的负载不一定最高，但更能反映日常体验。

3. 大群和全员通知

用 500、1000、5000 人的群分别发消息，观察投递延迟、队列积压和失败率。全员通知要单独测，因为一条消息可能触发几千次投递，和日常聊天不是一个量级。

4. 文件传输

并发上传大文件，观察吞吐、磁盘 IO、带宽占用，以及对同时进行的消息收发的影响。文件传输把磁盘和带宽一起压上来，很多项目在这里才看到瓶颈。

5. 音视频会议

按最大并发会议数和参会人数开会，观察 CPU、带宽、丢包和卡顿。会议室数量、是否开摄像头、是否共享屏幕，都会改变结果。

6. 弱网和断网重连

模拟网络中断、延迟和丢包，恢复后检查消息是否补全、是否重复、多端是否一致。移动办公和分支机构场景要重点测。

7. 长稳和故障恢复

以 70%-80% 的峰值负载跑 24-72 小时，观察内存、连接数和延迟是否漂移；再重启服务或断开节点，检查恢复时间和数据一致性。

验收标准可以按业务体验来定，下面是一组示例，不是统一标准。

指标	示例目标	测试方法
登录成功率	≥99.9%	登录洪峰
消息投递成功率	≥99.9%	日常与大群
P95 端到端延迟	≤1 秒	日常消息
P99 端到端延迟	≤2 秒	大群与峰值
错误率	<0.1%	全场景
峰值 CPU 利用率	<70%-80%	资源监控
24 小时内存增长	<5%	长稳测试

压测时还要避免测试工具自己成为瓶颈。客户端机器数量、网络带宽、脚本并发模型、消息大小和思考时间，都会影响结果。建议用多台压测机分布式施压，同时监控服务端和客户端。 POC 的产出不是一份演示记录，而是一张能写进验收单的指标表。

六、私有化部署还要算清服务器、带宽、存储和运维

私有化部署即时通讯，基础设施责任在企业。即时通讯服务器配置不能只看 CPU 和内存，软件能装起来只是第一步，服务器、带宽、存储和运维要一起算。

喧喧IM 官方给出的 5000 用户规模参考配置是，xxb 服务器 16G 内存、8 核以上；xxd 服务器 16G 内存、8 核以上；音视频服务器 8 核以上，建议带宽 8Mbps 以上。官方明确不建议更低的配置，过低会影响稳定性和性能。磁盘和带宽主要看图片、附件的数量和大小。实际项目要以官方文档和 POC 结果为准。部署步骤和版本要求可以查 安装升级手册。

网络环境通常有两种。服务器具备公网 IP，客户端通过公网访问；或者企业只允许内网访问，服务器不连外网，客户端全部在内网使用。两种模式的带宽、移动办公和远程接入设计不同，不能混着算。需要私有化部署的完整方案，可以看 私有化部署。

存储是容易被低估的部分。消息、文件、索引、备份都要占空间，留存时间越长、文件越大，增长越快。按日增数据乘以留存天数，再乘副本和备份系数，最后留 30%-50% 的余量。上线前做一次恢复演练，确认备份真的能恢复，否则备份只是占空间。

运维也要计入成本。监控项至少包括连接数、消息 TPS、延迟、队列积压、CPU、内存、磁盘和带宽；备份、升级、扩容、审计和故障处理都需要人。TCO 不只是软件许可，还包括服务器、带宽、实施、集成、运维、升级、迁移和退出成本。 私有化部署的成本大头，常常不是软件许可，而是存储、带宽和长期运维。

七、不同部署形态，容量评估的重点不同

企业即时通讯系统大致分三条路线，公有云 SaaS、私有化商业 IM、开源 IM。三条路线的容量责任不同，评估方法也不一样。

1. 公有云 SaaS

基础设施由厂商承担，企业不需要自己买服务器，但不等于不用评估容量。要确认服务等级协议、套餐限额、API 调用配额、消息和文件存储上限、数据导出方式，以及私有化版本和 SaaS 版本的能力边界。业务高峰期如果触发限流，体验同样会受影响。

2. 私有化商业 IM

企业自己承担服务器、带宽、存储和运维，所以要拿到可复现的压测报告，并在自己的环境里做 POC。厂商的架构、交付能力和运维支持，都会影响长期容量。

以喧喧IM 为例。它是禅道软件（青岛）集团有限公司研发的企业级私有化即时通讯与协同平台，服务端采用 XXB、XXD、XXC 三层结构。XXB 负责业务与数据，XXD 用 Go 处理高并发消息收发和文件传输，XXC 是基于 Electron 和 React 的跨平台客户端。官方口径支持 10000+ 用户同时在线，音视频会议支持百人规模。

喧喧IM 支持私有化部署，可以部署在具备公网 IP 的服务器，也可以放在纯内网；信创方面适配银河麒麟、统信 UOS、Deepin 等操作系统，以及申威、鲲鹏、兆芯、海光、飞腾、海思盘古、龙芯等国产 CPU。架构轻量指的是部署和资源占用，不是功能减配，即时聊天、音视频会议、文件协同等能力同样完整，具体可以看 即时聊天页面的说明。

适用条件也要说清楚。喧喧IM 更适合对数据安全、私有化部署、信创适配有要求的企业和研发团队；选择它意味着企业要自己准备服务器、网络和运维。如果业务有特殊的部署架构、容灾或合规要求，建议在 POC 中单独确认支持范围，不能只看公开参数。

版本上，开源版源码开放，适合先验证核心功能、具备一定技术能力的团队；专业版面向更高的企业级需求。两者的差异可以看 开源版页面的说明。

3. 开源 IM

开源 IM 的优势是可控、可改造，成本结构也不一样。代价是容量责任在企业自己身上，压测、调优、升级、插件兼容、安全补丁和故障处理都要有团队接。社区版和企业版的功能边界、插件生态和长期维护能力，要在选型时确认。

三条路线没有简单的优劣。 选部署形态，本质上是在选“容量责任由谁承担”。 愿意承担基础设施和运维，就换来数据和部署的自主；不想承担，就要接受厂商的边界和套餐约束。

八、常见误区与 FAQ

1. 常见误区

• 按注册人数买服务器。 注册用户不等于在线用户，更不等于并发连接。按峰值在线和多端连接算。
• 只看平均延迟。 平均值会掩盖长尾，P95/P99 和错误率更接近真实体验。
• 把“支持扩展”当成“现在就能扩”。 扩展方式、停机时间、数据迁移和费用都要问清楚。
• 忽略群消息扩散。 大群和全员通知的投递量，往往比日常聊天高一个数量级。
• 忽略文件存储和备份。 存储是持续增长的，恢复演练比备份本身更重要。
• 忽略移动端和弱网。 断网重连、离线消息补全和多端同步，都是容量体验的一部分。

2. FAQ

厂商标称 10 万并发，我们只有 5000 人，是不是浪费？

不一定。10 万可能是连接层的实验室峰值，不代表你们的消息模型能跑同样的量。按自己的峰值场景做 POC，留出 30%-50% 余量即可，不必为用不上的数字付费。

压测环境和生产环境不一致，报告还有效吗？

只能作为参考。硬件、网络、数据量、客户端和消息模型都会影响结果。关键场景要在接近生产的环境里复测，至少确认瓶颈和降级行为一致。

信创环境的性能要不要统一打折？

不建议用一个固定折扣。不同 CPU、操作系统、数据库和负载类型的差异很大，应该在目标信创环境里实测。采购时把信创环境写入 POC 条件，比事后估算可靠。

容量评估一次就够了吗？

不够。大版本升级、组织合并、业务高峰、集成新系统、留存策略变化，都可能改变负载。至少每年复核一次，重大变更前重新压测。

容量评估的终点，不是一张厂商参数表，而是一份能写进合同的验收清单。在什么硬件、什么网络、什么消息模型下，达到多少连接、多少吞吐、什么延迟和成功率。把这件事做实，企业即时通讯系统选型才不容易在高峰期返工。

资料来源：喧喧IM 官方部署文档与公开产品资料，核对日期 2026-11-01。