乐趣区

关于人工智能:声网王浩宇RTE-场景下的-Serverless-架构挑战RTE-2022

前言

在「RTE2022 实时互联网大会」中,声网云原生边缘计算团队的负责人 @王浩宇 Dylan 以《RTE 场景下的 Serverless 架构挑战 —— 声网如何兼顾后端服务的牢靠、高效和疾速迭代》为题进行了主题演讲。

这也是声网第一次在 RTE 大会上,对外分享外部的一些后端技术实际。置信大家也始终比拟好奇,声网如何在宽泛的 RTE 利用场景下解决服务的高效扩大问题。

以下内容基于 @王浩宇 Dylan 于大会中演讲内容整顿,为不便浏览略有删改。


01 实时互动后端技术演进

先看一下三个次要的业务需要:

一是一直暴发的新互动场景。从 RTC 的视频、推流、录制、鉴黄的根底能力,到 RTE 的灵动课堂、互动游戏、一起 KTV、空间音频、AI 声纹等等。当初的互动场景越来越简单,相比以前仅仅须要满足音视频的互通,曾经到了须要同时兼顾简单的信令过程、简单的数据交互。

二是谋求更加稳固牢靠的极致品质。从本来的低提早、低卡顿率,回升到 RTE 实时互动体验的质量标准 XLA;须要去反对异常情况下的智能容灾,异样主动复原。

三是麻利高效的大规模扩大能力。实时扩容,反对超大规模的业务场景弹性,以低成本笼罩寰球各个国家和地区。

以上这些,都是让实时互动更加易用、更加遍及的能力和需要。

在讲声网如何解决这些场景需要之前,我想先跟大家讲一下这些年在各种边缘云和私有云场景下,以后的一些典型架构模式。

在边缘上最传统也最成熟的模式是 CDN 的散发。这种架构经验了几十年的演进,曾经十分的成熟稳固。最常见的场景像基于 CDN 的直播、边缘函数、IoT 等等。

基于 CDN 的场景也可能高效的满足弹性、扩大、笼罩的问题。它的劣势在于,这样的一个简略动态配置,个别只用关注一个链路切换就能够实现横向的边缘扩容。但这种场景下只能解决散发、传输和接入能力,没有方法去实现简单的多项交互的业务。

当初的互联网业务简直都是云化的,私有云场景通过这些年的倒退,简直能反对所有的互联网业务。它具备齐备的贮存、计算、事务等各种云服务和中间件的能力,易用性和扩展性良好。但有一个问题是链路很简单,用了云之后意味着重度依赖基建的可靠性,任何一环都不能出问题。

大家也晓得声网根本是不必私有云的,也用不了 CDN。咱们提出了本人的实时互动边缘云,心愿能在咱们的边缘云上同时具备边缘的灵便和云的健壮,可能在边缘实现简单的实时互动逻辑,不依赖专线实现牢靠传输,解决数据和状态的寰球同步。

咱们心愿做到又快又好,在任意环境都能够运行,笼罩寰球的每一个角落。去反对从密集计算的突发工作,到有状态服务在内的任意负载,可能去 Serverless 化,反对动静的资源分配和弹性伸缩。

不同于传统的中心化模式,声网其实并不需要相似 CDN 的回源这类的外围节点,整体架构都做了去中心化。益处是能够彻底解脱对机房和运营商的依赖,也不须要对基础设施做很高水平的可用性保障。

另外一方面,云的易用性带来了复杂度的急剧增长,故障概率和影响范畴也进一步加剧。这些年不论是国内上的一些巨头还是国内的一些厂商,根本都呈现过大范畴的故障。并且如果是骨干网或者运营商故障,很多状况下是没有方法挽回的,云网络底层的 BGP 协定一旦在路由层面出问题,可能影响整个大洲。例如北美最近一两年曾经遇到过屡次私有云简直整体断网的状况。

声网心愿可能在实时互动边缘云上做到真正的反脆弱性,所以会对任何的基础设施去做肯定的故障预设。咱们的服务至多满足 N-3 的冗余度,意味着不会依赖任何繁多的基建或者运营商,在任意区域均可接受 3 个机房故障不影响可用性。

02 实时互动 x 边缘 Serverless

上述几点在过来几年咱们重复提及过,明天想要给大家讲的是在边缘云的能力上,Serverless 如何进一步驱动业务翻新。

