声网王浩宇:RTE 场景下的 Serverless 架构挑战【RTE 2022】

前言

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

这也是声网第一次在 RTE 大会上,对外分享内部的一些后端技术实践。相信大家也一直比较好奇,声网如何在广泛的 RTE 应用场景下解决服务的高效扩展问题。

以下内容基于 @王浩宇 Dylan 于大会中演讲内容整理,为方便阅读略有删改。


声网王浩宇:RTE 场景下的 Serverless 架构挑战【RTE 2022】_第1张图片

01 实时互动后端技术演进

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

声网王浩宇:RTE 场景下的 Serverless 架构挑战【RTE 2022】_第2张图片

一是不断爆发的新互动场景。从 RTC 的视频、推流、录制、鉴黄的基础能力,到 RTE 的灵动课堂、互动游戏、一起 KTV、空间音频、AI 声纹等等。现在的互动场景越来越复杂,相比以前仅仅需要满足音视频的互通,已经到了需要同时兼顾复杂的信令过程、复杂的数据交互。

二是追求更加稳定可靠的极致质量。从原本的低延迟、低卡顿率,上升到 RTE 实时互动体验的质量标准 XLA;需要去支持异常情况下的智能容灾,异常自动恢复。

三是敏捷高效的大规模扩展能力。实时扩容,支持超大规模的业务场景弹性,以低成本覆盖全球各个国家和地区。

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

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

声网王浩宇:RTE 场景下的 Serverless 架构挑战【RTE 2022】_第3张图片

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

基于 CDN 的场景也能够高效的满足弹性、扩展、覆盖的问题。它的优势在于,这样的一个简单静态配置,一般只用关注一个链路切换就可以实现横向的边缘扩容。但这种场景下只能解决分发、传输和接入能力,没有办法去实现复杂的多项交互的业务。

现在的互联网业务几乎都是云化的,公有云场景经过这些年的发展,几乎能支持一切的互联网业务。它具备完备的储存、计算、事务等各种云服务和中间件的能力,易用性和扩展性良好。但有一个问题是链路很复杂,用了云之后意味着重度依赖基建的可靠性,任何一环都不能出问题。

声网王浩宇:RTE 场景下的 Serverless 架构挑战【RTE 2022】_第4张图片

大家也知道声网基本是不用公有云的,也用不了 CDN。我们提出了自己的实时互动边缘云,希望能在我们的边缘云上同时具备边缘的灵活和云的强健,能够在边缘实现复杂的实时互动逻辑,不依赖专线实现可靠传输,解决数据和状态的全球同步。

声网王浩宇:RTE 场景下的 Serverless 架构挑战【RTE 2022】_第5张图片

我们希望做到又快又好,在任意环境都可以运行,覆盖全球的每一个角落。去支持从密集计算的突发任务,到有状态服务在内的任意负载,能够去 Serverless 化,支持动态的资源分配和弹性伸缩。

不同于传统的中心化模式,声网其实并不需要类似 CDN 的回源这类的核心节点,整体架构都做了去中心化。好处是可以彻底摆脱对机房和运营商的依赖,也不需要对基础设施做很高程度的可用性保障。

声网王浩宇:RTE 场景下的 Serverless 架构挑战【RTE 2022】_第6张图片

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

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

02 实时互动 x 边缘 Serverless

上述几点在过去几年我们反复提及过,今天想要给大家讲的是在边缘云的能力上,Serverless 如何进一步驱动业务创新。

这里主要有几个点:

声网王浩宇:RTE 场景下的 Serverless 架构挑战【RTE 2022】_第7张图片

  • 提供了一致化的云能力

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

  • 完备的调度覆盖和全球扩展能力

想要真正做到完备的调度覆盖和全球扩展,不是单独的某一个业务做到,而是需要所有业务都做到。我们的 Serverless 可以在有服务器和网络的地方完成即刻覆盖,不需要考虑机器的规格如何,通过负载均衡机制都能去实现最优的分配策略,满足质量与负载的平衡。

  • 专注于业务迭代

为了给开发者实现最大程度的价值,我们要满足更快的需求交付。声网内部研发在无需关注底层资源的同时,会享受到丰富的流量调度和灰度能力。对外大家能看到的实际体现,就是声网这些年互动应用的不断爆发。

  • 高性价比

