RTC 混合云部署：把企业环境纳入产品设计

同一家公司、同一办公区的员工开视频会议，音视频却需要经过外部网络转发。会议越多，企业互联网出口承受的带宽压力越大；对通信路径有管理要求的客户，也希望内部交流尽量在自己的网络里完成。

我们最初提供的是公有云 RTC 服务，也就是通过云端基础设施支撑实时音视频通信。随着企业客户提出本地化诉求，产品逐步衍生出混合云部署：将负责音视频转发的媒体服务器部署到客户环境中，让符合条件的通信使用本地资源。

这项能力从内部试点走向外部客户后，围绕接入策略、网络连接、部署方式和运维管理，持续出现新的建设需求。它们共同改变了产品设计的前提：基础设施不再完全由服务商统一控制，企业已有的网络和 IT 规则也会决定产品能否正常工作。

先讲清楚，哪些能力部署到了客户侧

混合云涉及私有化能力，但这里主要私有化的是边缘媒体服务，并不是把整套 RTC 系统都搬进客户机房。

可以把媒体服务器理解为会议中转声音和画面的站点。同一办公区的参会者连接本地站点后，媒体流有机会在内网完成转发；房间管理、用户管理和调度等中心能力，仍由云端提供。当内部员工与外部参会者交流时，也仍可能产生内外网之间的媒体传输。

因此，“部署了本地服务器”不能直接解释为“所有数据都不出内网”，也不代表企业在与公有云完全断开后仍能照常开会。要让客户形成准确预期，就需要分开说明媒体路径、中心服务依赖和外部参会场景。

成本也要沿着这条边界分析。本地转发能够减少部分公网媒体传输，但云端的中心服务仍会消耗资源，跨内外网通信也可能继续产生分发成本。混合云的价值应落在具体通信路径的优化上，不能简单包装成“内网会议零成本”。

部署范围、网络依赖和成本构成需要放在一起解释。否则，销售和交付阶段一句模糊的“支持私有化”，就可能让客户对能力形成过大的预期。

本地资源利用率，与入会速度之间的取舍

服务器装进客户环境，并不意味着员工一定会优先使用它。

早期接入会同时尝试公有云和私有化节点，哪个先连接成功就用哪个。这种方式倾向于尽快完成连接，但客户部署本地节点后，会有另一种期待：既然投入了机器和网络资源，就希望内部会议尽量使用它们。

于是，我们增加了本地优先的接入规则：在一段可设置的等待时间内，优先尝试私有化节点；超过时限仍未连通，再转向公有云。同时，本地节点满载时仍保留公有云接入，避免为了提高本地使用率而继续向已满的节点施压。

这里的“优先”有明确边界。它表达的是资源使用偏好，不能被理解为无论网络和容量怎样，都必须接入本地。等待多久，也是在本地资源利用与用户入会体验之间作出的选择。

随后，新的使用场景暴露了串行等待的代价：员工从公司回到家里，本地节点可能已经不可达，但客户端仍要先等它超时，才能开始连接原本可用的公有云。一个为办公区优化的策略，给外部网络用户增加了等待。

后续优化方向便是将两件事拆开：公有云与本地节点同时尝试建连，但在设定的时间窗口内，仍优先选择本地节点；到期后，如果本地不可用，而公有云连接已经就绪，就可以直接使用。

这与早期“谁先连上就用谁”不同。并行尝试解决准备连接的耗时，选择规则继续表达客户的本地优先诉求。它也说明，资源偏好不必等同于操作顺序；把所有步骤串行化，往往会让一个合理偏好变成额外阻塞。

企业网络不能套用同一种连接方式

客户侧的差异，不只有员工从哪里入会，还包括各个办公区之间怎样连接。

早期私有化项目中，曾有企业要求不同分部之间的媒体通信统一经过总部。这符合当时的网络管理规则，但其他企业可能已经建设了办公区之间的专线，希望本地会议本地完成、跨区会议直接使用已有专线。若仍强制绕行总部或公有云，就会占用不必要的链路资源。

媒体服务器直连需求由此出现：允许不同办公区的本地媒体节点，通过客户已有网络直接交换音视频。

产品上需要改变的，是把针对某类企业形成的固定路径，转为能够适应不同网络条件的连接规则。企业已有网络不是等待服务商重建的一张白纸；是否有专线、哪些区域互通、哪里允许接入外网，都需要成为交付前明确的条件。

直连也有适用前提。当时的设计要求相关节点之间具备完整的网络连通条件，不能因为办公区 A 能连 B、B 能连 C，就假定 A 与 C 也能直接连接。企业网络的实际可达关系，必须与系统采用的分发方式一致。