这里次要有几个点:

  • 提供了统一化的云能力

不同的 RTC、RTE,包含录制、推流、RTIC 等业务之间,都须要一个可复制的架构能力,去保障开发者在应用不同云服务的时候,均能享受到雷同程度的弹性,可扩展性和健壮性的服务。

  • 齐备的调度笼罩和寰球扩大能力

想要真正做到齐备的调度笼罩和寰球扩大,不是独自的某一个业务做到,而是须要所有业务都做到。咱们的 Serverless 能够在有服务器和网络的中央实现即刻笼罩,不须要思考机器的规格如何,通过负载平衡机制都能去实现最优的调配策略,满足品质与负载的均衡。

  • 专一于业务迭代

为了给开发者实现最大水平的价值,咱们要满足更快的需要交付。声网外部研发在无需关注底层资源的同时,会享受到丰盛的流量调度和灰度能力。对外大家能看到的理论体现,就是声网这些年互动利用的一直暴发。

  • 高性价比

同时,咱们也须要给开发者提供最高性价比的服务。声网利用极致的灵便与弹性的边缘资源,可能代替私有云惨重的基建老本,不必去购买低廉的私有云的带宽以及专线。

在这些需要之外,声网是如何真正在边缘实现所有相似的利用落地,这外面又有什么挑战?我想先用一个略微有点简单的小表格,来跟大家讲一下。

在讲挑战之前,咱们先提一个传统意义上原生利用架构跟实时互动利用的区别。

云原生利用很多时候大家都在讲无状态性,但所有的实时互动利用简直都跟流无关。streaming 意味着信息的高效传递,所有的数据都在毫秒级的工夫传达到对方。咱们没有方法再去做一个无状态协定,把流做切片。

置信大家也晓得,如果用 HLS 的协定去拉流,它的提早比 RTC 会差出一个数量级或更多。所以在实时互动利用场景下,肯定会抉择用有状态的实时流服务去实现业务,谋求在性能、老本、可能性层面,都做到极体验致,但代价就是须要去治理这里的复杂度,无论是扩容、迁徙、降级、保护,扩大,所有都变得十分的麻烦。

过来云厂商包含一些互联网大厂,也都在做面向无状态服务的 Serverless 架构,让大家都能有各种各样的函数服务去解决这种短暂无状态利用,包含对冷启动工夫不敏感的场景,这是迄今为止 Serverless 的技术白皮书当中举荐的场景利用模式。但这样的 Serverless 计划,从运行环境、API 到运行工夫层面,都是层层受限的。

咱们在实现一些像音视频之类比拟重的业务时,不论是启动工夫还是业务的运行时长,或者是须要用到的各种各样的 API,都会对基建能力和 Serverless 能力提出全新的高要求。

以录制场景为例,最早声网在没有提供外部的云能力之前,也是让客户用 SDK 录制,也就是一个 Linux SDK。这种在服务端跑 SDK 的益处就是不受限,想实现各种各样的业务场景都能够,非常灵活。

然而 SDK 录制也有几个十分显著的问题:

  • 机房 / 云厂商网络稳定影响录制品质
  • 扩缩容艰难,部署保护简单
  • 跑起来简略,高可用难

咱们发现,如果要想把实时互动场景做好,必须要把各种各样的简单的有状态服务,帮忙客户简化复杂度,基于此咱们推出了云录制。

当然除了录制外,声网还有大量其余的业务场景,因为工夫关系咱们就拿录制这一个例子来举例,也不便大家来了解。

简略来说,开发者不再须要保护一个有状态的服务,只须要调声网的一个无状态的 RESTful 接口,就能够实现频道的录制。

咱们来具体看一下,录制场景当中 Serverless 会带来哪些挑战。简略来说这外面有几条:

  • 不确定负载,依据主播人数帧率码率不同实时变动
  • 有状态持续性工作,频道可能继续数小时乃至数天
  • 保障工作唯一性的同时容许更新工作
  • 强实时性和可靠性,无奈承受丢路与黑屏
  • 需满足全球化场景,即便主播和最终录制存储区域不同。例如:

    ° 客户服务器在新加坡发动录制

    ° 主播在中东接入 RTC

    ° 录制文件上传到北美

通常来说,这些场景中的传输问题,客户往往没有方法自行搞定。因而在实时互动边缘云场景中,声网提出了如下图所示的架构:

声网有一套叫 UAP 的云原生边缘利用平台,能够就字面意义了解为通用利用平台。开发者能够在下面运行任意的利用代码。

两头是 RTE Runtime,能够了解为声网外部的服务端 SDK。下面的任意利用代码能够被跑在任意地位,UAP 平台会帮大家去治理资源编排、容量布局、迁徙治理、负载感知、智能调度、动静组网在内的边缘场景下的问题。

总的来讲,咱们心愿通过对底层资源包含对边缘复杂度的封装,让业务可能只关注在最上层的利用代码的开发。同时大家也能够把这个平台设想成一个 Linux SDK,能够用来做各种各样的 RTE 的场景。

为了不便大家了解相干概念,给大家看一个简略的例子。

上图左下角是一个 golong 的例子,借助 UAP 能够用一个十分小的 library 疾速的把任意的代码逻辑集成进来。这里的运行环境是不受限的,开发者能够用任意的容器负载放进来,同时咱们提供一个齐全云原生化的利用标准和规范,做到分钟级的部署。

上图右侧是声网外部的一些 CRD。在这个 Demo Serverless 的例子中,咱们定义了几个 worker,用了一个自定义的 demo 镜像,Request 的一部分资源。在分钟级的工夫内,就能够把这样的一个 Demo Serverless 推广到寰球的各个边缘上。

同时业务不须要管节点跑在哪、怎么连到它,整个过程都是有动静注册、动态分配的,这一点前面咱们会具体来讲。

当然这是最简略的一个集成的场景,还有很多其余的功能模块能够按需扩大。

上面来讲一下,刚刚说的接入调配的过程。

上图左侧的示例图有些简单,所以我做了一个简化,大家能够看左边的这三个小圆圈。

咱们在做任何边缘业务的时候,第一步要思考的就是调度,也就是须要满足哪些不同场景。比如说可能有些是对负载比拟敏感,有些对时延比拟敏感,有些对地理位置比拟敏感,这些条件都会由算法布局进去一个最佳的调度策略。

同时业务也能够在下面去自定义想要的业务逻辑。比方可能想要多个不同的版本,想在不同的区域用不同的版本,包含可能准确到不同的业务场景去用不同的版本,又或者可能他有本人的业务属性,在他的业务属性下能够进一步去管制更简单的策略。

比如说像汇聚,最终在端测声网的 SDK 也会去实现一个动静组网,实现汇聚→迁徙→重连的高可能闭环。通过这几个步骤的整合,基本上能够帮业务做到透明化。

在调配的根底上,还有一层是服务部署在哪里,这是一个云原生的资源编排问题。在声网外部有一套叫做 HCI 的底层云原生平台,它是基于 kubernetes 开发的。咱们把这整套的云原生架构推广到了声网在寰球的所有边缘上。

除 kubernetes 自身有的一些机制外,咱们还做了一些非凡的逻辑。

首先是一个基于云原生的寰球资源管制面。咱们同时有 HCI 外围环境和 HCI 边缘环境,这两个环境同时满足分钟级调度至寰球任意边缘节点的能力。

在简略的 Kubernetes 外面,咱们认为它是一个裸 API,而咱们提供的是通过肯定封装的平台,不是让开发者间接在外面裸跑容器,是通过负载封装之后,有一个不受限的运行环境,同时它能在平台上很好的治理长驻过程、有状态的长生命周期工作、动静函数等。

另外是为边缘设计优化。在边缘上应用简单业务场景具备相当的困难性。比如说有些业务它须要弹性的 IP,IP 须要可能跟着 Pod 进行迁徙;又或者说须要一个四层的边缘负载均衡器,针对这些状况咱们都实现了软件化的边缘弹性,能够在边缘环境中疾速实现各种各样的丰盛的网络栈扩大。

同时像简单业务基本上会有更加麻烦的一些编排策略,比如说可能须要在一组 Pod 之间去共享 Sidecar,多版本灰读等丰盛的编排策略,这些都会在内建的 CRD 当中失去反对。

上面再来看一个简略的 DEMO。

上图是咱们的 DEMO Serverless,展现了如何一键部署到边集群。在咱们外部既有图形化的界面,也有相似图中这样的命令行公布工具,开发者能够用齐全云原生的形式一键部署,就像在操作 Kubernetes 一样。在业务负载层面,既然是 Serverless 那必定是要让业务不去关注资源层面的问题,所以咱们有一个高精度的容量预测和动静伸缩能力反对。大家能够看上面这个图:

这是一个线上业务的预测窗口,窗口内的黄色区域是提前 15 分钟预测进去的一个调度线。

从图中前半段的曲线能够看出,预测值和理论状况放弃了高度的准确性。咱们的动静调度能力能够让开发者在应用云原生边缘平台的时候,更好的实现资源层的灵活性,而不须要去关注到底要在不同的区域中布局多少容量,同时还能够实现容量间的实时调配,为不同的业务实现更好的弹性。

在这些根底上,咱们还解决了传统云原生当中十分难以解决的一个问题 —— 动静负载。如果所有资源都做动态调配,没有方法应答实时互动场景下突发的各类场景。咱们后面举的例子,是一个频道内主播忽然变多了,在这样的场景下,咱们调度其实分成了两层。

上图左侧的草图是一个形象的概念,示意的是在业务的 worker 层面,agent 会实时感知到机器和业务层面的负载状况。并且这是一个全网的对 CPU 内存、GPU 磁盘的应用状况的整体秒级感知,使得咱们能够在秒级工夫内去躲避调度热点,做到齐全实时的调度和迁徙。

这个层面上和传统的容器动态调配不同,咱们能够在动静布局资源池之后,动静的依据负载调配容量。如果呈现了超大规模的频道,比如说客户做流动忽然涌进了很多人,咱们就能够疾速的把机器上的其余业务迁徙走,防止影响到其余业务场景。

这在实质上相当于实现了 Pod 与 Pod 之间的资源共享,一组雷同的业务容器负载能够共享资源,咱们就不必放心资源会调配适度或者调配有余。之前咱们可能会说 request 2C 有点少、request 8C 有点多,那当初就无所谓了。其实所有的 Pod 之间,只有存在资源就都是能够共享的,但如果资源真的没有了,也会被动静的布局到别的中央。

智能路由是绝对高级一些的能力,也绝对比较复杂。

智能路由在业务场景中有时会被提到。

咱们心愿雷同的频道一起被解决,比方抓娃娃机场景中,当大家一起在抓娃娃,咱们心愿用一个 convergeKey 实现工作的汇聚。如果娃娃机须要一个 GPU,那也能够在申请分配资源的时候带一个 GPU 减速。

同样,也能够去指定调配各种不同的版本,实现多版本并行的线上业务,咱们会依据理论的业务场景给客户做动态分配。

还有一块是传输和状态治理,这一层面是声网真正的一个边缘大杀器。

边缘会存在十分多的脆弱性和不确定性,要想真正的解决简单业务场景,不能只是靠调配、部署、托管,不是一个简略的 Serverless 就能搞定的。所以在后盾除了 Serverless 能力之外,咱们还有大量其余的后盾能力,比如说 Worker 状态治理带来的可操作性。目前市面上没有什么 Serverless 场景是能够在工作启动过程中依然去继续治理它的,这个时候咱们的非凡架构便能够带来一些操作上的便当。

最初咱们来简略回顾一下声网 UAP 在实时互动边缘云层面,跟当初市面上的其余云厂商相比做了哪些不一样的事儿。

这个表格不算列的很全,咱们基本上都是依照遇到的业务场景、业务挑战,去做一些针对性的布局。但咱们能够看到大量的第三方,包含云函数、云容器或者边缘函数当初的一些场景反对。

业界当初可能还没有真正意义上的实时互动边缘云,但从表格咱们能够看到,声网可能是在 RTC、RTE 畛域走的比拟靠前的厂商了,并且始终专一给开发者提供开箱即用的是实时互动能力,所以在外部咱们会更关注如何正当的解决这些问题。

之所以做这些,是为了什么呢?大抵有三点:

  • 进一步升高门槛

在外部咱们心愿可能升高 RTE 利用的开发门槛,带给大家更多、更快、更好的 RTE 后盾服务。当然这是相当艰巨的一个挑战,当初还存在肯定的门槛,即便在有了咱们这样的一个平台的根底上,也须要开发者有十分强的研发能力,须要能正确的集成,去解决好高可用的故障切换。所以,咱们还是心愿可能进一步对能力做形象和封装。

  • 欠缺解决方案

同时,咱们也在声网后盾外部一直深入欠缺外部的基建能力,增强应用性和工具链,最终带给大家更多开箱即用的场景。

  • 与生态和合作伙伴联合

