熹乐科技范维肖：基于WebAssembly的JAMStack实时数字应用开发实践

当前位置：资讯 > 新加坡云服务器 >熹乐科技范维肖：基于WebAssembly的JAMStack实时数字应用开发实践

相关服务：新加坡云服务器租用

嘉宾 | 范维肖整理 | 张润泽

出品 | CSDN云原生

2022年4月28日，在CSDN云原生系列在线峰会第3期“WebAssembly峰会”上，熹乐科技CEO范维肖分享了基于WebAssembly开发面向全球用户的低时延实时应用过程中的一些思考和认知。

戳👇观看范维肖分享视频

如何做到实时交互？WebSocket来帮你！

Web领域的大变化

当前，我们正在将越来越多的日常活动迁移至线上，工作、生活、娱乐等各方面的需求都在逐步被互联网应用承载，互联网俨然已经成为每个人不可或缺的生产力工具。为了不断提升生产效率和消费效率，应用的“实时性”被提升到了前所未有的重要程度。

我们常用的产品如社交媒体、聊天工具、在线协作、电商、IoT等均在快速增加实时交互的能力（Real-time functionality）。Figma增加了多人同时在线协作的功能如 CursorChat, Vercel作为JAMstack体系下商业化最成功的的产品，也在Vercel.com平台增加了Next.js Live功能，用来支持前端开发者、产品经理、测试人员通过多人实时协作快速构建产品的功能。电商应用通过增加多人协作的功能，使得顾客与客服可以实时无缝共同浏览商品，从而提升销售转化率。此外，以元宇宙为代表的新型实时应用也正在高速增长，“元宇宙”正在被当作一种交互形式重塑各类产品，如元宇宙社交、元宇宙在线协作平台等。

然而当前互联网的大部分请求并不是面向“实时交互”设计实现的，为了达到“零延迟”的交互效果，越来越多的应用正在基于WebSocket协议实现，WebSocket使得客户端和服务端可以始终保持连接，实时完成双向数据传输。基于WebSocket的应用，在用户和服务端之间可以实时长时间互联，但同时也给应用架构带来了很多挑战。

WebSocket应用可以支持的活跃用户的数量与服务器资源数量直接相关，一旦应用达到一定规模的同时在线用户，服务端就需要不断扩容以保持所有用户的数据同步。但 WebSocket的扩容一直是个难题，因为WebSocket连接通常是持久化的，扩容时既要有完整的不同节点之间的状态同步的解决方案，也要充分考虑服务资源成本相关的问题。如果当前应用的用户来自于全球各地，还需要考虑远距离数据传递，跨国、跨洲网络通信等问题，即便是AWS、Google等云服务厂商，其不同机房之间的云资源，网络互通问题也非常多。

为了解决实时应用在实现过程中面临的各种问题，过去两年时间，熹乐科技打造了开源编程框架YoMo（https://github.com/yomorun/yomo），来帮助开发者构建最适合实时应用的数据同步方式和应用架构。

针对实时应用，我们总结了四个核心问题。

就近计算：利用最靠近数据生产者和消费者的云资源进行计算，以解决统一数据中心引发的网络连通性的问题，但这就需要应用能支持地理位置分布式（Geo-distributed System）的部署方式，在全球范围内部署节点，用户可以访问最靠近自己的Server，以保证用户数据可以最快接入、最快计算和传递，同时也降低了单一节点的并发。这样的架构与Single Cloud-Region形成了鲜明对比，全球的用户不再需要去连接到统一的中心节点。
长连接：充分利用长连接（如WebSocket、WebTransport）来弥补HTTP在多次握手等方面引发的问题。
Stream流式编程：实时应用中，客户端产生的数据本质上是流式的数据，以流式的方式进行业务处理可以极大地提升事件变成的抽象程度，降低应用的复杂度。
低开销（low-overhead）: 实时应用的部署结构需要计算节点的下沉，必须充分利用边缘数据中心的资源，这就使得应用必须以极低的开销运行才能保障整体成本可控，这也使得单一数据中心结构下常用的云原生工具都不再适用。

