共计 6624 个字符，预计需要花费 17 分钟才能阅读完成。
前言
在「RTE2022 实时互联网大会」中，熹乐科技创始人 & CEO @范维肖 CC 以《基于开源 YoMo 框架构建“寰球同服”的 Realtime Metaverse Application》为题进行了主题演讲。
本文内容基于演讲内容进行整顿，为不便浏览略有删改。
大家好，我是熹乐科技的 C.C. 范维肖，咱们公司的产品是开源的实时边缘框架 YoMo。在过来的两年中，很多 Metaverse 行业的开发者应用了咱们的产品。这次就和大家分享一下过来的两年中，咱们在 Metaverse 畛域的一些教训和领会。
在过来的二十年，开发者曾经十分习惯 RESTful 开发方式，API 十分的简略，咱们用相似于 JSON、PutBuffer 等形式作为数据结构来做传输，通过一个 GET 一个 POST 就可能解决绝大多数的业务逻辑问题。这也造成了明天支流的「API 经济」模型，它次要的逻辑就是用户跟服务器在产生交互。
然而在 Metaverse 畛域当中，RESTful 形式受到了很大的挑战。比方下图中的场景：
无论是在一辆主动驾驶汽车上，还是戴着 VR、AR 跟咱们的事实世界造成与虚拟世界的实时投影，过程中都有大量的数据须要进行计算，而这些数据往往不是结构化的数据。
01 传统产品和 metaverse 的三个要害差别因素
在这一类 metaverse 场景中，和传统的产品相比有三个重要的不同因素。第一个要害差别，是越来越多的数据从 JSON 变成了流式的数据 Streaming Data。
这当中一个显著特点，是各种传感器在采集数据、传输数据。对于用户而言，上行数据的量比上行数据的量要大，也就意味着越来越多的数据须要通过网络来进行共享，须要去寻找它的计算单元实现计算。这个状况和此前“上行数据远远高于上行数据”、计算离用户很远的状况是齐全不一样的。
第二个差别在于低时延成为了一个十分十分重要的因素。
像在方才咱们讲的场景当中，能够大抵分为三局部：
- Video Stream
- Audio Stream
- Behavior Sequences
其中 Video Stream 次要利用在主动驾驶汽车、人脸识别当中；Audio Stream 是通过一条流来传输音频，可用于各类实时翻译、语音管制等场景；Behavior Sequences 是动作序列，间断的动作序列数据能够用于做规定判断、模式识别、举荐引擎，以及欺诈检测等等。这些都须要实时的实现计算。
第三个不同的点是整个 Metaverse 是一个全球化的模型，每一个人都在跟寰球所有的人组成一个本人主导的虚拟世界，那么每一个“我”与另一个人之间的 Metaverse 是互相交融在一起的，每个人都是本人世界的核心，这是 Metaverse 相干产品架构的底层逻辑。
那么这也造成了一个与之前传统来讲最大的不同：以前是人与计算单元产生交互，但明天人与人之间在产生着激烈的交互。这是咱们过来两年服务 Metaverse 行业开发者的过程中，一个最显著的感触。
02 如何解决这些难题？
开源框架 YoMo 有一个最简略的定位是 Streaming Serverless，让开发者应用 Serverless 的模式作为编程范式，构建整个的微服务的逻辑，解决流式的实时开发。
这个概念其实不新，在最早计算机呈现的时候，过程间的通信靠的就是 Unix Pipeline。
如上图所示的过程中，把输入放到左侧 ls 命令的规范输入中，通过 Unix Pipeline 以字节流的形式，进行单向的向后传递，传递给右侧的 wc 程序。通过这样的形式，解耦了左侧的 ls 和右侧的 wc。
那么 Unix Pipeline 就能够依照这样的流程间断起来，用文件形容服务去做整个的解耦和连贯，这也是经典的 Unix 哲学中一个很重要的局部。
而像咱们常常在命令行中通过用 cat 命令去打印内容，用 sort 去排序，用 uniq 去排除反复的数据，用 grep 去做过滤，这些利用是用一个竖线来示意整体的 Pipeline 的这个过程。
YoMo 就是基于这个思维，然而放大到了整个互联网的级别来做。
当初咱们来看下图，如果咱们的应用程序从左侧的 sort 到 uniq，而后 sort 到最初的 head，这几个命令咱们须要去均衡它的计算成本和计算时延的需要。
那么咱们就能够把它别离部署在不同的地位，比如说最左侧，咱们能够把它部署在 5G MEC 上，这样的 sort 就可能达到很快的后果。而后咱们能够顺次来调整剩下的级别，放到城市级、国家级甚至整个大洲，就咱们明天惯例的云计算的节点下面。
这样咱们就能取得更低的计算成本来构建利用，这使得不同的服务能够依照它的响应级别和老本管制的要求，去做均衡和取舍。这在传统的分布式计算当中，要花很大的精力去构建如此的基础设施。
这也引出来 YoMo 的三个外围概念 —— 数据源、处理函数和 Zipper。
Zipper 就像 linux 的 Pipeline 性能一样把两侧连接起来，去把数据调配到不同的计算资源。数据源是用于把数据结构转换成能在 YoMo 外面去流动的信息，这样才可能实现低时延、高效的寰球传输。
计算的算子能够把它了解为数据流动的形式，从左向右在做流动，那么两头靠一个 Zipper，像衣服的拉链一样，把所有的算子和数据重合，每次重合就是一次计算。这样最终能造成的架构是地理位置分布式的架构形式。
目前传统在用的分布式都是在一个繁多数据中心里的分布式，但须要满足寰球用户应用的时候，须要变为架构在明天的 IaaS 之上的寰球分布式技术。
写这样的利用大家必定会感到十分的苦楚，咱们在来到 7 毫秒时延的束缚，寰球范畴都一两百毫秒的时候，如何能保障咱们的分布式的 CAP 实践一致性等等，都是绝对辣手的难题。
所以 YoMo 的框架旨在于解决面向于寰球分布式场景下，如何更简略的构建本人的应用程序。那咱们应用程序一旦构建完就能够部署在离用户更近的中央，来为他左近的用户提供低时延，并且老本更低廉的服务，这样寰球利用的均匀时延能够从明天的 260 毫秒优化到寰球小于 50 毫秒。
地理位置分布式是逃不开的话题，因为网络的时延和光速是成正比的。明天咱们的网络在极限场景下，数据的传输速率跟间隔成正比。
上面的几张图展现了当数据中心放到北京，在 10 毫秒、20 毫秒、50 毫秒的时延状况下，实践上能笼罩的面积。
如图所示，50 毫秒的时延实践上能够实现笼罩亚洲和东欧的局部；100 毫秒的时延，如果将数据中心部署在美国的东部，实践上是能够笼罩半个地球的，但理论环境中其实基本做不到这一点。
因为理论场景下，用户从本人的端上到接入服务的链路十分长，而且业务提供方对此又不可控。这种状况下的问题就要蹩脚很多，在很多基础设施环节都须要做大量的优化。
很多私有云在不同的大洲都有多个数据中心，但跨区域的时候，这些数据中心之间的交互其实也是不够现实的。这个时候要思考的，是如何解决同一个云上多数据中心、不同云不同数据中心之间如何能高速的交互，并且能使得咱们的利用可能自我治理。
自我治理能够使得它一直的滋生。当一个区域的用户越来越多的时候，我能够滋生一个新的节点进去，这个节点是自适应、自组织的，并且能向上与之前的计算农场联合在一起。
这种自我治理的思路不是翻新，也是来自于互联网架构中十分传统的根底模型。Internet 其实就是 a network of networks，它就是由一个一个的网络组成，两头由 BGP 连起来，这也是 YoMo 架构的理念。
03 开发者敌对性
YoMo 要花大量的精力去解决的第三个事件，是开发者敌对性的问题。为什么呢？想想咱们明天的端，咱们有很多做端游的用户，他们用 YoMo 来解决的第一个问题是 WIFI 网络的问题。
这背地的起因在于，目前咱们大多数场景还在用 WIFI-5，其数据传递链路是波，而波是非常容易受到烦扰的，比如说建筑物的遮挡和多设施之间的烦扰，从而导致丢包。
在有丢包、时延产生的时候，TCP 吞吐量就会疾速的降落，因而咱们不得不去调整拥塞控制算法。但拥塞控制算法须要依照具体的利用来设置，做视频和做游戏是齐全不一样的。加上链路中网络设备僵化因素的存在，也使得使得咱们对 TCP 的优化不肯定能成立。比如说中间设备很老不反对新的算法，那么 TCP 就会降级，降级到最原始、最落后的状态。所以中间设备的僵化其实是现阶段全链路调优 TCP 过程中很难的一点。
然而去年，IETF 公布了 RFC9000，就是 QUIC 协定。QUIC 基于 UDP，具备更好的安全性，往年公布的 HTTP/3 底层的传输层就是 QUIC 协定。
QUIC 有各种长处，比如说它的多流十分的好，非常适合去开发简单业务逻辑的利用，然而很难用。
如果大家去翻 QUIC 的 IETF 的文档会发现它是一个协定族，有一大堆的文档要读，都读透了能力充沛的驾驭它，进而革新下层利用的代码去施展 QUIC 的劣势。你会发现一会儿我要翻 QUIC 的货色，一会儿我要翻 QUIC 扩大的货色，十分麻烦。那么如何能让咱们将 QUIC 利用到咱们的利用里边变得非常容易？是否跟以前开发应用程序一样还那么简略？那么如何升高用户的学习老本，这其实是 YoMo 在做的一个十分重要局部的工作。
上面这张图程序员们也十分相熟了，是驰名的 Emacs 的蜗牛曲线。
咱们升高学习老本的一个形式，就是借助于 Serverless。Serverless 的开发范式大家都曾经十分的相熟了，但 Serverless 到明天仍有一个致命的毛病，就是绝大多数的 Serverless 是无状态的执行，依照执行时长计费，这使得 Serverless 波及到一系列的问题，比如说没有状态的时候还是要把长期状态打到 DB 上。但在寰球分布式系统里，咱们的 DB 又十分难去做寰球读写，中心化的 DB 使得时延无奈失去保障。
所以咱们把 Serverless 降级了一下，把它先变成了 stateful。
如上图中的函数所示。当拿到一个数据的时候，咱们反对把它形象成一个 Rx 的流，从而能够借助很多 Rx 的办法去解决问题。比如说像这个例子当中，我要从相似于 VR 眼镜这样的传感器中传数据，那么我能够让它每收到 50 个数据包做成一个 buffer，收到 50 个数据包后我再让 echo 去计算。这在以前咱们须要破费精力去做这种框架反对利用的疾速开发，明天借助 YoMo 会简略很多。
同时，它要放弃着以前 Serverless 的简略易用个性。
目前，YoMo 的 Streaming Serverless 也反对了 Rust 语言，当初有越来越多的开发者在应用 Rust 语言去写本人的后端，Rust 的生态也变得越来越好，这种语言有很多出彩的中央。
但 Rust 也绝对难以治理。尤其咱们还要思考一个问题，就是目前的算子都是在云上进行，不论是在边缘的云上还是在传统的私有云上。那有没有可能把算子拉到端上来执行？
比如说要思考更好的数据安全，那么如何来调配它？基于这一点，咱们抉择了应用 WebAssembly 来做反对。
咱们齐全能够把 Serverless 函数变成 WebAssembly，那么它就能够在 YoMo 外面去被执行。
像上图所示的 demo 中，能够把 rust 代码编译成 wasm32-wasi 这样的 target，而后用 YoMo run 而后把它运行起来。
咱们也在跟 CNCF 的我的项目在单干，比方下面这个例子里，就是 YoMo 与开源的 WasmEdge 买通，基于规范的接口，都是社区型的开源我的项目，使得开发者不必放心被繁多供给起源绑定的问题。
04 为前端开发者的特地筹备
这两年前端产生了很大的变动，然而开发工具并没有倒退得很快。举个例子，过来的十几年外面吧，咱们要想写一些 Web 的实时利用，咱们可选的工具并不多。WebSocket 可能是绝大多数人都在用的一个工具。然而 WebSocket 太老了，而且呢，WebSocket 有诸多的劣势，尤其是针对于明天简单的应用程序而言。
在往年的年初，谷歌公布了 WebTransport，当初 Chrome、Microsoft Edge 都曾经做了反对，而后 Firefox 也正在去反对它，明天寰球 70+% 的 Web 申请都曾经反对它了，可是它的落地占比却还有余 0.1%。
咱们能看到对于 WebTransport 的介绍，它其实就是一个应用 HTTP/3 协定的一个双向的传输通道，它被设计就是为了要解决双向通信的问题。
其中提到的 Datagrams 就十分有意思，很多基于 Web 去做游戏的人没法用 UDP，开发者就要花很大的精力去解决这个畛域的问题，所以起初很多利用都不得不抉择去降级解决，大多都会抉择通过就义产品体验的形式，就是因为技术上没法满足。
那明天有了像 Datagrams 的宝贝，咱们就能像 UDP 一样的去高速的去传数据，这是给 Web 开发者引入了新的货色。
同样，Streams API 也十分的弱小。明天咱们能够用来去操作字节流，不须要去关注各种的对象的问题，我的音频、视频，我的各种流式的编解码器都可能放到前端去做。
上面咱们来看看 Streams API 的应用形式。
上图所示是如何发数据到 WebTransport。能看到须要先创立一个 SendStream，而后拿到这个 Stream 要去 getWriter。第二行、第三行、第四行是要筹备好我的数据要依照 Uint8Array 的模式筹备好，而后要把它 write 过来，还要去看管制 error 的问题。
如果要接管读取更麻烦了。
要读的时候要先去创立一个 receiveStream，拿到他的 reader 后，要始终去 read 数据。但这个时候就有一个问题了，如果我的 server 和我的客户端去交互的时候，我怎么晓得我的每一个数据包的边界是什么？像我间断的传两个 json 过来，我怎么晓得如何辨别这两个 json 什么时候开始做反序列化？这些都使得前端的开发者不得不要本人去设计一些数据结构。
那么这种十分底层，low level 的 API，这就像咱们间接在用 TCP、用 UDP、用 QUIC 是一个情理，咱们须要做大量的根底工作来去撑持咱们的上层建筑的开发。
但 Strams API 有一个十分好的性能是他反对双向流，那么反对双向流的时候呢，咱们的开发逻辑就会变得更简单了。咱们一边要管制 ReadableStream，一边还要管制 WritableStream，往往我收到的数据要做一些工作，而我还要实现一些异步的操作，这会使得咱们的编程模型变得更加的简单，尤其是业务逻辑简单的时候，这个就十分难管制了。
那么 WebTransport 尽管看起来应用形式很简略，然而要做大型项目的时候，还是有艰难的。咱们能够在官网举荐的 WebTransport.day 下面去体验一下 WebTransport 的速度如何。
在 WebTransport 之外，咱们也是能够应用 YoMo 去写一个 Serverless 的形式看到整个 Server 端的逻辑开发。做过前端实时通信的同学肯定都十分困恼当年咱们去写 WebSocket 的业务逻辑，比如说基于 SocketIO，要解决很多很多的问题，而后还可能要在 WebSocket 上做 RTC 类的数据等等。
体验过后，能显著感触到 WebTransport 的应用比 WebSocket 是难了很多的，那么如何能让 WebTransport 在 server 端的开发变得异样的容易，并且能够不去关怀整个的网络层、流这些简单的 API，只是简略的就像后面的寰球响应的模型一样，去写咱们的代码。？同时我写完的代码能不能别离部署在不同的区域里边，能使得就近去服务不同区域的用户？
这些是能够借助于 YoMo 来实现的。
进入 https://webtransport.day/serverless 页面，咱们能够去创立一个 serverless，用 rust 来写，而后编译成一个 WebAssembly 文件，用 YoMo 在本地运行起来。
这样寰球的用户都能够把数据发到 YoMo 的开发者服务的节点上，这是一个收费的为开发者提供测试服务，这个服务会把数据推到你本机的 webAssembly 过程中去，执行并拿到数据的后果。
以上就是我明天跟大家的一些分享，这也是在过来的两年里边咱们服务了一些 Metaverse 产品的开发者后的教训。这些开发者有的是做 VR 的、有的做 AR 的，有的基于 Web 在做游戏和办公合作（Collaborative SaaS），也有的是基于手机设施和挪动设施来做 Metaverse 的游戏利用等等。
针对于这些不同产品的构建形式以及复杂程度，咱们在整个的开发者程序里边打磨进去的开发模式 Stream Serverless，能够基于 Streaming Stateful Serverless 的开发方式。
欢送大家跟咱们一起来打造将来实时寰球互联网的新浪潮！