同时,我们也需要给开发者提供最高性价比的服务。声网利用极致的灵活与弹性的边缘资源,能够替代公有云沉重的基建成本,不用去购买昂贵的公有云的带宽以及专线。

在这些需求之外,声网是如何真正在边缘实现所有类似的应用落地,这里面又有什么挑战?我想先用一个稍微有点复杂的小表格,来跟大家讲一下。

声网王浩宇:RTE 场景下的 Serverless 架构挑战【RTE 2022】_第8张图片

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

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

相信大家也知道,如果用 HLS 的协议去拉流,它的延迟比 RTC 会差出一个数量级或更多。所以在实时互动应用场景下,一定会选择用有状态的实时流服务去实现业务,追求在性能、成本、可能性层面,都做到极体验致,但代价就是需要去管理这里的复杂度,无论是扩容、迁移、升级、维护,扩展,一切都变得非常的麻烦。

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

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

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

声网王浩宇:RTE 场景下的 Serverless 架构挑战【RTE 2022】_第9张图片

但是 SDK 录制也有几个非常显著的问题:

  • 机房/云厂商网络波动影响录制质量
  • 扩缩容困难,部署维护复杂
  • 跑起来简单,高可用难

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

当然除了录制外,声网还有大量其他的业务场景,因为时间关系我们就拿录制这一个例子来举例,也方便大家来理解。

简单来说,开发者不再需要维护一个有状态的服务,只需要调声网的一个无状态的 RESTful 接口,就可以完成频道的录制。

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

声网王浩宇:RTE 场景下的 Serverless 架构挑战【RTE 2022】_第10张图片

  • 不确定负载,根据主播人数帧率码率不同实时变化

  • 有状态持续性任务,频道可能持续数小时乃至数天

  • 保障任务唯一性的同时允许更新任务

  • 强实时性和可靠性,无法接受丢路与黑屏

  • 需满足全球化场景,即使主播和最终录制存储区域不同。例如:

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

    ° 主播在中东接入 RTC

    ° 录制文件上传到北美

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

声网王浩宇:RTE 场景下的 Serverless 架构挑战【RTE 2022】_第11张图片

声网有一套叫 UAP 的云原生边缘应用平台,可以就字面意义理解为通用应用平台。开发者可以在上面运行任意的应用代码。

中间是 RTE Runtime,可以理解为声网内部的服务端 SDK。上面的任意应用代码可以被跑在任意位置,UAP 平台会帮大家去管理资源编排、容量规划、迁移管理、负载感知、智能调度、动态组网在内的边缘场景下的问题。

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

为了方便大家理解相关概念,给大家看一个简单的例子。

声网王浩宇:RTE 场景下的 Serverless 架构挑战【RTE 2022】_第12张图片

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

上图右侧是声网内部的一些 CRD。在这个 Demo Serverless 的例子中,我们定义了几个 worker,用了一个自定义的 demo 镜像,Request 的一部分资源。在分钟级的时间内,就可以把这样的一个 Demo Serverless 推广到全球的各个边缘上。

同时业务不需要管节点跑在哪、怎么连到它,整个过程都是有动态注册、动态分配的,这一点后面我们会详细来讲。

当然这是最简单的一个集成的场景,还有很多其他的功能模块可以按需扩展。

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

声网王浩宇:RTE 场景下的 Serverless 架构挑战【RTE 2022】_第13张图片

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

我们在做任何边缘业务的时候,第一步要考虑的就是调度,也就是需要满足哪些不同场景。比如说可能有些是对负载比较敏感,有些对时延比较敏感,有些对地理位置比较敏感,这些条件都会由算法规划出来一个最佳的调度策略。

同时业务也可以在上面去自定义想要的业务逻辑。比如可能想要多个不同的版本,想在不同的区域用不同的版本,包括可能精确到不同的业务场景去用不同的版本,又或者可能他有自己的业务属性,在他的业务属性下可以进一步去控制更复杂的策略。

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

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

除 kubernetes 本身有的一些机制外,我们还做了一些特殊的逻辑。

声网王浩宇:RTE 场景下的 Serverless 架构挑战【RTE 2022】_第14张图片

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

在简单的 Kubernetes 里面,我们认为它是一个裸 API,而我们提供的是经过一定封装的平台,不是让开发者直接在里面裸跑容器,是经过负载封装之后,有一个不受限的运行环境,同时它能在平台上很好的管理长驻进程、有状态的长生命周期任务、动态函数等。