将计算推到离用户更近的地方

为用户提供就近接入的网络和就近计算的能力是降低时延，加速数据传递的本质。YoMo可以帮助WebSocket应用快速构建地理位置分布式（Geo-distributed system）的部署结构。

如上图所示，如果我们有两个用户，分别是德国的Bob和新加坡的Alice，Bob的数据直连法兰克福的节点，Alice的数据直连新加坡的节点，这样Bob和Alice与服务端的时延均可优化到小于20ms，Bob和Alice产生的数据就可以最快的速度传递到整体的同步网络中。

与最后一公里连接到用户的网络链路不同，两个数据中心直接的网络链路相对稳定，也有成熟的优化手段，我们有非常多软件的方式来优化不同节点之间的时延，解决了最后一公里的难题，将之前的“不可控”连接转换为“最高效”的连接，从而达到整体的时延最低。

流式编程

Stream Processing这个词通常会在大数据领域被提及，而我们讲的实时应用领域的流式编程范式，本质上是将实时数据处理抽象成为一个个管道（Pipeline），有输入输出，业务逻辑可以基于一个个管道去进行拆分和组合。

需要特别注意的是，面向实时应用的开发过程，时延和用户体验是最优先需要关注的问题，所以在处理过程中，需要保证数据可以最快速地被接收和被消费，而不应该过多关注Backpressure这类的问题。

在YoMo实现流式编程框架的过程中，我们充分借鉴了Unix Pipeline的思想，我们支持将每个Pipeline以WebAssembly的形式存在。这给我们带来了非常大的优势，使得我们可以任意位置部署，输入和输出可以分散在不同的客户端中。

过去两年，YoMo与WasmEdge在进行充分的合作，WasmEdge帮助我们将Stream Function部署在任意位置，使得可以支持更复杂、更灵活的业务逻辑。

还是以Bob和Alice案例为例，基于YoMo和WasmEdge，整个应用的架构会如下图所示。

上图架构所示的整个数据流转过程由各种管道（Pipeline）组成，为了降低管道的处理时延，YoMo采用Wire Protocol，因此对承载的数据需要做一次编解码。编码阶段，Encoding算子被编译为Wasm直接在浏览器里运行完成，Bob的数据编码后，传递给法兰克福的节点，进行一次业务计算，再传递至新加坡的Alice这一侧，再次被进行处理，最终在Alice的浏览器被Decode后，交付给前端框架，完成业务逻辑。这样的过程使得Web开发者的工作极为简单，同时还支持binary的操作。

下图展示了YoMo某位用户开发的全景视频的应用，这个应用既在浏览器中运行，同时也需要能在几种主流的VR和AR设备中运行。随着客户端视角（orbit）的变化，视频会被实时渲染，而客户端由于无法提供足够的计算资源，使得这个全景视频的交互很不流畅，同时交互方式也非常受限。为了保证该应用在资源受限的情况下，能够增加更丰富的交互模式，开发团队利用YoMo将一些计算卸载到边缘计算资源中，利用 Verizon的5G和边缘服务器，完成计算密集型任务，弥补了端内计算资源不足的问题。

由于基于YoMo的分布式应用（Geo-distributed）需要部署到全球各地，成本问题和快速部署就成为了应用能够顺畅运行的两个核心问题。为了解决这两个问题，我们借助WebAssembly，使得开发者的Stream Function在实现沙箱隔离的同时，还能以极低的开销运行，同时极大地缩短了冷启动时间。这些关键角度的优化，让我们可以很好地控制规模成本，使得我们将云计算从单一超大数据中心推向城市区域级的中小数据中心成为可能，突破了分布式云和边缘计算在计算经济性方面的瓶颈。