云边协同的 RTC 如何助力即构全球实时互动业务实践

云边协同的 RTC 如何助力即构全球实时互动业务实践

作者:即构科技

由 51 CTO 主办的“WOT 全球技能创新大会 2023深圳站”于 11 月 24 日 – 25 日举行,即构科技后台技能总监肖潇以“边际容器在全球音视频场景的探究与实践”为主题进行同享。 边际核算作为中心云核算的补充,经过边际容器架构和云边协同,为音视频、云游戏、元宇宙等场景带来了更好的用户体会和事务价值。

云边协同的 RTC 怎么助力即构全球实时互动事务实践

讲师现场风采

肖潇说到,即构这种实时互动的事务场景,天然便是边际核算很契合的方法,原因便是边际核算在下降时延、本钱优化、进步并发、下降毛病影响等方面有非常显着的优势。即构科技根据在实时互动范畴的多年技能堆集与实践,落地了云边协同的全球音视频云架构:多云基础设施、边际容器、全球多中心、MSDN (Massive Serial Data Network)海量有序数据网络全球传输网络。这也协助即构建立了 “生于云、善于云”的云原生音视频云服务,进步实时音视频云服务质量和运维功率,经过多云 serverless 做好容灾, 并进一步优化本钱。

下面是肖潇在现场讲演的内容回顾:

边际核算遇到的问题及落地应战

即构运用边际核算多年,在最开端咱们的首要战略是租赁全球各种大规模的虚拟机和物理机。不同事务、不同的客户集群各自独占边际算力,进行自己系统内部的资源冗余,导致边际整体的运用率不高,本钱压力大。其次,面向边际没有一致的运维系统,各事务建造自己的事务支持系统,容量办理、扩缩容不一致功率比较低下。另外,中心布置的服务现已全面云原生化,运维团队在办理中心和边际的服务需求在两种思维方法以及在两套运维设施中切换,这很割裂,等候有一些新的改变。

咱们期望云原生的边际容器能带来三方面的改变:

  • 经过底层核算资源复用最大化的运用算力和带宽完成本钱的极致优化;
  • 经过云原生的弹性伸缩、多容器办理、版别更新机制大幅进步运维功率和可靠性;
  • 经过边际容器的落地,构建一个一致的云边一体化的云原生基础设施。

可是,企业在落地边际容器时会面对许多应战,首先,业界没有一致的边际容器标准,从产品维度,他们都拥有相同的产品要害字:云边协同、边际自治、单元化布置。咱们预研整理落地边际容器的一些应战,例如,音视频事务是强有状况服务,怎么云原生化?不同服务规格差异较大,怎么调度?音视频服务经常是两个进程协同完结作业,怎么做到 pod 多进程彻底独立的灰度发布?云边网络中断事务怎么处理?云边通信的流量本钱能否降到很低?怎么进步运维功率等等应战。

实时互动事务的落地实践

带着这些应战进行思考,即构根据在实时互动范畴的多年技能堆集与实践,落地了云边协同的全球音视频云架构:多云基础设施、边际容器、全球多中心、MSDN 全球传输网络。即构没有做成彻底分布式去中心化的架构,是由于咱们的事务是全球实时互动场景,500 机房之间 full mesh 进行同步功率太低,有中心的参加能大幅进步信息同步功率。

云边协同的 RTC 怎么助力即构全球实时互动事务实践

云边协同的全球音视频云架构

1、音视频服务云原生化

音视频服务是强有状况事务

音视频服务有点类似游戏服务器,有玩家在玩游戏,不能容易更新和缩容。音视频服务器除了有海量的用户接入,还有服务器之间的级联。服务器级联形成了一个流的分发网络,服务器节点的改变会导致分发网络的重建。虽然会经过 SDK 重试等战略下降这个网络重建的本钱和对用户体会的影响,可是仍是期望发布、扩缩容这些运维操作能尽量下降对音视频事务的影响。

详细来看,期望做到 IP 端口固定的无损直连;镜像更新,pod 不重建,下降 pod 重建从头调度耗时对事务影响;期望容器更新进程中,镜像拉取耗时是极短的,来下降推拉流的中断。有状况事务的扩容需求有多种事务目标来触发,缩容需求很精确的控制。一个 pod 内有两个容器,引擎容器和配套事务处理容器,期望这两个容器能够做到各自独立发布。有一些定向运维操作的需求。

主机网络削减网络损耗

咱们选择主机网络模式来削减网络损耗,这样的优点是不需求经过容器额定的网络虚拟化层,可是也带来了端口抵触的问题。咱们新建了一个 Daemonset,端口办理的服务,在节点上 pod 启动的时分负责进行端口的分配。

作业负载的选择、更新战略

前面咱们说到 K8s 自带的 workload 不满足音视频事务的生命周期办理,在这里咱们选择了 openKruise 的 cloneset 作为咱们的作业负载,重视它首要是看中它如下几块的才能:原地晋级、指定 pod 缩容、sidecarset 完成 sidecar 容器布置的才能、镜像预热的才能。

云边协同的 RTC 怎么助力即构全球实时互动事务实践

如上图所示,音视频引擎作为主容器、配套事务处理容器作为 sidecar 容器 ,sidecar 容器经过 webhook 注入到 pod 中,经过 cloneset 和 sidecarset 两种资源完成两个容器的独立灰度发布。社区的版别 sidecarset 并不支持 env from metadata 的原地晋级,咱们完善了这个才能,后续也会提 PR 贡献给到社区。根据 cloneset 和 sidecarset,咱们能进行下图所示的根据 partition 的百分比多阶段灰度发布。