另外是为边缘设计优化。在边缘上使用复杂业务场景具有相当的困难性。比如说有些业务它需要弹性的 IP,IP 需要能够跟着 Pod 进行迁移;又或者说需要一个四层的边缘负载均衡器,针对这些情况我们都实现了软件化的边缘弹性,可以在边缘环境中快速实现各种各样的丰富的网络栈扩展。

同时像复杂业务基本上会有更加麻烦的一些编排策略,比如说可能需要在一组 Pod 之间去共享 Sidecar,多版本灰读等丰富的编排策略,这些都会在内建的 CRD 当中得到支持。

下面再来看一个简单的 DEMO。

声网王浩宇:RTE 场景下的 Serverless 架构挑战【RTE 2022】_第15张图片

上图是我们的 DEMO Serverless,展示了如何一键部署到边集群。在我们内部既有图形化的界面,也有类似图中这样的命令行发布工具,开发者可以用完全云原生的方式一键部署,就像在操作 Kubernetes 一样。在业务负载层面,既然是 Serverless 那肯定是要让业务不去关注资源层面的问题,所以我们有一个高精度的容量预测和动态伸缩能力支持。大家可以看下面这个图:

声网王浩宇:RTE 场景下的 Serverless 架构挑战【RTE 2022】_第16张图片

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

从图中前半段的曲线可以看出,预测值和实际情况保持了高度的准确性。我们的动态调度能力可以让开发者在使用云原生边缘平台的时候,更好的实现资源层的灵活性,而不需要去关注到底要在不同的区域中规划多少容量,同时还可以实现容量间的实时调配,为不同的业务实现更好的弹性。

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

声网王浩宇:RTE 场景下的 Serverless 架构挑战【RTE 2022】_第17张图片

上图左侧的草图是一个抽象的概念,表示的是在业务的 worker 层面,agent 会实时感知到机器和业务层面的负载情况。并且这是一个全网的对 CPU 内存、GPU 磁盘的使用情况的整体秒级感知,使得我们可以在秒级时间内去规避调度热点,做到完全实时的调度和迁移。

这个层面上和传统的容器静态分配不同,我们可以在动态规划资源池之后,动态的根据负载分配容量。如果出现了超大规模的频道,比如说客户做活动突然涌进了很多人,我们就可以快速的把机器上的其他业务迁移走,避免影响到其他业务场景。

这在本质上相当于实现了 Pod 与 Pod 之间的资源共享,一组相同的业务容器负载可以共享资源,我们就不用担心资源会分配过度或者分配不足。之前我们可能会说 request 2C 有点少、request 8C 有点多,那现在就无所谓了。其实所有的 Pod 之间,只要存在资源就都是可以共享的,但如果资源真的没有了,也会被动态的规划到别的地方。

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

声网王浩宇:RTE 场景下的 Serverless 架构挑战【RTE 2022】_第18张图片

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

我们希望相同的频道一起被处理,比如抓娃娃机场景中,当大家一起在抓娃娃,我们希望用一个 convergeKey 实现任务的汇聚。如果娃娃机需要一个 GPU,那也可以在申请分配资源的时候带一个 GPU 加速。

同样,也可以去指定分配各种不同的版本,实现多版本并行的线上业务,我们会根据实际的业务场景给客户做动态分配。

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

边缘会存在非常多的脆弱性和不确定性,要想真正的解决复杂业务场景,不能只是靠分配、部署、托管,不是一个简单的 Serverless 就能搞定的。所以在后台除了 Serverless 能力之外,我们还有大量其他的后台能力,比如说 Worker 状态管理带来的可操作性。目前市面上没有什么 Serverless 场景是可以在任务启动过程中仍然去持续管理它的,这个时候我们的特殊架构便可以带来一些操作上的便利。

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

声网王浩宇:RTE 场景下的 Serverless 架构挑战【RTE 2022】_第19张图片

这个表格不算列的很全,我们基本上都是按照遇到的业务场景、业务挑战,去做一些针对性的规划。但我们可以看到大量的第三方,包括云函数、云容器或者边缘函数现在的一些场景支持。

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

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

声网王浩宇:RTE 场景下的 Serverless 架构挑战【RTE 2022】_第20张图片

  • 进一步降低门槛

