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

字节跳动 / 游望秋 ⼤纲 •veRTC云边协同场景•veRTC云边协同的特点和挑战•veRTC⾼可⽤云边通信架构介绍 veRTC业务场景 veRTCReal Time Communication实时⾳视频 视频会议 直播连⻨ 云游戏 特点 全球范围内的实时⾳视频互动 物联⽹ 互动课堂 全球实时⾳视频云 1.边缘全球下沉，⽤户就近接⼊2.全球实时流媒体传输⽹3.全球实时信令传输⽹4.边缘计算，云边协同 云边协同场景 ⼤纲 •veRTC云边协同场景•veRTC云边协同的特点和挑战•veRTC⾼可⽤云边通信架构介绍 veRTC云边协同的特点-可靠性 可靠性要求⾼ •信令系统依赖中⼼作为超级⼤脑，边缘⽆法⾃治•媒体⽹络依赖云边通信做带外控制•下线边缘会对⽤户体验产⽣严重影响 云边通信异常可能会导致 •⽤户通话⽆法建⽴•边缘失联导致⽤户断开重连，导致卡顿⿊屏•媒体⽹络避障异常，导致通话失败 veRTC云边协同的特点-实时性 实时性要求⾼ •各类实时互动的业务场景对控制信令的实时性要求⾼ 云边消息延迟上升100ms会导致•3s/5s进房成功率下降3%•⾸帧延迟上升600ms veRTC云边协同的特点-成本 带宽消耗⼩ •只⽤来传输控制信令、不传输媒体流•每100w PCU云边通信带宽2Gbps veRTC云边通信的挑战-基建 1.边缘分布⼴⽽下沉，故障率⾼•⼤部分节点⽆法建设专线•公⽹的可靠性不⾼2.云机房故障⽆法避免，影响⾯⼤ veRTC云边通信的挑战 - 延迟、容灾与容量 当有多个云机房存在，边缘该如何连接？ 业界常⻅的云边通信⽅案 基于公⽹构建VPN隧道OpenYurt/Raven 业界常⻅的云边通信⽅案 业界⽅案提供了 1.基于公⽹构建对业务透明的云边⽹络通信能⼒2.⽀持通过QUIC等协议提⾼云边通道的可靠性3.提供了云原⽣管理能⼒ 应⽤到veRTC的场景，没有解决的问题： 1.云边链路单⼀，故障时如何容灾容错2.如何尽可能降低云边通信延迟3.多中⼼架构中边缘到中⼼的流量调度 ⼤纲 •veRTC云边协同场景•veRTC云边协同的特点和挑战•veRTC⾼可⽤云边通信架构介绍 v1 各服务基于⻓连接⾃⾏实现的云边通道 各个服务通过grpc/ws⻓连接实现云边双向通信 存在的问题： 1.每个服务需要单独做运维配置2.⼤量冗余开发⼯作3.⾼可⽤能⼒⽋缺，且各个服务不⼀致 v2 中⼼化⽹关版本 边缘端 •边缘服务集成SDK接⼊ 云端 •中⼼化⽹关服务cloud gateway，⽤于管理⻓连接以及转发云到边和边到云的数据 传输通道•MultiPath Transport：基于边缘和中⼼保活⼀组异构链路的⻓连接实现的⾼可⽤通道 Multipath Transport 如何保证⾼可⽤ 引⼊多种类型（10+）的异构链路各种故障场景下，总能够保证有链路可以连到中⼼ •我们曾经遇到的故障 •云端⽹关服务故障•云端⼊⼝LB硬件故障•云端⼊⼝运营商线路故障•云边专线故障•域名DNS故障，⽆法解析•域名配置变更时误配置，导致域名不可⽤•区域性⽹络故障，如新疆/内蒙古区域到北京故障，但是从深圳绕⾏可以连通•边缘机房出⼝故障，三线机房，单个运营商出⼝故障 Multipath Transport 如何保证⾼可⽤ - 异构链路 如何将可靠性做到更加极致？ 异构链路带来的优势 •当链路故障发⽣时，可以进⾏链路切换，及时避障•⽇常发送消息时，可以选择延迟最低的链路进⾏发送，降低延迟•边缘⽆论是否有专线覆盖都能充分利⽤链路资源 问题 •故障发⽣后进⾏链路切换，仍然导致云边通信短暂受损。中⼼LB、区域汇聚点出现故障时可能会导致短暂的⼤⾯积受损 Multipath Transport 如何保证⾼可⽤ - 多径 veRTC云边消息的特点主要是控制信令，带宽消耗⼩，优先级⾼，天然适合多径冗余发送 多径发送流程 •对所有链路进⾏探测，选择最好的两条链路发送消息•中⼼⽹关收到消息后进⾏去重，去重后转发到下游业务•单链路故障业务⽆感知，多链路故障秒级恢复 Multipath Transport 如何保证⾼可⽤ - 协议 MultiPathTransport在多个链路的冗余发送的基础上实现了类似TCP的ACK重传机制。⽀持保序、⾃动重传 如何⾼效去重 异构链路的情况下，每个链路LB都有⾃⼰的负载均衡策略，LB可能会将⻓连接路由到不同的中⼼⽹关实例，增加去重难度 如何⾼效去重 - v1 基于Redis实现去重 问题： 1.增加消息处理延迟，降低并发2.引⼊强依赖，降低可靠性 如何⾼效去重 - v2 TLB⼀致性Hash去重 LB是否可以直接将消息投递到同⼀个云端⽹关实例？Yes！通过对于同⼀个边缘的⻓连接，配置相同的hash策略 问题： 扩容、云⽹关升级场景，hash环会发⽣变化，各个LB实例的感知速度不⼀样，会出现结果不⼀致，导致消息重复 如何⾼效去重 - v3 Converge Routing 最终⽅案： 定制LB⽹关，将连接过程拆分成短链和⻓链两步 •边缘启动时通过短链请求中⼼控制⾯分配⽹关实例地址，控制⾯引⼊redis保证⼀致性①•边缘创建⻓连接时带上①中分配的地址，LB根据地址将⻓连接打到指定地址的⽹关实例上②•cloud gateway在内存中完成消息去重③，最后转发到下游业务实例 如何降低⻓连接保活的开销？ 每1000个边缘节点->750K个保活的⻓连接1000个边缘* 5个边缘服务* 15个链路* 10个连接 解决⽅案： •短链探测，探测通道与消息通道分离•链路分级，按需保活，降低80%的保活开销•活跃链路和⾮活跃链路实时转化，保证容灾能⼒ 中⼼化架构存在的问题 1.多个service共⽤cloud gateway集群，资源⽆法隔离2.cloud gateway本身是有状态服务，实现平滑升级依赖裸机部署，运维复杂度⾼3.cloud gateway成为业务核⼼链路上的强依赖，出问题时影响⾯很⼤ 能否去掉cloud gateway服务？ v3 去中⼼化⽹格架构 - 控制转发分离 控制⾯ 数据⾯•链路质量探测•⻓连接保活•云边数据传输 •分配服务实例地址•⻓连接信息管理•边缘流量调度 1.业务资源完全隔离2.⽆需单独考虑⽹关的平滑升级3.去除单点强依赖4.减少⽹关<->业务实例的调⽤开销 v3 去中⼼化⽹格架构 — 云端故障容错 单实例故障 •控制⾯：⽆状态服务，⾃动切换实例•数据⾯•边缘上报故障到控制⾯，控制⾯重新分配实例，秒级切换—②•如⻓时间⽆法恢复，⾃动切换到其他互备云上机房—③ 云端机房⼤规模故障 •控制⾯下发切流操作，⽀持从多个云端机房下发操作，保证操作⼀定能够成功—④ 云端异地多活场景挑战：云端机房容量不对等，容灾时需要综合考虑延迟+容量，否则云端机房容量被打满策略：控制⾯感知云端机房容量信息，综合云边延迟进⾏流量调度 云边通道稳定性数据（2023年） 避障次数25次⽉均减少故障时⻓75分钟年事故数量0次MTTR<5s