云边协同的 RTC 怎么助力即构全球实时互动事务实践

原地晋级不能解决所有的更新问题

咱们知道原地晋级的触发条件首要是 spec container 的镜像改变以及 env from metadata 中 label 和注解的改变,可是 cloneset yaml 的其他字段需求修正的时分咱们怎么能做到防止 pod 的重建从而使对事务的影响接近于零呢,即还能保持 IP 端口的稳定?对这种情况咱们完成了一个 clonesetmigration 的 operator 来和谐这个进程。

云边协同的 RTC 怎么助力即构全球实时互动事务实践

镜像预热

咱们在计划选型的时分对比剖析了镜像预热和边际 P2P 镜像分发这两种方法。对比的进程中咱们发现 dragonfly 这种 P2P 镜像分发关于边际场景运维仍是偏杂乱,由于它要求一个 P2P 网络中服务网络有必要是互通的,那关于较大的边际机房 P2P 网络是内网能有很好的作用,但关于多个较小的边际机房又需求分区域组成一个外网的 P2P 网络,可是音视频又是高带宽的服务,为了不影响事务在节点和任务的维度都会要求有限速,显着的限速又影响到 P2P 镜像的拉取作用。于是回到了咱们的中心诉求,原地晋级时镜像拉取的耗时足够低,那 OpenKruise 每一阶段灰度发布时 node 的提前镜像预热 镜像仓库多地域布置现已能满足咱们的诉求。

音视频场景下的弹性伸缩

音视频场景下弹性伸缩咱们区别于社区的 HPA 计划,咱们做的是带音视频事务状况的伸缩计划,扩容会多维度目标综合评估,从带宽、PPS、推拉流数、CPU、内存等多目标进行核算,缩容有点特殊,在有用户在推拉流的时分不能直接进行缩容操作,需求做事务的无损整理,不然容易带来用户的黑屏、卡顿。假如咱们设计了 pod 事务状况的状况机,有初始化、已分配、石碑态和等候被删除几种状况。其间石碑态是要害的状况,进入这个状况会从事务层面不进行新请求和流量被调度进来等候流量的天然消亡,以及超时后的接近无损的驱赶和整理,当然假如石碑态的进程中流量上涨会将事务状况回退到已分配状况持续服务事务。

2、质量和运维功率进步

在边际容器的质量和运维功率进步方面,即构在成立之初就自研了“海量有序数据网络 MSDN”,实时勘探网络质量,能够完成全球范围内优质的智能调度及路由,链路毛病秒级恢复,大幅下降云边断网概率,进步数据传输速度及可靠性。即构还根据机器学习算法预测边际机房未来运用率,生成扩容、缩容资源 node 数,然后根据这个推荐数据主动进行边际节点购买/纳管、cordon/drain/节点退订,完成边际资源池的智能化推荐、扩缩。此外,即构经过全球边际容器控制面的多集群办理,完成全球资源一致办理。

肖潇还说到,关于云边协同的另一种风趣的方法——多云 Serverless 容灾。

当边际容器控制面所在的中心 region 毛病的时分,由于边际自治的原因,边际容器仍旧能够正常运转,可是会影响到服务的扩容才能和容量水位。这个时分咱们的一种容灾方法是经过在多云商不同中心机房的 serverless 集群的扩容进行这部分弹性容量的补齐。其次,用中心机房 Serverless 承载边际资源池的突发溢出流量也非常有价值。这种溢出往往是临时性的突然打高,经过边际带宽承载日常流量加 Serverless 流量计费承载突发流量,能够完成网络本钱的最优组合。这里也充沛用到了中心机房 Serverless 极致的弹性才能。

3、本钱优化

边际资源的最大化同享。运用边际容器的边际资源池能够做到不同的事务集群或事务角色能同享相同的资源池,经过整个资源池的资源冗余来防止在事务集群和服务维度各自的资源冗余。其次咱们有全局多级资源池调度,上一级满了会溢出到下一级,完成在资源池全局资源的复用,和恣意区域 N-2 机房资源的冗余。

资源调度战略。根据实时音视频场景思考,咱们把默认的 Spread 调度战略改成 Binpack 调度战略,它会优先将 pod 调度到资源消耗较多的节点,多个 pod 会优先运用同一节点来进步整个资源的运用率,相较于虚拟机和物理机时代作业负载进步了一倍。

关于本钱,即构重视怎么大幅下降云边通信的流量的本钱。以 OpenYurt 为例,首先要尽量削减 Service 和 EndpointSlice 的运用;第二,kubelet、daemonset list-watch 资源要 label 筛选本节点的数据,削减重视度;第三,以 Openyurt 为例,经过 Pool-Coordinator 和 Yurthub 的协同,完成单一节点池内云边只要一份 pool scope data 数据通信,当然 pool-coordinator 机制带来的优点,能区分出云边断网和节点宕机。

未来展望

未来即构会从三方面下手,一是探究更适合事务的调度算法, 对核算密集型的事务敞开 CPU 拓扑感知调度的才能、供给 GPU 调度从而完成更全的事务覆盖;其次,经过更多东西链系统的建造和更多的才能抽象,进一步下降事务接入边际容器的本钱, 完成分钟级的布置;第三,把更多的才能在边际侧进行供给。

即构将会持续推进边际容器在全球音视频场景的进一步探究和使用!