前言
在「RTE2022 实时互联网大会」中，声网云原生边缘计算团队的负责人 @ 王浩宇 Dylan 以《RTE 场景下的 Serverless 架构挑战 —— 声网如何兼顾后端服务的可靠、高效和快速迭代》为题进行了主题演讲。
这也是声网第一次在 RTE 大会上，对外分享内部的一些后端技术实践。相信大家也一直比较好奇，声网如何在广泛的 RTE 应用场景下解决服务的高效扩展问题。
以下内容基于 @ 王浩宇 Dylan 于大会中演讲内容整理，为方便阅读略有删改。
先看一下三个主要的业务需求：
一是不断爆发的新互动场景。从 RTC 的视频、推流、录制、鉴黄的基础能力，到 RTE 的灵动课堂、互动游戏、一起 KTV、空间音频、AI 声纹等等。现在的互动场景越来越复杂，相比以前仅仅需要满足音视频的互通，已经到了需要同时兼顾复杂的信令过程、复杂的数据交互。
二是追求更加稳定可靠的极致质量。从原本的低延迟、低卡顿率，上升到 RTE 实时互动体验的质量标准 XLA；需要去支持异常情况下的智能容灾，异常自动恢复。
三是敏捷高效的大规模扩展能力。实时扩容，支持超大规模的业务场景弹性，以低成本覆盖全球各个国家和地区。
以上这些，都是让实时互动更加易用、更加普及的能力和需求。
在讲声网如何解决这些场景需求之前，我想先跟大家讲一下这些年在各种边缘云和公有云场景下，当前的一些典型架构模式。
在边缘上最传统也最成熟的模式是 CDN 的分发。这种架构经历了几十年的演进，已经非常的成熟稳定。最常见的场景像基于 CDN 的直播、边缘函数、IoT 等等。
基于 CDN 的场景也能够高效的满足弹性、扩展、覆盖的问题。它的优势在于，这样的一个简单静态配置，一般只用关注一个链路切换就可以实现横向的边缘扩容。但这种场景下只能解决分发、传输和接入能力，没有办法去实现复杂的多项交互的业务。
现在的互联网业务几乎都是云化的，公有云场景经过这些年的发展，几乎能支持一切的互联网业务。它具备完备的储存、计算、事务等各种云服务和中间件的能力，易用性和扩展性良好。但有一个问题是链路很复杂，用了云之后意味着重度依赖基建的可靠性，任何一环都不能出问题。
大家也知道声网基本是不用公有云的，也用不了 CDN。我们提出了自己的实时互动边缘云，希望能在我们的边缘云上同时具备边缘的灵活和云的强健，能够在边缘实现复杂的实时互动逻辑，不依赖专线实现可靠传输，解决数据和状态的全球同步。
我们希望做到又快又好，在任意环境都可以运行，覆盖全球的每一个角落。去支持从密集计算的突发任务，到有状态服务在内的任意负载，能够去 Serverless 化，支持动态的资源分配和弹性伸缩。
不同于传统的中心化模式，声网其实并不需要类似 CDN 的回源这类的核心节点，整体架构都做了去中心化。好处是可以彻底摆脱对机房和运营商的依赖，也不需要对基础设施做很高程度的可用性保障。
另外一方面，云的易用性带来了复杂度的急剧增长，故障概率和影响范围也进一步加剧。这些年不管是国际上的一些巨头还是国内的一些厂商，基本都出现过大范围的故障。并且如果是骨干网或者运营商故障，很多情况下是没有办法挽回的，云网络底层的 BGP 协议一旦在路由层面出问题，可能影响整个大洲。例如北美最近一两年已经遇到过多次公有云几乎整体断网的情况。
声网希望能够在实时互动边缘云上做到真正的反脆弱性，所以会对任何的基础设施去做一定的故障预设。我们的服务至少满足 N-3 的冗余度，意味着不会依赖任何单一的基建或者运营商，在任意区域均可承受 3 个机房故障不影响可用性。
上述几点在过去几年我们反复提及过，今天想要给大家讲的是在边缘云的能力上，Serverless 如何进一步驱动业务创新。
这里主要有几个点：
在讲挑战之前，我们先提一个传统意义上原生应用架构跟实时互动应用的区别。
云原生应用很多时候大家都在讲无状态性，但所有的实时互动应用几乎都跟流有关。streaming 意味着信息的高效传递，所有的数据都在毫秒级的时间传达到对方。我们没有办法再去做一个无状态协议，把流做切片。
相信大家也知道，如果用 HLS 的协议去拉流，它的延迟比 RTC 会差出一个数量级或更多。所以在实时互动应用场景下，一定会选择用有状态的实时流服务去实现业务，追求在性能、成本、可能性层面，都做到极体验致，但代价就是需要去管理这里的复杂度，无论是扩容、迁移、升级、维护，扩展，一切都变得非常的麻烦。
过去云厂商包括一些互联网大厂，也都在做面向无状态服务的 Serverless 架构，让大家都能有各种各样的函数服务去解决这种短暂无状态应用，包括对冷启动时间不敏感的场景，这是迄今为止 Serverless 的技术白皮书当中推荐的场景应用模式。但这样的 Serverless 方案，从运行环境、API 到运行时间层面，都是层层受限的。
我们在实现一些像音视频之类比较重的业务时，不管是启动时间还是业务的运行时长，或者是需要用到的各种各样的 API，都会对基建能力和 Serverless 能力提出全新的高要求。
以录制场景为例，最早声网在没有提供内部的云能力之前，也是让客户用 SDK 录制，也就是一个 Linux SDK。这种在服务端跑 SDK 的好处就是不受限，想实现各种各样的业务场景都可以，非常灵活。
但是 SDK 录制也有几个非常显著的问题：
声网有一套叫 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 和 Serverless 之间的一些关系和技术展望。
在一个完整的业务场景里，除了前面提到的基础的 PaaS 能力，还有很大部分都是基于每一位开发者身上实现的应用逻辑，如何解决这类业务逻辑的交互问题也至关重要。
如果我们用最简单的方法来看，可以用无服务器的移动端把所有的应用逻辑都放在端测，这对开发者非常友好，简单无后台。但如果应用比较复杂，团队和业务已经到了一定规模，这种方法就很难满足更复杂的场景。
在早期我们能以这种几行代码集成的 RTC 开发很长的时间，帮助开发者把整个互动应用创新做好，但当业务做大做强的时候，就需要一个更加完整的后台。
下图包含一个大致的示意图，是当客户需要管理自己的业务信令、业务事件，结合声网的 SDK、NCS 回调，业绩服务端 RESTful API 并用的一个相对完整的业务场景。
上图中浅色的部分都是客户要实现的，深色的部分是声网的各种模块。如果我们上来就给开发者看这样一个图，很可能会觉得头有点大，看起来好复杂。但实际上这里的复杂结构一定程度上是不必要的。
大家可以看到，我们引入了三个端之间的交互。开发者的端侧以及我们的两套后台，这样势必会带来极大的通信成本，包括中间的交互链路。
假如说项目中声网后台的任意交互都有需要，那中间任何一端出了问题都非常麻烦，比如前面提到的云录制，可能要收一个云录制的回调，才能知道在录的过程中出现了什么样的问题。
但是有可能声网的录制并不能直接满足你的场景，比如说在录的过程中主播和观众需要同时出现，或者说在特定的时刻才开始录制，显然是需要特别关注在自定义的业务场景下的录制是如何实现的。我们过去直接提供的 API 不能直接帮客户实现这个问题，因此我们希望能够进一步的用 Serverless 去简化架构。
前几年大家有看到声网的 aPaaS，某种程度上就是新架构的体现。我们希望能够把我们跟客户之间的交互、客户跟后台之间的交互做简化。
这里我们把它粗略的分成两大类，实时互动场景和非实时互动场景。
非实时互动场景其实就是客户自己的业务端和后台的交互，但我们希望的是把实时互动相关的场景在声网整体做一个闭环。这样的好处是非常大的，因为实时互动相关的功能开发其实都不简单，声网可以帮开发者尽可能的去屏蔽这部分的复杂度，同时实现客户自定义的业务逻辑。比如说互动游戏场景中的仲裁、防作弊，这些都是没有办法单纯在端测去实现的。
整体来看，我们希望能够去赋能开发者，让实时互动触手可及。
我们并不是在做一个 Serverless，也不是传统意义上的云厂商，而是一个专注于做实时互动的平台，希望能通过基于 RTE platform 的开放性框架，让内部的实时互动边缘云更好的孵化 RTE 场景。
从 Serverless 的角度来看，我们更加关注整个生态以及实时互动应用后台能力的发展。
边缘应用正在变得越来越复杂，同样也越来越完善。
从电信运营商的角度看，电话，短信这些大家习以为常的基础服务都可以认为是边缘化的互动场景。
而声网后台今天带给大家的 RTC，RTE 互动能力，其实也是一个分布式的边缘云，未来的十年，我们认为整个实时互动边缘云，还会更多的走进大家的生活，会给开发者带来更多更复杂丰富的业务场景，也希望我们真正能够通过这样的 Serverless 能力，让实时互动变得触手可及，无处不在。
我本次的分享基本就到这里，谢谢大家的关注。也希望今天的这个分享能帮助到大家，欢迎大家持续关注声网未来在 RTE Serverless 应用领域的新进展。
（正文完）
