从外部看，Jitsi Meet 很简单：一个房间 URL、一次摄像头授权提示、一组参会者网格。底层架构更适合按职责拆开阅读。浏览器客户端呈现产品表面，Prosody 通过 XMPP 承载信令，Jicofo 作为会议焦点运行，Jitsi Videobridge 作为选择性转发单元路由媒体，而不会把每个参会者混合成一条合成流。[1][2]
这组分工，是 Jitsi 作为开源基础设施仍然值得关注的主要原因。它超出“用自托管 Web 应用替代托管会议厂商”的层面，直接暴露真实会议系统本身：身份与房间策略位于一层，会议编排位于另一层，实时数据包路由位于再下一层，可选录制或 SIP 集成则留在热路径之外。[1]
截至 2026-06-10T23:34:55Z UTC，jitsi/jitsi-meet 仓库有 29,397 个 star、7,914 个 fork、207 个 open issue，许可证为 Apache-2.0，push 时间戳来自同一天。releases API 返回的最新 GitHub release 为 2.0.11031，发布于 2026-06-08，对应 stable/jitsi-meet_11031。[6][7] 这些数字不能证明它适合某个具体运维环境，却显示出一个仍在活动、安装面和贡献面都很大的项目。
浏览器只承担系统的一部分
大多数用户体验 Jitsi 的位置在 Web 客户端：加入流程、设备选择、聊天、回应、屏幕共享、主持控制和布局。从架构角度看，它是一个参会端点。它协商媒体，渲染界面，并响应会议状态。最困难的多人扩展决策落在更深的媒体和控制平面里。
这一点很重要，因为评估 Jitsi 的团队常从错误问题开始。他们会问界面是否接近现有会议产品。更好的问题是，组织是否想掌握界面背后的实时系统。Jitsi 的架构页把 Jitsi Meet、Jitsi Videobridge、Jicofo、Prosody、Jigasi 和 Jibri 列为彼此独立的组件。[1] 产品表面只是这个系统里的一个参与者。
开源优势与维护负担在这里同时出现。你可以检查、部署、扩展并集成这些层。与此同时，当两个人开会正常、二十个人质量下降，远端参会者收不到媒体，或者录制行为与实时参会不同步时，你也继承了判断失效层级的责任。
信令留在媒体路径之外
Prosody 和 Jicofo 容易被低估，因为它们处在视频通话最显眼的画面之外。Prosody 是用于信令的 XMPP 服务器。Jicofo 是会议焦点，负责协调房间、参会者和媒体桥选择。[1] 它们的工作，是让控制平面的状态保持一致，同时不伪装成媒体平面。
这种拆分是一条实际的设计边界。房间成员、权限和会议编排需要可靠的信令语义。媒体包需要低延迟路由和自适应能力。把这些关注点绑得太紧，会让系统在负载下更难推理。Jitsi 的组件模型给了运维人员描述故障的词汇：这是认证与房间状态问题、桥接选择问题，还是媒体传输问题？
这种区别也让定制更容易落地。团队可以处理认证、品牌、房间默认值或主持行为，而不用重写媒体路由器。反过来，桥接扩展和网络位置也可以作为基础设施工作推进，而不会让每次 UI 变化都变成媒体系统变化。
Videobridge 是重心
Jitsi Videobridge 是架构重心，因为它决定多人媒体如何扩展。它是兼容 WebRTC 的 SFU：客户端把媒体发送到桥，桥再把选定的流转发给其他参会者，避免为所有人解码、合成并重新编码一条混合视频。[2]
选择 SFU 不只是实现细节。一篇独立的 WebRTC 工程解释文章把 SFU 描述为传统多点控制单元之外成本更低、适应性更强的方案，适用于许多多人视频场景，尤其适用于不同参会者需要不同质量或码率的情况。[5] Jitsi 自己的 Videobridge 页面也从项目侧提出同样的架构要点：转发选定流，使桥把工作集中在路由上，避开完整媒体混合。[2]
由此形成清晰取舍。服务器避开了混合器的 CPU 特征，而客户端和桥共同承担流选择、接收端条件和会议动态。结果可以很好扩展，但它没有魔法。丢包、上行质量差、桥过载和糟糕网络路径仍会表现为用户可见的会议质量问题。Jitsi 把路由模型显性化，使运维人员可以把这些故障诊断为媒体基础设施问题，避免把它们笼统归入“视频应用”问题。
采用边界在 UDP 与容量
自托管 Jitsi 的工作会延伸到网页加载之后。quickstart 指南的防火墙部分引导运维人员开放 TCP 443 上的 HTTPS 和 UDP 10000 上的媒体流量，并明确建议在参会者看不到或听不到彼此时检查防火墙和 NAT 规则。[3] 这是许多试点遗漏的采用边界：加入页面只能证明 Web 层可达，不能证明实时媒体对用户所在的各种网络都处于健康状态。
requirements 指南从容量角度强化了同一点。Jitsi Meet 被描述为实时系统，该指南点出了 CPU 行为、Prosody 的单核约束，以及加入录制或流媒体后 Jibri 更重的资源画像。[4] 也就是说，桥和周边服务需要运维余量，而不只是能提供静态资源的小型虚拟机。
这也解释了 Jitsi 最适合与最不适合的场景。它适合想要开源视频基础设施、能理解 UDP 可达性、能把桥放在用户附近、并能把质量作为基础设施监控的团队。对于只想要“像托管会议产品一样，同时没有运维表面”的需求，它契合度较低。Jitsi 可以由供应商管理，也可以作为服务运行，但自托管架构承诺的是控制权，运维工作仍然存在。
可选组件应当保持可选
架构页对 Jigasi 和 Jibri 的处理也很说明问题。Jigasi 把 SIP 客户端带入 Jitsi 会议。Jibri 通过启动一个类似浏览器的参会者并编码输出，来录制会议或推流。[1] 这些功能很重要，但它们被刻意放在独立任务里。
这种拆分让核心通话路径更清晰。SIP 互通有自己的失效模式。录制也有自己的 CPU、内存、磁盘和浏览器自动化画像。requirements 指南警告说，Jibri 的资源需求远高于 Jitsi Meet 本身，把它与会议服务放在一起会损害会议性能或耗尽磁盘空间。[4] 如果一个系统把录制当成主服务器上的另一个勾选项，这些成本会一直隐藏到第一场高风险会议失败时才显现。
更好的读法是，Jitsi 的模块化首先体现在运维意义上，而不仅是源码树意义上。小型私有部署可以采用更精简的形态。公共或机构部署可以增加专用桥、录制 worker、TURN 支持、SIP 网关、可观测性，以及围绕房间创建的策略。这些是从同一个项目家族中组装出的不同系统。
需要记住的部分
Jitsi Meet 的价值在于，它让会议栈变得可读。浏览器客户端是用户表面。Prosody 和 Jicofo 协调信令与会议状态。Jitsi Videobridge 以 SFU 身份承担媒体路由负载。Jibri 和 Jigasi 增加录制、推流和 SIP 集成，同时不把这些能力伪装成核心通话路径的免费扩展。[1][2][4]
这是采用 Jitsi 之前需要保留的架构笔记。Jitsi 的位置超出“开源 Zoom”。它是一套开放、可检查、基于 WebRTC 的会议架构；当运维方接受这些层次时，它的优势才会落地：信令、媒体路由、网络可达性、容量和可选服务。如果你想要这种控制，Jitsi 的结构非常直接。如果你只想要一个会议链接，这套架构会持续要求你承担链接之外的更多内容。
来源
- Jitsi Meet Handbook, “Architecture”——说明 Jitsi Meet、Jitsi Videobridge、Jicofo、Prosody、Jigasi 与 Jibri 等组件。
- Jitsi, “Jitsi Videobridge”——项目页说明兼容 WebRTC 的选择性转发单元与媒体路由模型。
- Jitsi Meet Handbook, “Debian/Ubuntu server” quickstart——部署与防火墙指引，包括 HTTPS 与 UDP 媒体可达性。
- Jitsi Meet Handbook, “Requirements”——实时系统说明、CPU 指引、Prosody 约束与 Jibri 资源警告。
- webrtcHacks, “Optimizing video quality using Simulcast”——独立 WebRTC 工程文章，解释 SFU、simulcast 与多人 WebRTC 路由取舍。
- GitHub API，
jitsi/jitsi-meet仓库元数据快照——文章创建时的 star、fork、open issue、许可证与近期 push 活动。 - GitHub，
jitsi/jitsi-meetreleasestable/jitsi-meet_11031——文章创建时观察到的最新 release。 - Wikimedia Commons，“Server Rack with Spaghetti-Like Mass of Network Cables.jpg”——Kim Scarborough 于 2006 年拍摄的真实照片，作为本文图片来源。