在内部我们希望能够降低 RTE 应用的开发门槛,带给大家更多、更快、更好的 RTE 后台服务。当然这是相当艰巨的一个挑战,现在还存在一定的门槛,即使在有了我们这样的一个平台的基础上,也需要开发者有非常强的研发能力,需要能正确的集成,去解决好高可用的故障切换。所以,我们还是希望能够进一步对能力做抽象和封装。

  • 完善解决方案

同时,我们也在声网后台内部不断深化完善内部的基建能力,加强应用性和工具链,最终带给大家更多开箱即用的场景。

  • 与生态和合作伙伴结合

进一步来讲,我们也希望能够跟生态合作伙伴做结合,通过云市场接入更多第三方的互动场景,放到我们的边缘云平台上。我们会针对有开发能力的合作伙伴,一起考虑如何进一步开放我们的实时边缘云的能力。

03 当 RTE 遇见 Serverless

前面讲的是声网内部的一些技术能力和方案,相信大家也会很关心我们的能力除了做了一个云录制之外,还能给大家提供什么?

下面我想从完整的业务场景来讲一讲,RTE 和 Serverless 之间的一些关系和技术展望。

声网王浩宇:RTE 场景下的 Serverless 架构挑战【RTE 2022】_第21张图片

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

如果我们用最简单的方法来看,可以用无服务器的移动端把所有的应用逻辑都放在端测,这对开发者非常友好,简单无后台。但如果应用比较复杂,团队和业务已经到了一定规模,这种方法就很难满足更复杂的场景。

声网王浩宇:RTE 场景下的 Serverless 架构挑战【RTE 2022】_第22张图片

在早期我们能以这种几行代码集成的 RTC 开发很长的时间,帮助开发者把整个互动应用创新做好,但当业务做大做强的时候,就需要一个更加完整的后台。

下图包含一个大致的示意图,是当客户需要管理自己的业务信令、业务事件,结合声网的 SDK、NCS 回调,业绩服务端 RESTful API 并用的一个相对完整的业务场景。

声网王浩宇:RTE 场景下的 Serverless 架构挑战【RTE 2022】_第23张图片

上图中浅色的部分都是客户要实现的,深色的部分是声网的各种模块。如果我们上来就给开发者看这样一个图,很可能会觉得头有点大,看起来好复杂。但实际上这里的复杂结构一定程度上是不必要的。

大家可以看到,我们引入了三个端之间的交互。开发者的端侧以及我们的两套后台,这样势必会带来极大的通信成本,包括中间的交互链路。

假如说项目中声网后台的任意交互都有需要,那中间任何一端出了问题都非常麻烦,比如前面提到的云录制,可能要收一个云录制的回调,才能知道在录的过程中出现了什么样的问题。

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

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

声网王浩宇:RTE 场景下的 Serverless 架构挑战【RTE 2022】_第24张图片

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

非实时互动场景其实就是客户自己的业务端和后台的交互,但我们希望的是把实时互动相关的场景在声网整体做一个闭环。这样的好处是非常大的,因为实时互动相关的功能开发其实都不简单,声网可以帮开发者尽可能的去屏蔽这部分的复杂度,同时实现客户自定义的业务逻辑。比如说互动游戏场景中的仲裁、防作弊,这些都是没有办法单纯在端测去实现的。

整体来看,我们希望能够去赋能开发者,让实时互动触手可及。

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

从 Serverless 的角度来看,我们更加关注整个生态以及实时互动应用后台能力的发展。

边缘应用正在变得越来越复杂,同样也越来越完善。

从电信运营商的角度看,电话,短信这些大家习以为常的基础服务都可以认为是边缘化的互动场景。

而声网后台今天带给大家的 RTC,RTE 互动能力,其实也是一个分布式的边缘云,未来的十年,我们认为整个实时互动边缘云,还会更多的走进大家的生活,会给开发者带来更多更复杂丰富的业务场景,也希望我们真正能够通过这样的 Serverless 能力,让实时互动变得触手可及,无处不在。

声网王浩宇:RTE 场景下的 Serverless 架构挑战【RTE 2022】_第25张图片

我本次的分享基本就到这里,谢谢大家的关注。也希望今天的这个分享能帮助到大家,欢迎大家持续关注声网未来在 RTE Serverless 应用领域的新进展。

你可能感兴趣的:(技术干货,实时互动,serverless,架构)