火山引擎veRTC场景下高可用云边通信实践
如果无法正常显示，请先停止浏览器的去广告插件。
1. 火山引擎veRTC场景
下高可用云边通信实践
字节跳动 / 游望秋
2.
3. 大纲
• veRTC云边协同场景
• veRTC云边协同的特点和挑战
• veRTC高可用云边通信架构介绍
4. veRTC业务场景
veRTC
Real Time Communication
实时音视频
直播连⻨ 视频会议 云游戏
物联网 互动课堂 游戏语音
特点
全球范围内的实时音视频互动
5. veRTC全球化架构
边缘就近接入云端
用户就近接入
SDN网络
云端⻣干网
边缘服务器
全球实时音视频云
1. 边缘全球下沉，用户就近接入
2. 全球实时流媒体传输网
3. 全球实时信令传输网
4. 边缘计算，云边协同
云端数据中心
3. 信令数据从边同步到云端
在云端进行全球同步
2. 业务逻辑边缘
本地处理
5. 媒体流传输
4. 用户就近接入边缘
从云端获取流信息，进行拉流
1. 用户就近接入，进行推流
6. veRTC全球化架构中的云边协同
云边协同场景
边缘就近接入云端
用户就近接入
1. 房间、用户、流信息的上报和推送
SDN网络
2. 控制信令传输
云端⻣干网
边缘服务器
3. 媒体节点信息上报
4. 流媒体网络带外控制
云端数据中心
3. 信令数据从边同步到云端
在云端进行全球同步
2. 业务逻辑边缘
本地处理
5. 媒体流传输
4. 用户就近接入边缘
从云端获取流信息，进行拉流
1. 用户就近接入，进行推流
7. 大纲
• veRTC云边协同场景
• veRTC云边协同的特点和挑战
• veRTC高可用云边通信架构介绍
8. veRTC云边协同的特点-可靠性
可靠性要求高
• 信令系统依赖中心作为超级大脑，边缘无法自治
• 媒体网络依赖云边通信做带外控制
• 下线边缘会对用户体验产生严重影响
信息上报
信息上报
推送
推送
云边通信异常可能会导致
• 用户通话无法建立
媒体传输
• 边缘失联导致用户断开重连，导致卡顿黑屏
• 媒体网络避障异常，导致通话失败
建立通话
9. veRTC云边协同的特点-实时性
实时性要求高
• 各类实时互动的业务场景对控制信令的实
时性要求高
信息上报
信息上报
推送
推送
云边消息延迟上升100ms会导致
• 3s/5s 进房成功率下降3%
• 首帧延迟上升600ms
建立通话
10. veRTC云边协同的特点-成本
带宽消耗小
• 只用来传输控制信令、不传输媒体流
信息上报
信息上报
推送
推送
• 每100w PCU 云边通信带宽 2Gbps
建立通话
11. veRTC云边通信的挑战-基建
边缘
1. 边缘分布广而下沉，故障率高
•大部分节点无法建设专线
云边通信
故障
•公网的可靠性不高
2. 云机房故障无法避免，影响面大
• 边缘出口故障
• DNS故障
• 云端出口故障
• 4/7层LB故障
云端
中间
链路
• 地区网络故障
• 云边专线故障
• 动态加速故障
12. veRTC云边通信的挑战 - 延迟、容灾与容量
地区A
云端DC1 地区B
云端DC2 地区C
云端DC3
边缘1 边缘2 边缘3
地区A
云端DC1 地区B
云端DC2 地区C
云端DC3
正常场景
边缘就近接入
当有多个云机房存在，边缘该如何连接？
故障场景
边缘分流到其他云端DC
80%
边缘1
20%
边缘2
边缘3
13. 业界常⻅的云边通信方案
基于公网构建VPN隧道
OpenYurt/Raven
基于⻓连接
KubeEdge
14. 业界常⻅的云边通信方案
业界方案提供了
1. 基于公网构建对业务透明的云边网络通信能力
2. 支持通过QUIC等协议提高云边通道的可靠性
3. 提供了云原生管理能力
应用到veRTC的场景，没有解决的问题：
1. 云边链路单一，故障时如何容灾容错
2. 如何尽可能降低云边通信延迟
3. 多中心架构中边缘到中心的流量调度
15. 大纲
• veRTC云边协同场景
• veRTC云边协同的特点和挑战
• veRTC高可用云边通信架构介绍
16. veRTC云边通道架构演进
v1 各服务基于⻓
连接自行实现
v2 中心化网关
架构
v3 去中心化
网格架构
17. v1 各服务基于⻓连接自行实现的云边通道
Cloud
service B
service A
各个服务通过grpc/ws⻓连接实现云边双向通信
存在的问题：
1. 每个服务需要单独做运维配置
2. 大量冗余开发工作
3. 高可用能力欠缺，且各个服务不一致
grpc
websocket
edge node
Edge Cluster
service A
service B
18. v2 中心化网关版本
边缘端
• 边缘服务集成SDK接入
云端
• 中心化网关服务cloud gateway，用于管理
⻓连接以及转发云到边和边到云的数据
传输通道
• MultiPath Transport：基于边缘和中心保活
一组异构链路的⻓连接实现的高可用通道
Cloud
service
service
service
cloud gateway
multiPath Transport
edge node
Edge Cluster
service service
SDK SDK
19. Multipath Transport 如何保证高可用
引入多种类型（10+）的异构链路
• 我们曾经遇到的故障
各种故障场景下，总能够保证有链路可以连到中心
• 云端网关服务故障
专线直连（如有）
• 云端入口LB 硬件故障
公网域名直连
• 云端入口运营商线路故障
• 云边专线故障
• 域名DNS故障，无法解析
• 域名配置变更时误配置，导致域名不可用
• 区域性网络故障，如新疆/内蒙古区域到北京
故障，但是从深圳绕行可以连通
• 边缘机房出口故障，三线机房，单个运营商
出口故障
动态加速
LB
多个供应商
动态加速域名
LB
Edge
运营商
出口1
边缘出口异构
中心LB
冗余
Cloud
区域汇聚点专线转发
区域汇聚点
公网
专线
运营商
出口2
LB
中心直连边缘
NAT
20. Multipath Transport 如何保证高可用 - 异构链路
异构链路带来的优势
如何将可靠性做到更加极致？
• 当链路故障发生时，可以进行链路切换，及时
专线直连（如有）
避障
公网域名直连
• 日常发送消息时，可以选择延迟最低的链路进
行发送，降低延迟
• 边缘无论是否有专线覆盖都能充分利用链路资
源
问题
• 故障发生后进行链路切换，仍然导致云边通信
动态加速
多个供应商
动态加速域名
LB
Edge
运营商
出口1
边缘出口异构
中心LB
冗余
Cloud
区域汇聚点专线转发
区域汇聚点
公网
专线
运营商
出口2
LB
短暂受损。中心LB、区域汇聚点出现故障时可
能会导致短暂的大面积受损
LB
中心直连边缘
NAT
21. Multipath Transport 如何保证高可用 - 多径
veRTC 云边消息的特点
主要是控制信令，带宽消耗小，优先级高，天然
适合多径冗余发送
多径发送流程
• 对所有链路进行探测，选择最好的两条链路发
送消息
• 中心网关收到消息后进行去重，去重后转发到
下游业务
• 单链路故障业务无感知，多链路故障秒级恢复
公网直连
Edge
Cloud
区域汇聚点
22. Multipath Transport 如何保证高可用 - 协议
MultiPath Transport
发送队列
MultiPathTransport 在多个链路的
⻓连接池
ackID = 3
id=6
id=5
id=4
id=3
id=2
id=1
active
链路1
active
链路2
冗余发送的基础上实现了类似TCP
的ACK重传机制。支持保序、自动
重传
recv
ackID=3
如何去重？
send
id=1,2,3,3
send
id=3
23. 如何高效去重
service
异构链路的情况下，每个链路 LB都有
Cloud
service
cloud gateway
pod1
service
cloud gateway
pod2
service
cloud gateway
pod3
自己的负载均衡策略， LB 可能会将⻓
连接路由到不同的中心网关实例，增
LB
LB
加去重难度
Edge
24. 如何高效去重 - v1 基于Redis实现去重
Cloud
问题：
cloud gateway
pod1
链路1 消息
不重复
1. 增加消息处理延迟，降低并发
2. 引入强依赖，降低可靠性
LB
链路2 消息
消息重复
丢弃
cloud gateway
pod2
消息投递
service
pod
25. 如何高效去重 - v2 TLB一致性Hash去重
LB是否可以直接将消息投递到同一个云端网关实例？ 问题：
Yes！ 通过对于同一个边缘的⻓连接，配置相同的 扩容、云网关升级场景，hash环会发生变化，各个LB实例
hash策略 的感知速度不一样，会出现结果不一致，导致消息重复
Cloud
cloud gateway
pod1
cloud gateway
pod2
hash_key=edge1
Cloud
cloud gateway
pod1 cloud gateway
pod2
LB LB
hash_key=edge1
hash_key=edge1
LB
LB
Edge1
Edge
cloud gateway
pod3
26. 如何高效去重 - v3 Converge Routing
最终方案：
定制LB网关，将连接过程拆分成短链和⻓链两步
• 边缘启动时通过短链请求中心控制面分配网关实例地址，控制面引入redis保证一致性①
• 边缘创建⻓连接时带上①中分配的地址，LB根据地址将⻓连接打到指定地址的网关实例上②
• cloud gateway在内存中完成消息去重③，最后转发到下游业务实例
Cloud
cloud gateway
pod1
①通过短链分配网关地址
链路1
Edge
LB
cloud gateway
pod2
链路2
service pod
区域汇聚点
②创建⻓连接时
带上upstream
LB
链路3
通过redis
保证一致性
cloud gateway
pod3
③内部去重
转发消息到
下游业务实例
27. 如何降低⻓连接保活的开销？
所有链路
数量15
每1000个边缘节点 -> 750K个保活的⻓连接
1000个边缘 * 5个边缘服务 * 15个链路 * 10个连接
解决方案：
• 短链探测，探测通道与消息通道分离
• 链路分级，按需保活，降低80%的保活开销
• 活跃链路和非活跃链路实时转化，保证容灾能力
active+keepalive 链路 * 3
保活⻓连接
可用于云端push
active
active
转化
standby 链路
数量12
不保活⻓连接
standby standby
standby standby
keepalive
…
28. 中心化架构存在的问题
Cloud
service
service
service
cloud gateway
multiPath Transport
Edge Cluster
edge node edge node
service service
SDK SDK
1. 多个service共用cloud gateway集群，资源无法
隔离
2. cloud gateway本身是有状态服务，实现平滑升
级依赖裸机部署，运维复杂度高
3. cloud gateway 成为业务核心链路上的强依赖，
出问题时影响面很大
能否去掉cloud gateway服务？
29. v3 去中心化网格架构 - 控制转发分离
控制面
• 分配服务实例地址
• ⻓连接信息管理
• 边缘流量调度
数据面
• 链路质量探测
• ⻓连接保活
• 云边数据传输
1. 业务资源完全隔离
2. 无需单独考虑网关的平滑升级
3. 去除单点强依赖
4. 减少网关 <-> 业务实例的调用开
销
control_plane
同步⻓连接元信息
Cloud
service pod service pod service pod
agent agent agent
内部转发
multiPath Transport
Edge Cluster
edge node edge node
service service
SDK SDK
短链请求
分配
业务实例地址
30. v3 去中心化网格架构 — 云端故障容错
单实例故障
• 控制面：无状态服务，自动切换实例
控制面实例
故障
control_plane
Cloud DC1
control_plane
service pod1
数据面实例
故障
service pod2
• 数据面
切换— ②
control_plane
service pod1
②数据面实
例切换
• 边缘上报故障到控制面，控制面重新分配实例，秒级
Cloud DC2
①控制面实
例切换
③数据面云
端机房切换
• 如⻓时间无法恢复，自动切换到其他互备云上机房—
③
云端机房大规模故障
• 控制面下发切流操作，支持从多个云端机房下发操作，
保证操作一定能够成功 — ④
④控制面下
发切流指令
Edge
31. 异地多活场景下的云边流量调度
云端多机房
异地多活
控制面
云端异地多活场景
要综合考虑延迟+容量，否则云端机房容
地区A
云端DC
量被打满
综合云边延迟进行流量调度
地区B
Edge
地区B
云端DC
容量信息上报
挑战：云端机房容量不对等，容灾时需
策略：控制面感知云端机房容量信息，
调度策略下发
地区C
云端DC
调度策略下发
容灾切换
地区A
Edge
调度策略下发
地区C
Edge
32. 云边通道稳定性数据（2023年）
避障次数
25次
月均减少故障时⻓
75分钟
MTTR
<5s
年事故数量
0次
33.