行政同事的采购单写着"就几十个人开会，买台 8 核 16G 的机器够了"，机器按这个配置买回来了，前两周也确实没出过问题。第三周周一上午九点，三个部门同时开周会，画面集体糊成马赛克，声音断成电报，有人退出重进，退出重进的瞬间又把带宽再踩一脚。运维拉出监控看了一眼：CPU 使用率三成不到，内存用了不到一半，唯独出网带宽那条线贴着上限在走。复盘会上争论的焦点是"要不要再加几核"，但真正的答案是这台机器从一开始就被按错了方向买——视频会议这类负载的第一约束不是算力，是出网带宽的形状。
Jitsi 官方手册在讲服务器要求时，把"网络链路"排在第一位，并且措辞相当直接：Jitsi Meet 是一个实时系统，算错容量的后果不是"变慢"，而是基本功能直接坏掉。手册给出的资源重要性顺序是网络链路、内存、CPU、磁盘，这个顺序和绝大多数 Web 应用的直觉是反的。做网站时人们习惯先算 CPU 和内存，带宽留够就行；做视频会议时，带宽是那个先撞墙的量。
CPU 闲置也不是异常，而是这套架构设计出来的结果。Jitsi Videobridge 是一个选择性转发单元，它收到一路流之后不做解码、不做混流、不做重新编码，而是把已经加密的媒体包复制给需要它的接收端。不做转码，CPU 自然用不起来。官方公开的一份性能评估里，一台四核 Xeon E5-1620 v2 的独占服务器跑出 1056 路视频流加 1056 路音频流、总带宽超过 550 Mbps 时，CPU 占用大约在 20% 左右。这份评估是官方在自家测试床上跑出来的公开数据，它说明的是一个量级关系：在这类转发型负载里，带宽会比 CPU 先到顶。
于是就有了那个典型的错位画面：采购单按"几十个人"的心智模型写，脑子里想的是"人越多 CPU 越累"，实际上人越多累的是出口。等到三个部门同时开会，撞的不是 CPU 天花板，是带宽天花板。
要算清带宽账，得先把 SFU 和 MCU 的区别摆正。MCU 的做法是把所有人的流收上来，解码、混成一路画面，再重新编码发给每个人，服务器的 CPU 极重，但每个客户端只收一路，服务器的出网带宽反而不大。SFU 反过来：服务器不解码，客户端各收各的。代价是服务器要为"每个接收者订阅的每一路流"单独发一份。
所以 JVB 的出口流量不是跟着"会议数"走的，也不是简单跟着"参会人数"走的，而是跟着"总订阅流数"走的。官方那份性能评估里有一句非常关键的话：1000 路视频流的 CPU 和带宽开销是一样的，不管这 1000 路是发给一千个各收一路的人，还是发给一百个各收十路的人。这句话可以直接翻译成选型语言——你要盯的计数器是"当前正在被转发的流总数 × 每条流的码率"，不是"现在有几场会"。
订阅数又受 simulcast 和 last N 两个机制调节。simulcast 让发送端同时编码多个分辨率层，JVB 按接收端的屏幕大小和网络状况挑一层转发，而不是一刀切；据 Jitsi 开发者在社区的解释，Chrome 一类的发送端最多发三层，主分辨率 720p 时另外两层是 360p 和 180p，三层上限分别是约 2.5 Mbps、500 Kbps、150 Kbps，可用带宽下降时先砍最高层的码率，再逐层关闭。last N 则限制每个接收者最多同时收到几路远端视频，官方文档记录 channelLastN 的默认值 -1 表示不限制，startLastN 可以让会议从一个较小的值开始。这两个机制是带宽账里的分母，能不能把带宽压下来，主要看它们怎么设。
还有一个容易误导人的点：两个人开会时 Jitsi 可以走点对点，媒体根本不过 JVB。这意味着"两人测试通过"完全不能证明架构可用，很多团队一直到第三个人加入才第一次真正走通转发路径，然后发现 UDP 那一侧从来就没通。这个故障模式后面还会提到。
自建一套 Jitsi 实际上是在一台或多台机器上一块块地拼职责，每块的压力来源都不一样，把它们混在一起谈"这台机器够不够"，本身就问错了问题。
| 组件 | 承担的工作 | 主要消耗什么资源 | 压力随什么增长 | 扩容方式 | 选型时要确认什么 |
|---|---|---|---|---|---|
| Jitsi Videobridge（JVB） | 作为选择性转发单元，把每个发送者的音视频包复制给订阅它的接收端，不解码不混流 | 出网带宽为主，其次是入网带宽；CPU 用于包复制、加密与抖动缓冲，占用相对低 | 随同时被转发的流总数与单流码率增长，而不是随会议场数线性增长；单台可承载的流数需实测 | 横向增加 JVB 实例，由 Jicofo 做分配；跨区域可用 OCTO 让多个 bridge 之间互联转发 | 出网带宽峰值与计费方式、UDP 10000 是否双向放行、是否有独立公网 IP、CPU 是否独占而非共享 |
| Jicofo（会议焦点） | 管理会议生命周期、协商媒体会话、决定这场会用哪个 bridge、在 JVB 之间做负载分配 | CPU 与内存都不重，压力集中在会议创建与结束的 bursts 上 | 随会议场数与参会人数的信令频次增长，不随媒体码率增长 | 与 Prosody 一起放在信令节点上，按区域部署多个信令节点，而不是把它和 JVB 一起放大 | 与 JVB 之间的网络质量、单节点能承载的会议场数需实测、是否要单独部署 |
| Prosody（XMPP 信令） | 负责登录鉴权、在线状态、聊天消息与会议房间的创建维护，是信令面而不是媒体面 | CPU 与内存，且官方明确指出它只能使用一个核心 | 随在线人数、房间数与消息量增长；与视频码率无关 | 加核无效，只能拆分信令节点或升级单核性能 | 必须确认 CPU 是独占的；单核性能比核数重要，官方提示核数超过 32 也未必有用 |
| Jibri（录制与直播） | 以隐藏参与者身份用无头 Chrome 加入会议，抓屏抓音后用 ffmpeg 编码成文件或推 RTMP 流 | CPU 最重（浏览器渲染加视频编码），其次是内存与磁盘顺序写带宽 | 随同时录制的会议场数线性增长，一场会议就需要一个 Jibri 实例 | 只能加实例，一个实例一场，没有共享或复用的变通办法；建议独立成机 | 内核是否带 snd-aloop 模块、CPU 是否独占、磁盘是否 SSD、录制目录所在盘是否与系统盘分离 |
| Jigasi（SIP 网关） | 让传统 SIP 话机或电话系统作为一路参与者进入会议，承担协议转换与音频编解码 | CPU（涉及音频转码）与内存；出网带宽占用远低于视频 | 随同时接入的电话路数增长，与视频订阅数无关 | 按需增加实例并做负载分担；不接入电话系统时可以不部署 | 是否真的有电话接入需求、与 SIP 侧的网络连通、并发路数需实测 |
| coturn（STUN/TURN 中继） | 在客户端无法与 JVB 建立直连时，为其提供中继路径；同时提供 STUN 用于地址发现 | 出网与入网带宽同时消耗，同一份媒体在服务器上进出各一遍；其次是中继端口资源 | 随走中继的会话比例与这些会话的码率增长；比例取决于用户所在网络，需实测 | 按区域增加实例，用 DNS 轮询做多候选；中继端口段按并发量规划 | UDP 3478 与 TCP 5349 是否放行、中继端口段是否整段放行、能否显式配置对外地址、是否限制中继目标网段 |
这张表里最容易被忽略的一行是 Prosody。它只能用一个核，意味着在信令节点上堆核数是纯粹的浪费；官方甚至提示核数超过 32 也未必有用。反过来，JVB 那一行最容易被低估的是"出网带宽为主"这五个字——它不是"之一"，它就是主约束。
官方手册为了让人有个抓手，直接给了分辨率与码率的对应参考：180p 约 200 kbit/s，360p 约 500 kbit/s，720p（HD）约 2500 kbit/s，4K 约 10 Mbit/s，并提醒"别指望在一条 100 Mbit/s 上下行的链路上让 20 个人跑 4K"。这些是官方给出的估算口径，不是承诺，但足够用来做量级判断。
算账的公式并不复杂：先估出"同一时刻最多有多少场会同时进行"，再估出"其中画面最凶的那一场有多少人开摄像头、多少人共享屏幕"，然后用"接收者数 × 每人订阅的路数 × 对应层码率"得出这台 JVB 那一瞬间要吐出去的量。注意这里有三个容易被漏掉的乘数。
第一个乘数是上下行几乎对称。SFU 每收进一路，几乎就要吐出若干路；入网和出网是同一份数据的两端，只盯着出网买、入网被限制住，一样会坏。第二个乘数是屏幕共享。共享的是文档和界面，纹理密集、运动突然，压缩效率远不如人脸，码率会在共享开始的那一刻跳一档，很多人只按摄像头开会估算，一遇到共享就超。第三个乘数是重叠。会议系统的用量从来不是均匀分布的，它几乎全部集中在整点和半点，尤其是周一上午。平均值在这里是彻头彻尾的误导：你需要的不是"一天平均多少带宽"，而是"峰值那十分钟多少带宽"。
还有一个更小但真实存在的尖峰：会议开始后的头半分钟是 ICE 协商、关键帧请求和带宽探测叠在一起的时刻，瞬时用量会高于稳态。带宽如果买得刚刚好，崩的往往就是这三十秒。所以官方给出的口径是"朋友间或小型组织的服务器 1 Gbit/s 通常够用，但严肃用途建议 10 Gbit/s"，并且提到大型部署会用多个各带 10 Gbit/s 链路的 bridge。这句话背后的逻辑就是：留出足以吸收峰值和重叠的余量，而不是算到平均值就收手。
官方手册在这一点的态度很明确：Jitsi Meet 的设计优先通过"加服务器"来扩展，而不是"用一台巨型服务器"，并且提示不要往这套系统上叠别的功能，那会伤害性能也会让优化变复杂。所以默认路径应该是横向拆，而不是纵向加。
但"默认横向"不等于"永远横向"，判断依据是瓶颈落在哪个计数器上：
关于"一台 JVB 到底能扛多少人"，需要说清楚口径：官方并不发布一个统一的并发上限。社区里有 Jitsi 核心开发者给出的经验口径，比如"4 核 8 GB 对一个 JVB 足够"、"800 人量级需要 4 到 8 个 JVB，取决于多少人开视频"，也有其他使用者分享的按核数估算的表格。这些都是社区经验而不是官方承诺，而且高度依赖于开摄像头的人数比例、分辨率和 last N 设置。把它当成起点可以，当成验收标准不行。
最常见的误解是"我的服务器有公网 IP 了，为什么还要 TURN"。答案是：需要中继的原因在客户端那一侧，不在服务器这一侧。一个坐在企业内网里、出口防火墙把 UDP 封掉的参会者，或者一个处在运营商对称型 NAT 后面的手机用户，无论你的服务器地址多公网，他都建不起直连路径。这种情况下 TURN 是唯一通路，不是可选项。
端口上要分清三件事：3478 UDP 是 STUN 与 TURN 的监听端口，5349 TCP 是 TURN over TLS，另外还有一段用于实际中继的端口范围，coturn 默认常见配置是 49152 到 65535 这段 UDP。很多部署只开了 3478 就以为完事了，结果客户端拿到了中继候选却通不了媒体，因为真正承载数据的那段端口被防火墙挡着。另外，如果参会者所在的网络只放行看起来像网页流量的东西，就得让 TURN 走 443 或 5349 的 TCP/TLS，伪装成普通 HTTPS 才有机会穿出去。
对带宽账来说，TURN 的意义在于它会让同一份媒体在服务器上走两遍：客户端 A 发到 TURN，TURN 再发给对端，进和出各一遍。中继占比只要上去，你买的带宽账单就会实打实地翻倍。关于这个比例，业内流传的经验值是公网消费级场景大约 10% 到 20% 的会话需要中继，而企业网络和严格防火墙为主的场景有来源称可以高得多，甚至到 85%。这两个数字差距巨大，恰好说明了重点：中继比例完全取决于你的用户画像，必须自己抓指标实测，不能照抄别人的比例。
运维上还有几个必须提前确认的点：机器有内网地址又有公网地址时，coturn 需要显式配置对外地址，否则它默认把内网地址报出去，客户端拿到就废；中继端口段要在主机和上层网络策略里整段放行；还要限制中继的目标网段，防止这台 TURN 被当成打进内网的开放代理。另外，每个中继分配都要占一个端口，规模上来之后要按并发量规划端口段并监控占用率，而不是一直用默认值。
Jibri 的工作方式和人们想象的不一样。它不是在 JVB 上把媒体流转储下来，而是以一个隐藏参与者的身份，用真正的 Chrome 浏览器打开这个会议，把虚拟屏幕和虚拟声卡上的内容交给 ffmpeg 编码。也就是说，一场录制同时跑着一个完整浏览器、一个虚拟显示、一块虚拟声卡和一个视频编码器。这解释了它为什么重，也解释了它为什么有一条硬限制。
官方手册的说法是"一次录制需要一套系统，一个 Jibri 等于一场会议，要同时录 5 场就得有 5 个 Jibri，这件事没有变通办法"。即便你很懂容器，能在一台大机器上塞多个 Jibri 实例省一点资源，也只是省一点，规则本身不变。内存上官方给的口径是录制单场会议时，1080x720 至少需要 8 GB，1280x1024 需要 12 GB，并且强调内存不够、CPU 编码跟不上或者磁盘不够快，录制就会失败而不是变慢。
还有两个实操门槛常被低估。一是内核模块：Jibri 需要 ALSA 的 snd-aloop 模块来做虚拟声卡，而不少云镜像用的是裁剪过的定制内核，不带这个模块，装到一半才发现要换内核。二是磁盘：官方建议如果要对接云存储，至少要用 SSD；同时明确不建议把 Jibri 和 Jitsi Meet 放在同一台机器上，理由是它太吃资源，会拖累实时会议，而且录制文件把磁盘写满之后，整台机器上的 Jitsi 会一起停摆。
直播走的是同一条 Chrome 加 ffmpeg 的管线，只是输出端换成 RTMP 推流。它对 CPU 更敏感，因为录制卡了可以事后转码，直播卡了就是当场事故。所以在做容量规划时，录制和直播的机器要单独列一行，规模按"最忙那一小时同时有多少场要录"来算，而不是按"一天总共录多少场"。
顺带划一条边界：录制落盘是持续的大块顺序写，压力在写入带宽和编码器上；这和照片库那类海量小文件、随机读写为主的负载是完全不同的两件事，不要拿同一套存储选型逻辑套过来。
自建视频会议对机房的要求，比一般 Web 应用挑剔，而且挑剔的点很具体。
媒体走的是持续的小包 UDP 流，重传窗口极小，丢包和抖动直接变成画面糊和声音断。机房宣称的带宽大小和网页打开速度都不能代替这项验证。选型时要问的是这条链路在跨网访问时的丢包表现、晚高峰是否劣化，以及能否用工具实测。这一点上，BGP 多线一类的多出口资源价值在于缩短跨网路径、减少绕行，而不是营销话术。
同样写着"100M"，按固定端口、按峰值、按 95 计费，三种方式的成本结构和可用上限完全不同。视频会议的用量是尖峰型的，如果计费方式对突发敏感，或者超出部分单价很高，账单会和你的会议排期强相关。必须提前问清：出网是否单独计费、是否允许短时突发、超限怎么处理、入网是否受限。
这套系统要用的端口不少：443 是网页与信令，10000 UDP 是默认的媒体端口，3478 UDP 与 5349 TCP 给 TURN，还有一段中继端口。需要确认的是这台机器拿到的是独立公网 IP、UDP 没有被默认策略挡、非常用端口可以按需放行。另外，媒体路径要求双向可达，单向放行一样会出现"能进不能出"的单通故障。
跨区域团队把所有人连到同一个 bridge 上，远端用户的媒体要先绕到那个点再绕回来，延迟被放大两次。官方的做法是按区域布 JVB 池，让参会者连就近的 bridge，bridge 之间再通过 OCTO 互联转发。所以如果参会者分散在多个区域，选型的答案通常不是"买一台更大的"，而是"在几个节点各放一个 JVB"。是否需要中国香港或海外节点，取决于参会者实际在哪里，而不是取决于机器便宜还是贵。
同样是"自建视频会议"，四类场景的带宽形状和扩容方向差别很大，用同一套配置去套，必然有一类是浪费、另一类是事故。
企业内部会议的特点是开摄像头的人少、屏幕共享多、时间高度集中在整点和半点。它的带宽曲线是窄而尖的：平时几乎不用，周一上午九点冲到顶。对策是把 last N 调小、把默认分辨率压住，重点防的是那十分钟的峰值重叠，而不是提升日常画质。
在线教育小班的订阅结构极不均衡：一路主讲上行，若干学生主要下行，学生端开摄像头的比例不高但互动时需要被看见。它的出网账更接近"学生数 × 一主讲路"，比全员会议的账好算。真正的压力在录制端——每门课都要留档，Jibri 的数量要按"同时开课的班级数"来配，而不是按一天的课时总数。
远程问诊与客服以一对一为主，这种情况下 Jitsi 可能根本走点对点，媒体不经过 JVB，服务器带宽压力反而最小。但它对录制和留痕有强要求，所以成本大头会落在 Jibri 实例数、录制文件的存储与归档策略上。这一类和前两类几乎是两种系统。
出海与跨区域团队的核心矛盾不是容量而是路径。单 bridge 部署下，远端参会者的媒体要跨洲绕行，再大的带宽也救不了延迟和抖动。这类应该优先考虑在参会者集中的各个区域各放一个 JVB，用 OCTO 把它们串起来，而不是把预算全砸在某一台机器的配置上。
CPU 的选型逻辑和 Web 服务器不一样。官方手册的口径是：基础服务器 4 个独占核心可能就够了；同时因为 Prosody 只能用一个核，堆到 32 核以上也不一定有用。所以核数不是重点，重点是单核性能和是否独占。共享型 vCPU 在实时系统上的风险是抖动，而不是平均算力不足。
内存上官方建议 8 GB，小会议可以 4 GB，纯测试环境 2 GB 也能跑起来。需要说明的是，这个 8 GB 指的是跑 Jitsi 本身；如果同一台机器上还跑 Jibri，官方给的单场录制参考值就是另外一档（1080x720 至少 8 GB、1280x1024 需要 12 GB），两者叠加不是简单相加，但绝不能按"8 GB 够跑 Jitsi 了"这一句话来定整机。
磁盘是这套系统里最不紧张的一项。官方的说法是除非做很重的日志或有特殊需求，20 GB 普通硬盘就够，SSD 更多是锦上添花。真正的例外是录制：录制文件是持续写入的大块数据，量大且不能中断，所以录制节点建议单独配 SSD，并且把录制目录放在与系统盘分离的盘上——这条不是性能建议，是可用性建议，因为磁盘写满会让 Jitsi 整体停摆。
其余几项要写进采购单的是：独立公网 IP、可按需放行的 UDP 端口、BGP 多线一类的多出口接入、以及明确的出网带宽上限与计费规则。IP 的数量也要提前想好：如果 TURN 要和 JVB 分开部署、录制要独立成机，那就是多台机器多个地址，而不是一个地址打天下。
带宽是这套系统里唯一买了之后很难"临时补"的资源，所以买之前要把三件事谈清楚。
一是按什么口径计费。固定端口意味着你的上限就是那个值，超出即丢包；按峰值或按 95 计费则允许一定突发，但账单会随峰值走。视频会议的用量形状是尖峰，这两种方式的成本和风险分布完全不同，需要先判断自己的会议排期是不是高度集中。
二是上下行是否对称、入网是否受限。SFU 的入网和出网是同一份数据的两端，很多机房的产品描述只突出下行，选型时要明确上行能力。TURN 一旦启用，同一份媒体在服务器上进出各一次，对上下行的要求会同时抬高。
三是能否突发、突发怎么算。会议开始的那半分钟、整点重叠的十分钟，都是瞬时高于稳态的。买带宽时把"平均用量"当目标，等于把最关键的十分钟卖给了运气。
实践上建议的顺序是：先按最坏那一场会估算峰值，在这个基础上留出吸收重叠和协商尖峰的余量，上线后用真实的会议负载跑两到三周，再依据实测的流数、带宽曲线和中继占比回头调整。这个调整方向既可能是加大带宽，也可能是通过调 last N 和分辨率把峰值削平——后者往往更省钱。
把自建视频会议的总成本拆开看，大致是这几块：计算节点（JVB，以及可能独立的信令节点）、出网带宽、TURN 中继所占的额外流量、录制与直播节点、录制文件的存储、域名与证书、以及运维人力。前几项的单价都属于"需询价"或"以官网实时报价为准"的性质，不同机房、不同计费方式下的差异可以很大，这里不给出任何具体数字。
最容易被低估、也最容易失控的是两块。
第一块是出网带宽。它的不确定性来自形状：一是会议排期的重叠程度，二是参会者开摄像头的比例，三是走中继的比例。这三个量都随业务变化，且都不是采购时能一次定死的。很多团队一开始按"够用"买，然后在第一次全员大会或第一次同时开三个部门周会时被迫临时加，而带宽的调整和机器的加配置不同，往往涉及计费口径的重新谈判。
第二块是录制节点。因为一个 Jibri 只能录一场，这条规则是硬性的，录制需求一旦从"偶尔录"变成"每场都录"，节点数量就是线性增长，没有规模效应可言。而且每个节点都要配独占 CPU 和 SSD，成本单价并不低。所以在做预算时，把"最忙那一小时同时要录几场"这个数字确认清楚，比反复比价更有用。
相比之下，计算节点的成本反而最好预测：官方倾向横向扩展，单台 JVB 的配置需求并不夸张（4 个独占核、8 GB 内存是官方给出的基础口径），加一台的边际成本是可预期的。
自建系统最容易出的问题不是"跑不起来"，而是"看起来跑起来了，直到某个特定条件被触发才崩"。所以验收不能只验证功能路径，要验证边界路径。
第一组：三人会。两个人开会可以走点对点，媒体不过 JVB，这一组测的是"第三个人加入之后媒体是否双向正常"。它能暴露 UDP 10000 是否真的双向放行、JVB 对外通告的地址是否正确、以及是否需要 TURN。只测两人会就上线，等于把最关键的转发路径留给用户去踩。
第二组：峰值重叠。把"最坏的那一场会"复制若干份同时跑起来，观察出网带宽、流数、CPU 和丢包四个计数器，看谁先到顶。这组演练的价值在于确定你的天花板到底是带宽、是流数还是 CPU，从而决定后续是加 JVB、加带宽还是调参数。注意这一组要尽量模拟真实的摄像头数量和屏幕共享，用静音的空房间跑出来的数据没有意义。
第三组：强制中继。让一部分客户端只能通过 TURN 接入，观察中继比例、中继后的带宽占用是否翻倍、以及音画质量是否还能接受。这一组决定你的 TURN 容量该怎么配，也验证中继端口段是否真的整段可用。
除此之外，录制链路要单独验收：snd-aloop 模块能否加载、录制能否正常起停、生成的文件能否播放、磁盘写满之前有没有告警。日常监控至少要覆盖这几项：JVB 的出入带宽与流数、CPU 与内存、丢包与抖动、TURN 的分配数与中继会话占比、以及 Jibri 的空闲实例数。其中"中继占比突然飙升"是一个很值得报警的指标，它通常意味着直连路径出了问题，所有会话被挤到中转上，带宽会立刻吃紧。
把故障按层归类，能省下大量排查时间。这套系统的三层是：页面与信令（443）、媒体（UDP 10000 及 TURN 中继段）、录制链路（Jibri 与 Prosody 之间的 XMPP 连接）。
运维分工上建议把"媒体层"和"录制层"分开交给不同的人或不同的值班清单。媒体层的问题有强实时性，影响所有人；录制层的问题通常不影响正在进行的会议，但会留下无法补救的空洞。两者的紧急程度和处理路径完全不同。
官方并不发布一个统一的并发上限，因为答案取决于开摄像头的人数、分辨率、last N 设置和码率，变量太多。能做的是一个可操作的替代口径：先确定"同时被转发的流总数"这个指标，用你自己的真实会议去测它在什么数量级上让带宽或 CPU 先到顶。社区里流传的按核数估算的经验值可以参考，但不适合当验收标准。
官方手册给了按分辨率的参考值（180p 约 200 kbit/s、360p 约 500 kbit/s、720p 约 2500 kbit/s、4K 约 10 Mbit/s），这足够做量级估算。更细的分层码率在前端配置里有默认值，具体数值以你所使用的版本配置为准。实践上的建议是先按保守值上线，再依据实测的画质与带宽曲线回调，不要在没测之前就追求高清。
需要。问题出在客户端那一侧的网络，而不是服务器的地址。只要你的参会者里有企业内网用户、对称型 NAT 用户或者处在严格防火墙后面的用户，就需要中继路径。真正要实测的是"这些人占多大比例"，因为它直接决定带宽要不要翻倍预留。
不能。一个 Jibri 实例一场会议是硬性规则，官方明确说没有变通办法。能优化的是降低单场的资源占用（比如压分辨率），以及把录制节点独立出来避免拖累实时会议，但实例数量必须按同时录制场数来配。
看参会者在哪，不看机器在哪便宜。如果参会者集中在单一区域，一个 JVB 就够了；如果分散在多个区域，正确做法是在参会者集中的区域各放一个 JVB 并用 OCTO 互联，让就近接入的人不用绕远。节点数量的决策依据是路径，不是价格。
第一条：把预算从 CPU 挪到带宽和带宽的形状上。SFU 不转码，CPU 用不完是常态；真正会先撞墙的是出网带宽。判断线是——如果你的监控里 CPU 长期低于四成而带宽已经接近上限，那么加核是无效投入。
第二条：按峰值重叠算，不按日均算。取舍在于，按峰值买意味着平时有闲置成本，按均值买意味着周一上午九点出事故。对于会议这种排期高度集中的负载，前者的代价是可预算的，后者的代价是口碑。
第三条：默认横向加 JVB，但先确认瓶颈在哪个计数器。取舍是，横向扩展需要多机房或多实例的管理成本，纵向加配置则受 Prosody 单核、共享 vCPU 这些硬限制约束。只有确认是流数或带宽先到顶时，横向才是正解。
第四条：先把 last N 和默认分辨率调到位，再去谈扩容。取舍是画质，尤其是大会议室里想看到所有人的诉求。但削峰的收益往往比加带宽大得多，而且不需要额外成本，优先级应该在采购之前。
第五条：把 TURN 当成带宽预算里的一个乘数，而不是一条备用链路。取舍在于，中继保障了连通率，代价是同一份媒体在服务器上走两遍。正确做法是先实测中继占比，再决定带宽要预留多少倍，而不是等中继比例飙升时被动加。
第六条：录制节点永远独立，且按同时场数线性配。取舍是成本——录制没有规模效应，每多一场并发就是多一套实例。把它和实时会议混在一台机器上省下的钱，会以磁盘写满导致整体停摆的形式还回来。
一万网络深耕 IDC 行业 19 年（成立于 2007 年），在华南、华东、华北及中国香港、海外多地整合自营节点与 BGP 多线资源，提供服务器租用、机柜托管与带宽接入的一体化交付；具体机型、带宽与报价以官网实时信息或咨询确认为准。
本文只讨论自建视频会议的架构角色、资源账与选型思路，不比较任何具体服务商或云的优劣，不给出任何未经核实的并发数、码率或延迟承诺，不指向任何具体客户，也不构成性能或可用性承诺。所有容量数字均需在自有环境实测确定。
文中援引的口径分三类：一是 Jitsi 官方手册公开的服务器要求，包括资源重要性顺序、按分辨率的码率参考值、内存与 CPU 的基础建议、磁盘建议，以及 Jibri 的实例与内存要求；二是 Jitsi 官方公开的一份 Videobridge 性能评估，包括测试机型、流数、带宽与 CPU 占用的量级关系，这是官方在自家测试床上取得的数据，不代表任何具体部署环境的表现；三是公开技术社区与文档中关于端口默认值、simulcast 分层码率、last N 参数含义、中继端口范围与中继占比经验值的说法，这些属于经验参考而非承诺。
凡涉及具体容量——单台 JVB 能承载多少流或多少人、单场会议的带宽峰值、走中继的会话比例、录制节点的并发能力、以及各机房的带宽计费与价格——本文一律不给确定数字，需在你的自有环境、按你的真实会议负载实测确定。文中出现的场景为通用示例，用于说明取舍逻辑，不指向任何具体客户或具体部署。
本文不讨论邮件系统、网校平台、ERP、IT 资产管理或照片库等其他自建应用的选型，也不展开地区层面的海缆、电力与合规议题。存储部分仅在录制落盘这一处出现，讨论的是持续顺序写入对磁盘与隔离的要求，不涉及海量小文件与随机读写的存储选型问题。
一万网络深耕 IDC 行业 19 年（成立于 2007 年），在华南、华东、华北及中国香港、海外多地整合自营节点与 BGP 多线资源，提供服务器租用、机柜托管与带宽接入的一体化交付；具体的机型、机柜、带宽与报价，仍要以官方实时信息或咨询确认为准。
Copyright © 2013-2020 idc10000.net. All Rights Reserved. 一万网络 科技有限公司 版权所有 深圳市科技有限公司 粤ICP备07026347号
本网站的域名注册业务代理北京新网数码信息技术有限公司的产品