虚拟机环境进一步放大了这类差异。在一种客户私有云环境中，媒体服务器能看到本机的虚拟网络地址，但其他区域的机器无法通过这个地址访问它。程序成功启动，与跨区域媒体能够互通，是两个不同的问题。

因此，虚拟机部署的适配需要处理实际可达地址的使用方式，而不能只验证安装成功。这类需求表面上是支持一种部署环境，实际涉及媒体服务对网络条件的假设是否成立。

每增加一条正常路径，都要检查故障时的路径

专线直连减少了绕行，也引入了必须单独处理的故障场景：两个办公区各自的服务器都正常，员工也能连接本地服务器，但办公区之间的专线出了问题。

这时，客户端已经接入成功，不能指望它最初的接入回退自动解决服务器之间的断路。直连能力之后，我们又把专线异常时回退到公有云媒体链路纳入补齐范围。

另一个缺口在节点本身。私有化节点出现故障后，如果调度仍继续选择它，就可能持续造成通话或节点间转发异常。因此，故障节点的自动摘除和避障，也需要作为专门的容灾能力建设。

这几件事不能合并成一句“支持自动回退”：客户端连不上本地节点、节点之间的链路故障、节点服务本身异常，发生的位置不同，所需的处理机制也不同。

公有云已经具备的保障，也不能仅凭两侧使用类似的媒体服务，就推定私有化环境天然具备。节点部署位置变了，网络条件和管理方式变了，故障识别与调度是否真正覆盖到客户节点，仍然需要逐项检查。

对于允许使用公有云兜底的混合云场景，回退能够成为连续通话的保障方向；对于完全隔离、依赖服务不同的全量私有化环境，则不能直接套用同样的承诺。路径是否可用，既取决于技术能力，也取决于客户允许的网络边界。

能运行，还要能进入企业的管理体系

公有云服务商可以统一安排自己的机器和运行环境，企业客户却已经有操作系统、部署平台和运维规范。

有的企业要求边缘机器上的所有服务统一以容器方式管理，有的只允许指定操作系统。早期混合云安装过程中虽然会创建容器环境，但安装管理所用的代理程序本身仍运行在容器之外。这意味着，即使媒体服务可以运行，整套部署仍未必符合客户的管理要求。

容器化需求因此不能只检查主要业务进程。需要纳入适配的，还有代理程序及相关运行依赖，让整套部署能够被企业现有方式管理。容器化在这里解决的是交付与纳管的障碍，不能仅用“技术上更先进”解释其价值，也不应被当成适配所有环境的保证。

当机器进入客户机房，企业 IT 还需要看得见它的状态。会议中的声音和画面由终端用户感知，资源是否紧张、当前负载如何，则是 IT 人员的日常管理问题。

因此，我们将 CPU、内存、媒体发送和接收带宽、并发负载等状态查询纳入能力设计，并考虑当前状态与历史数据两类需求。当前数据用于了解正在发生什么，历史数据则帮助回看会议高峰和资源变化，为后续调整提供依据。

指标还需要有清楚的含义。例如，媒体流并发数不能未经定义就直接变成参会人数；同一场会议中的不同媒体使用方式，会带来不同资源负担。对企业开放的数据，必须与它希望作出的管理判断相匹配。

这里也体现了平台与业务的分工：RTC 提供底层服务器状态，会议业务在自己的管理后台组织呈现。用户看到的是一套企业管理能力，底层则需要明确数据由谁提供、含义是什么。

客户需要控制权，不代表每个需求都要做成通用功能

企业还提出过按用户范围控制是否使用本地媒体节点的需求。例如，先让部分员工使用新部署的节点，或在遇到网络问题时，对比使用与不使用本地服务的表现。

这种诉求涉及试用范围、排查问题和客户信心，具有实际交付价值。但它不一定需要变成 RTC 对所有客户开放、长期维护的一套复杂管理功能。当时的取舍是以必要的调度支持满足业务，由业务承接用户范围管理，暂不扩展成通用产品能力。

控制使用范围，也不能代替稳定性建设。让客户缩小试用人群，可以降低验证阶段的影响范围，却不能据此认定故障节点已经能够自动避开。客户控制、运行数据和自动容灾，解决的是不同层面的问题。

混合云建设中的产品判断，需要同时面对两类使用者：员工希望顺畅入会、连续交流，企业 IT 则需要掌握资源、网络和管理边界。只满足其中一方，另一方的约束仍可能阻塞交付。

把公有云能力延伸到企业环境时，首先要定义本地化的对象和仍然存在的云端依赖，再围绕接入偏好、网络可达性、异常路径和运维方式检查整套服务。能够复用的差异应沉淀为平台能力，特定业务的管理逻辑则保留清楚的承接边界。私有化交付的可持续性，取决于这些规则能否适应客户环境，而不只取决于服务器是否安装完成。