火山引擎veRTC场景下高可用云边通信实践

如果无法正常显示，请先停止浏览器的去广告插件。

1. 火山引擎veRTC场景下高可用云边通信实践字节跳动 / 游望秋

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.