8.1 服务器架构对比与选型

8.1 服务器架构对比与选型

实战从最大的一笔账开始：转发架构。终端直连、转发、混流三种形态决定了产品的成本曲线与规模上限，选错架构的团队后期要付出推翻重来的代价。本节给出三形态的完整对比与一套可操作的选型决策。

三种形态的本质差异

全员直连是引擎的默认形态：每个参与者与其余所有人各建一条连接，服务器只做信令撮合。它零服务端算力、延迟最低，但上行带宽随人数线性暴涨——八人会议里每人要同时发出七份相同的流，家用上行根本撑不住。它只适合双人场景与技术验证。

选择性转发是当前的主流：每人向服务器发一份流，服务器按需复制转发给其他人。上行从"人人七份"降到"人手一份"，服务端只做搬运不做编解码，单机就能扛数百路。它的进阶能力是配合第五章的分层编码：上行发多层，服务器按各接收端的带宽发对应层，弱网的人自动收到低清版。代价是服务端要真正接管传输逻辑，工程复杂度上一个台阶。

混流再分发是服务端干重活的形态：把多路流在服务端解码、合成一路、再编码分发。接收端永远只收一份流，老设备与协议互通场景友好，但服务端算力开销最高，且合成引入新的编解码延迟。它如今主要活跃在电话接入、录制归档、跨协议互通这些特定位置，作为主架构已经让位给转发形态。

选型决策与成本账

选型只看三个变量。人数规模：双人或三人，直连即可，省掉整个服务端媒体层；十人到百人，转发形态；千人以上的活动直播，转发加边缘分发的扇出方案。上行环境：参与者多是家庭或移动网络，必须转发形态——直连的上行数学上就不可行。算力预算与互通需求：没有编解码预算、没有老协议包袱，选转发；要跟电话系统互通或要服务端录制合成，混流模块作为旁路存在，而不是主架构。

转发形态的选层细节

转发形态既然是主力，它的核心机制——选层——值得多看两眼。上行按 5.2 的分层方案发出多层，服务器按每个接收端的实时带宽挑层下发：带宽好的收高层，差的收低层。这套机制把"弱网者降清"的决策从终端上移到了服务端，带来三个工程红利：接收端不用自己扛弱网决策；同一场次的带宽消耗被精确匹配到各端能力；录制与转推可以固定选高层，与实时观看互不干扰。

选层的颗粒度与切换频率也有讲究。切层过于敏感会让画面档位频繁跳动，观感上"忽清忽糊"比稳定中清更差；过于迟钝则弱网者长时间糊。成熟实现都在两者间取滞回中间带——与 7.2 武器调度的滞回思想同源。工程验收时，把"切层次数每分钟"作为观感稳定性的代理指标，比主观评价更有操作性。

最后给选型一个兜底建议：先按转发形态做最小可用版本（单机、单房间、无多分层），把信令、监控、运维链路跑顺，再逐步上多分层、边缘扇出、混流旁路。架构演进一步一验，远比一步到位的"完整方案"稳——实时系统的复杂度下限已经很高，部署复杂度能省则省。

转发服务器会改变延迟吗

会增加一次机房转发，地理就近时增量在个位数毫秒级，远小于它省下的上行收益。真正要防的是跨区调度——把东部用户调度到西部机房，转发路径反向拉长几十毫秒，这种劣化与架构无关，是调度策略问题。

小规模产品直接用开源转发服务可行吗

可行且常见，成熟的开源转发项目覆盖了协议与选层的主体逻辑。工程量集中在运维侧：多机调度、监控接入、版本跟进。评估时拿自己的房间模型压测一轮，再决定自研还是沿用——多数团队会发现开源方案的上限比想象的高。

直连形态真的只剩双人场景了吗

直播回放、单向上行的小工具类业务里它仍有位置：只要"互看"的人数少且上行可控，省掉整个媒体服务层就是最便宜的架构。判断标准始终是账本，不是流行度。

选型文档的落法

架构决策要落成文档才有生命力，给选型文档一个最小结构：一页决策记录，写清选了什么、备选是什么、关键账目是多少、推翻条件是什么。其中"推翻条件"最容易被漏掉却最有价值——例如"当单房间人数上限需要突破五十时，当前单点转发需重新评估"，把假设摆到明面上，一年后接手的人才能判断架构是否还在其适用区内。决策记录与 8.2 的部署验收清单、8.4 的指标口径共同构成产品的架构档案，三者齐备，实时通信产品的长期演进才有抓手。

案例：八人会议的三形态账本

背景。初创团队要做企业培训产品，首版按八人小班课设计，CTO 要求在写第一行服务端代码之前，把三种架构在同一场会议下的带宽与机器成本算清楚。

操作。设定：八名参与者，每路视频上行八百千比特、音频四十千，均按转发友好的多分层方案上行。逐一记账。全员直连：每人上行等于自身一路乘以七份对端，即约五点九兆——三家运营商的家庭上行直接出局，方案在物理层就被否决。选择性转发：每人上行八百四十千，服务器转发量为每人下行七路合计约五点九兆、全室合计约四十七兆，按单机千兆网卡与每核转发吞吐折算，单台中等配置机器可承载数十个这样的房间，机器成本极低。混流分发：上行同转发形态，但服务器要为每个房间跑一路合成，按每路合成消耗的核数折算，机器成本高出转发形态一个数量级，且合成延迟增加约百毫秒。

结果。账本结论：小班课选转发形态，混流只在需要合成录制文件时作为旁路开启。团队据此定了首版架构，两年内仅扩机器未改架构。

解读。这笔账的方法论价值大于数字本身：架构选型的核心是找出随规模增长的变量。直连形态里暴涨的是每人上行，转发形态里温和增长的是服务器转发量，混流形态里昂贵的是编解码核数——把变量找出来，成本曲线自然画出，选型就从口味之争变成了算术题。

变式。若产品形态是万人级活动直播，账要重新记：主讲人一路多分层上行，转发层按边缘节点逐级扇出，观众端只下行——此时架构的关键从"房间内互转"变成"扇出树"，选型维度换成边缘节点成本与调度策略。同一个转发内核，拓扑变了，账的记法也变了。

要点回顾

本节要点：直连、转发、混流的本质差异是"谁复制谁加工"；选型三变量是人数、上行环境、算力与互通；绝大多数多人产品的答案是转发形态，混流作旁路；记账先找随规模增长的变量。下一节解决部署层面的雷区：中转、端口与企业网络策略。