共计 7930 个字符，预计需要花费 20 分钟才能阅读完成。
前言
在「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 应用领域的新进展。
