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

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