进一步来讲,咱们也心愿可能跟生态合作伙伴做联合,通过云市场接入更多第三方的互动场景,放到咱们的边缘云平台上。咱们会针对有开发能力的合作伙伴,一起思考如何进一步凋谢咱们的实时边缘云的能力。

03 当 RTE 遇见 Serverless

后面讲的是声网外部的一些技术能力和计划,置信大家也会很关怀咱们的能力除了做了一个云录制之外,还能给大家提供什么?

上面我想从残缺的业务场景来讲一讲,RTE 和 Serverless 之间的一些关系和技术瞻望。

在一个残缺的业务场景里,除了后面提到的根底的 PaaS 能力,还有很大部分都是基于每一位开发者身上实现的应用逻辑,如何解决这类业务逻辑的交互问题也至关重要。

如果咱们用最简略的办法来看,能够用无服务器的挪动端把所有的应用逻辑都放在端测,这对开发者十分敌对,简略无后盾。但如果利用比较复杂,团队和业务曾经到了肯定规模,这种办法就很难满足更简单的场景。

在晚期咱们能以这种几行代码集成的 RTC 开发很长的工夫,帮忙开发者把整个互动利用翻新做好,但当业务做大做强的时候,就须要一个更加残缺的后盾。

下图蕴含一个大抵的示意图,是当客户须要治理本人的业务信令、业务事件,联合声网的 SDK、NCS 回调,业绩服务端 RESTful API 并用的一个绝对残缺的业务场景。

上图中浅色的局部都是客户要实现的,深色的局部是声网的各种模块。如果咱们上来就给开发者看这样一个图,很可能会感觉头有点大,看起来好简单。但实际上这里的简单构造肯定水平上是不必要的。

大家能够看到,咱们引入了三个端之间的交互。开发者的端侧以及咱们的两套后盾,这样势必会带来极大的通信老本,包含两头的交互链路。

如果说我的项目中声网后盾的任意交互都有须要,那两头任何一端出了问题都十分麻烦,比方后面提到的云录制,可能要收一个云录制的回调,能力晓得在录的过程中呈现了什么样的问题。

然而有可能声网的录制并不能间接满足你的场景,比如说在录的过程中主播和观众须要同时呈现,或者说在特定的时刻才开始录制,显然是须要特地关注在自定义的业务场景下的录制是如何实现的。咱们过来间接提供的 API 不能间接帮客户实现这个问题,因而咱们心愿可能进一步的用 Serverless 去简化架构。

前几年大家有看到声网的 aPaaS,某种程度上就是新架构的体现。咱们心愿可能把咱们跟客户之间的交互、客户跟后盾之间的交互做简化。

这里咱们把它粗略的分成两大类,实时互动场景和非实时互动场景。

非实时互动场景其实就是客户本人的业务端和后盾的交互,但咱们心愿的是把实时互动相干的场景在声网整体做一个闭环。这样的益处是十分大的,因为实时互动相干的性能开发其实都不简略,声网能够帮开发者尽可能的去屏蔽这部分的复杂度,同时实现客户自定义的业务逻辑。比如说互动游戏场景中的仲裁、防舞弊,这些都是没有方法单纯在端测去实现的。

整体来看,咱们心愿可能去赋能开发者,让实时互动触手可及。

咱们并不是在做一个 Serverless,也不是传统意义上的云厂商,而是一个专一于做实时互动的平台,心愿能通过基于 RTE platform 的开放性框架,让外部的实时互动边缘云更好的孵化 RTE 场景。

从 Serverless 的角度来看,咱们更加关注整个生态以及实时互动利用后盾能力的倒退。

边缘利用正在变得越来越简单,同样也越来越欠缺。

从电信运营商的角度看,电话,短信这些大家司空见惯的根底服务都能够认为是边缘化的互动场景。

而声网后盾明天带给大家的 RTC,RTE 互动能力,其实也是一个分布式的边缘云,将来的十年,咱们认为整个实时互动边缘云,还会更多的走进大家的生存,会给开发者带来更多更简单丰盛的业务场景,也心愿咱们真正可能通过这样的 Serverless 能力,让实时互动变得触手可及,无处不在。

我本次的分享根本就到这里,谢谢大家的关注。也心愿明天的这个分享能帮忙到大家,欢送大家继续关注声网将来在 RTE Serverless 应用领域的新进展。

退出移动版