WebAssembly 使用場景和未來發展趨勢

  1. 前言

從之前的章節學習中，我們已經瞭解了 WebAssembly（WASM） 的基本概念，以及它的基本使用方法。但是，在什麼樣的場景中我們會使用 WASM 呢？在這些不同的場景下，我們是如何使用 WASM 的呢？更進一步，我們能看到的 WASM 的未來發展趨勢是什麼樣的呢？在這一章中，爲了使讀者能夠更好更全面的瞭解 WASM ，我們將會討論一下 WASM 的使用場景和未來發展趨勢。

  1. 場景

WASM 的名稱的體現了它在最初的設計中人們對它的希望：能夠在 Web 環境中快速地運行。目前，WASM 已經能夠在包括瀏覽器在內的很多不同的環境中運行。這些場景包括：雲原生場景、移動設備、物聯網、區塊鏈等多種不同的場景。在這些場景中，大家使用 WASM 的主要目標包括，但是不限於如下幾個方面：

下面兩張圖分別展示了 1. WASM 在不同場景中的使用情況；2. 主要場景從 2021 年到 2022 年的變化。它們均出自《The State of WebAssembly 2022》[1]。首先第一張圖顯示了目前大家使用 WASM 的主要領域。從圖中我們可以發現，目前大部分的用戶都在瀏覽器端和雲原生場景，而 Web 場景的開發更是佔到整體的 50% 以上。

圖 1. 不同領域 WebAssembly 佔比

下一個圖中則顯示了與去年（2021）年相比，WASM 在不同領域中的佔比變化。從圖中可見，WASM 在雲原生場景中的使用佔比從 2021 年到 2022 年有了比較大的增長。雖然 Web 場景的使用有略微減少，但是目前它仍然是主要的 WASM 的使用領域。

圖 2. 2021-2022 不同領域的佔比變化

在不同的領域中， WASM 有着不同程度的應用。目前，有大量的公司和組織在使用 WASM 或者參與 WASM 生態的建設。這些公司或者組織的列表如下圖所示 [2]：

圖 3. WebAssembly 生態中的主要公司和組織

對於具體的場景，我們會在本章節中接下來對它們進行進一步的深入介紹。

2.1 Web 環境

WASM 從最早設計的時候目標是讓代碼在瀏覽器端更快地執行。在瀏覽器環境中，WASM 將非 JavaScript 的語言（例如：C/C++，Rust，Golang 等）的代碼編譯爲低級字節碼 WASM 模塊，瀏覽器可以直接執行這些模塊，而無需解析源文件。

雖然 WASM 是一個相對來說比較新的技術，但是目前在主流瀏覽器中都已經支持。下圖顯示了不同瀏覽器中的 Web 程序集對 WASM 的支持 [3]。這裏不同的行描述了不同 WASM 的對象在不同瀏覽器中的支持。例如：Memory 對象代表了 WebAssembly.Memory 對象，該對象是一個可變大小的 ArrayBuffer 或者 SharedArrayBuffer。它內部的原始數據可以被 WebAssembly.Instance 對象訪問。

圖 4. 不同瀏覽器中的 WebAssembly 支持

2.1.1 視頻解碼和 GUI 控件

WASM 可以用於視頻解碼和 GUI 控件。例如：1. 在 WASM 中實現的視頻解碼器可以用於在瀏覽器中播放視頻；2. 在 WASM 中實現的 GUI 控件可以用於在瀏覽器中渲染圖形界面。

目前 HTML5 支持的視頻格式主要是三種：MP4, WebM 和 Ogg。進一步需要注意的是，不同瀏覽器的支持不盡相同。例如：在 Safari 瀏覽器上，Ogg 格式是不支持的。WebM 只在 58% 的瀏覽器上支持。在 Firefox 24 之上，MP4 的支持默認情況是被禁用的。

正因爲這些，視頻平臺需要需要解決如何在網頁中播放其它格式視頻的問題。一般來說，解決方案有如下幾種：

  1. Flash 播放器（目前已經很少人使用 Flash ）。

  2. Web 實現一個播放器。

  3. 對視頻解碼成 MP4 格式再使用原生播放器。

對於愛奇藝、騰訊等公司的直播業務，他們使用了上述第三種方式 [4]。當 FLV 格式的直播流到達前端時，使用 WASM 將 FLV 轉封裝爲 MP4 格式，再交給原生播放器。從愛奇藝的技術博客中的描述我們可以知道，由於之前使用的是 JavaScript，其運行效率較低，這部分的性能一直都不太令他們滿意。在引入了 WASM 技術之後替換 JavaScript 來進行轉封裝之後，他們發現瀏覽器中播放視頻的性能提高了將近 20%。下圖爲愛奇藝直播使用 WASM 之後的性能提高。

圖 5. 愛奇藝直播使用 WebAssembly 之後的性能提高

在圖形渲染方面，一個使用 WASM 的例子就是 Qt。Qt 是一個跨平臺的 C++ 庫，它可以用於開發桌面應用程序和移動應用程序。Qt 主要用來開發圖形用戶界面（Graphical User Interface，GUI）程序，當然也可以用來開發不帶界面的命令行（Command User Interface，CUI）程序。從 Qt 5.11.0 發佈時，WASM 的支持開始作爲 Qt 5.11 工具包更新的一部分發布 [5]。

Qt for WebAssembly 的目標是爲任何安裝了支持 WASM 瀏覽器的平臺編譯部署 Qt 應用到 Web 服務器上，不再需要對於不同的系統（例如：Mac, Windows 等）進行編譯並進行部署。這樣編譯一次並部署到 Web 服務器上之後，不同平臺的用戶都能夠使用編譯好的 Qt 程序。下圖爲一個 Qt for WebAssembly 應用程序運行的例子。

圖 6. Qt for WebAssembly 應用程序運行的例子

其它一些應用則使用 WASM 來提供了一種基於瀏覽器的使用體驗，包括 Figma、AutoCAD、Google Earth。這裏我們重點講一下 Figma。

Figma 最近 200 億美元被 Adobe 收購。究竟爲什麼一個面向專業用戶、不到十年的一個設計軟件，能值這麼多錢，而另外一個類似的和 Figma 競爭的軟件 Sketch 卻在競爭中敗陣下來？一個重要的原因就是 Sketch 是一個原生 MacOS 應用，只能在蘋果電腦上安裝運行，沒有免費版。Figma 則是一個瀏覽器應用，只要有瀏覽器就能使用，而且有免費版。下圖是瀏覽器打開 Figma 時的樣子：

圖 7. Figma 瀏覽器界面

使用 WASM 後，Figma 提高了他們的響應和載入速度。下圖爲在 Firefox 之上 Figma 的載入時間在 WASM 和 asm.js 之間的不同。我們可以看到，在使用 WASM 後，大文檔的載入速度有了明顯的提高。

圖 8. Figma 在 Firefox 之上的載入時間

2.1.2 瀏覽器平臺的虛擬現實（VR）和遊戲相關

幾乎每個人都玩過計算機上的遊戲，但是在瀏覽器上玩遊戲的人卻很少。這是因爲瀏覽器上的遊戲曾經通常都是使用 Flash 或者 Java Applet 開發，而目前這兩種技術都已經被淘汰了。如今，WASM 可以讓遊戲開發者在瀏覽器上開發遊戲，而不需要使用 Flash 或者 Java Applet。這樣，遊戲開發者就可以在瀏覽器上開發遊戲了。

最近虛擬現實（VR）技術也很火熱，很多人都想在瀏覽器上體驗虛擬現實。WASM 可以讓開發者在瀏覽器上開發 VR 應用，使得用戶不需要下載安裝任何軟件就可以在瀏覽器上體驗虛擬現實。

主流遊戲引擎（虛幻，Unity）都已經支持編譯目標爲 WASM 。在發展早期，asm.js 曾是在瀏覽器環境運行這些引擎的解決方案。因爲 WASM 解決了 asm.js 的痛點，相比之下速度更快，代碼更少，使用內存量更少，所以現在 WASM 成爲它們在瀏覽器環境中的默認編譯目標。

在遊戲方面，基於 WASM 的遊戲中，最有名的就是移植的《毀滅戰士 3》（ Doom 3 ）。它是一款恐怖的第一人稱射擊遊戲，最初於 2004 年在微軟的 Windows 系統上發行。《毀滅戰士 3》使用了 Id Tech 4 遊戲引擎（更常稱之爲 Doom 3 引擎），該引擎是於 2011 年根據 GNU 通用公共許可證協議發佈的。這款遊戲獲得了巨大的商業成功，銷量超過了 350 萬份。在 2018 年，它被移植到瀏覽器平臺。下圖爲 Doom 3 瀏覽器平臺運行界面：

圖 9. Doom3 在 Web 平臺運行界面

一般來說，編譯爲本地代碼的應用程序性能要高於基於瀏覽器的編譯版本。在虛擬現實（VR）場景中，響應速度是非常重要的。爲了解決瀏覽器版本的延遲問題，人們會傾向於使用 WASM 。在 Khomtchouk 的論文《 WebAssembly enables low latency interoperable augmented and virtual reality software 》中，就使用了 WASM 來提供了一個很有前途的解決方案，可爲基於瀏覽器的應用程序帶來近乎本地化的低延遲性能，通過在任何 WiFi 或支持蜂窩數據網絡的 AR/VR 設備上運行的 WASM 的字節碼實現大規模硬件不可知的互操作性。

2.1.3 其他基於 Web 環境的應用

除了上述例子之外，在瀏覽器環境中 WASM 還有很多獨特的應用。在 Java 方面，TeaVM 將 Java 字節碼編譯成 JavaScript 和 WASM 的 AOT 編譯器（翻譯器）並最終在瀏覽器中運行。TeaVM 不需要 Java 源文件，它直接將編譯好的.class文件編譯成 JavaScript 和 WASM 。下圖表示了 TeaVM 的編譯方式。因爲是基於 Java 字節碼來編譯的，所以 TeaVM 對於 Kotlin 和 Scala 同樣也適用。

圖 10. TeaVM 使用例子

在數據庫方面，DuckDB-WASM 是一個用於瀏覽器的進程內分析 SQL 數據庫。它可以使用 Arrow 語言，讀取由文件系統 API 或 HTTP 請求支持的 Parquet、CSV 和 JSON 文件，在主流瀏覽器上均經過測試。

物理引擎方面，Box2d 是一個優秀的 2D 物理引擎，Box2d-WASM 將 Box2d 編譯成了 WASM ，從而可以在瀏覽器環境中使用。在他們的 GitHub 頁面上有該引擎的動態演示。

圖 11. Box2d-WASM 運行的例子

2.2 雲原生場景（ Cloud Native ）

雲原生是一種基於容器的應用開發和部署方式，它的目標是將應用程序打包成容器，然後將容器部署到雲平臺上。雲原生的應用程序可以在任何地方運行，包括本地計算機、雲平臺、邊緣計算設備等。雲原生的應用程序可以通過 Kubernetes 等容器編排工具進行管理，從而實現自動化的部署、擴展、監控等功能。

WASM 作爲一種新興的技術，可以在雲原生場景中發揮重要作用。在雲原生場景中，WASM 可以用於編寫雲原生應用程序，也可以用於編寫雲原生的基礎設施。在這個章節中，我們將介紹 WASM 在雲原生場景中的應用，包括雲原生應用及其分發、雲原生平臺能力、邊緣計算和函數無服務計算（ FaaS/Serverless ）。

2.2.1 雲原生應用

在雲原生時代，Kubernetes 已經成爲分佈式環境下資源調度和應用編排的事實標準，Kubernetes 可以屏蔽底層設施的差異性。Kubernetes 可以在同一個 K8s 集羣中包含 x86、ARM 等不同體系架構的節點，同時支持 Linux，Windows 等不同的操作系統。WASM 和 Kubernetes 相結合可以進一步提升應用的可移植，我們在下面會介紹兩種主要的方式來完成 Kubernetes 對 WASM 的編排，分別是 使用傳統容器以及使用 Krustlet。

2.2.1.1 傳統容器（ Container ）

在介紹傳統容器的使用之前，我們先了解一下什麼是容器。容器是一種輕量級的虛擬化技術，它可以將應用程序和它的依賴打包在一個文件中，然後在不同的環境中運行。容器的優勢在於它的輕量級，可以在不同的環境中運行，而不需要額外的虛擬化層。容器的缺點在於它的性能較差，因爲它需要在宿主機的內核上運行，而不是直接運行在硬件上。

這是有別於傳統的虛擬機技術，虛擬機技術可以在不同的硬件架構上運行，而不需要額外的虛擬化層。但是虛擬機技術的缺點在於它的性能較差，因爲它需要在宿主機的內核上運行，而不是直接運行在硬件上。

下圖展示了容器和虛擬機的區別：

圖 12. 容器和虛擬機的區別

在 2022 年 10 月底，Docker 宣佈推出與 WASM 集成 (Docker + WASM) 的首個技術預覽版，並表示公司已加入字節碼聯盟 ( Bytecode Alliance ) ( Bytecode Alliance 是 WASM 和 WebAssembly System Interface 背後的非營利組織)，成爲投票成員。目前開發者已經可以通過最新版的 Docker 快速構建面向 WASM 運行時的應用程序。

Docker Engine 繼續使用與整體生態相統一的 Containerd 容器運行時，但創建了一個新的 Containerd Shim， 把負責容器進程運行的 runC 替換成 WasmEdge 運行時，Wasm Module 的啓動和運行都依賴於 WASM 運行時環境，詳情請見下圖。這部分是和 WasmEdge 合作的項目，這個 Containerd Shim 從 OCI artifact 中提取 WASM 模塊，並使用 WasmEdge 運行時來運行。雖然這裏使用了 WasmEdge , 理論上可以把這部分擴展到 Wasmtime 等其他的 WASM 運行時。

圖 13. Docker+WASM

2.2.1.2 Krustlet

在介紹 Krustlet 之前，我們先了解一下什麼是 Kubernetes。Kubernetes 是一個開源的容器編排引擎，它可以自動部署、擴展和管理容器化的應用程序。Kubernetes 由 Google 公司在 2014 年開源，目前已經成爲 CNCF 基金會的核心項目之一。下圖展示了 Kubernetes 的架構：

圖 14. Kubernetes 架構

在 Kubernetes 中，Kubelet 是一個守護進程，它負責管理容器的生命週期，包括創建、啓動、停止、刪除容器。Kubelet 通過與 Kubernetes Master 通信來獲取容器的創建、啓動、停止、刪除等指令。Kubelet 通過與 Docker 通信來創建、啓動、停止、刪除容器。

微軟的 Deis Labs 在 2020 年宣佈了 Krustlet 項目，Krustlet 是 “Kubernetes RUST kubeLETs” 的簡稱，它爲 WASM 代碼提供了一個新的沙盒環境，是一個用於將 Kubernetes 管理的工作負載交付給 WASM 運行時的工具。它採用了新的編程語言實現 Kubernetes 的核心組件 Kubelet。相比於 Kubelets 用 Go 編寫，Krustlet 是在 Mozilla 的類型安全和內存安全 Rust 中開發的。

Krustlet 可以被視爲 Kubelet 的替代實現，但是 Krustlet 專注於管理 WASM ，而不是使用傳統容器。我們可以理解爲重新用 Rust 實現了一遍 Kubelet 的功能，它使用與 Kubelet 相同的機制，通過 List and Watch 監聽 Pod 信息，管理 Pod 生命週期，同時將 Host 級別的數據等管理指標彙報給 APIServer。在 Kubernetes 架構中同時擁有 Kubelet 和 Krustlet，同時在一個集羣中管理 容器 和 WASM 。

從成熟度角度來看，個人認爲 Krustlet 還是一種概念驗證，因爲它還不支持 Pod Events 或 Init 容器等特性。WASM 的應用程序必須實現 WASM 系統接口 (WASI)，目前跟傳統容器的功能還不能全部對齊，而單獨爲了 WASM 重寫一套 Kubelet 感覺並沒有那麼有必要，所以整體來看這種方式來支持 WASM 侷限非常多。截止 2022 年 11 月，Krustlet 目前也不再積極維護中。

2.2.2 雲原生應用分發

爲了部署雲原生應用，我們需要將應用的鏡像分發到集羣中，然後通過 Kubernetes 的調度器將應用部署到集羣中。在 WASM 中，目前仍然沒有一個統一的分發方式，目前主要有兩種方式：通過第三方的分發平臺，或者通過將 WASM 代碼打包成鏡像的方式。

WAPM 全稱是 WebAssembly Package management。是目前社區提供的類似 NPM 的包管理實現，來專門支持 WASM 製品的分發。我們可以在這個倉庫上 發佈自己的 WASM 程序，或者下載運行別人發佈的 WASM 程序。它由 Wasmer 公司創建於 2019 年，作爲一個開源項目，幫助 WASM 開發者輕鬆分享打包的代碼模塊。

2.2.3 雲原生平臺能力

雲原生平臺能力是雲原生應用的基礎，包括：服務發現、負載均衡、服務網格、日誌監控、配置管理、安全等。目前 WASM 在這些領域的支持還不夠完善，但是社區也在不斷的完善中。在這裏，我們需要重點介紹的是 Envoy Proxy 和 Istio。

Envoy 是一個高性能、可編程的 L3、L4 和 L7 代理，它是 Istio 的核心組件，也是 Istio 的數據平面。Envoy 本身是一個 C++ 項目，但是在 2021 年 10 月份，Envoy 官方發佈了 Envoy WASM 擴展，支持在 Envoy 中運行 WASM 程序。Envoy WASM 擴展的目的是爲了讓開發者能夠在 Envoy 中運行 WASM 程序，來實現自定義的功能。Envoy WASM 擴展的實現是基於 Proxy-WASM ，Proxy-WASM 是一個通用的 WASM 運行時，它提供了一套標準的 API，來讓開發者能夠在不同的 WASM 運行時中實現跨平臺的功能。

下圖展示了 Istio 中包含 Envoy Proxy 的架構圖 [6]。在每個節點，Envoy Proxy 作爲 Sidecar 與應用程序一起運行，Envoy Proxy 會與 Istio 控制平面進行通信，來獲取配置信息，以及上報應用程序的運行狀態。Envoy Proxy 會根據配置信息，來實現服務發現、負載均衡、服務網格、日誌監控、配置管理、安全等功能。

圖 15: Istio 中的 Envoy 架構

下圖展示了 Envoy 使用 WASM 擴展的架構圖 [7]。Envoy WASM 擴展是基於 proxy-wasm 實現的，它提供了一套標準的 API，來讓開發者能夠在 Envoy 中運行 WASM 程序。

圖 16: Envoy 使用 WASM 擴展

2.2.4 邊緣計算（ Edge Computing ）

過去幾年，雲計算的邊界不斷向邊緣側延伸。作爲雲原生技術事實標準的 “Kubernetes + 容器” 組合，自然也被很多人考慮部署到邊緣側，以提高邊緣應用部署的效率和便利性，降低邊緣應用與硬件之間的耦合度。不過 “ Kubernetes + 容器” 組合並非萬用良藥，對於邊緣計算場景來說，它們還是太重了。

邊緣設備通常硬件資源有限，沒有足夠的資源部署運行完整的 Kubernetes。其他問題還有：很多邊緣設備基於 ARM 架構，但大部分 Kubernetes 發行版不支持 ARM 架構；邊緣設備所處環境複雜，無法保證穩定可靠的網絡連接，而 Kubernetes 不支持離線運行，等等。爲了解決包含但不限於以上 Kubernetes 在邊緣計算場景下的挑戰，更好地將 Kubernetes 從雲端延伸到邊緣，業內已經誕生了多個基於原生 Kubernetes 優化的開源項目，比如華爲開源的 KubeEdge、阿里開源的 OpenYurt、騰訊開源的 SuperEdge、Rancher 開源的 K3s 等，並且這四個項目都已經被 CNCF 接收。

而傳統容器方案比如 Docker，問題與 Kubernetes 類似，它還是一個相對重的容器運行時，鏡像大小很容易就達到一兩百 MB 以上，對於資源不足的硬件——邊緣場景有不少內存和磁盤空間小於 1GB 的微型設備，Docker 也不是一個理想的選擇。

邊緣計算不僅需要更輕量的 Kubernetes，也需要更輕量、更快的容器方案，WASM 就是近幾年出現的一個新選擇。

2.2.4.1 Fastly

Fastly 在 2019 年開源了 Lucet 項目，首次將 WASM 從主流瀏覽器場景帶到邊緣之上，這個項目演化成了今天最流行的 WASM 運行時和編譯器之一 Wasmtime，作爲最早在邊緣場景落地 WASM 運行時的邊緣雲廠商，Fastly 將 lucet(Wasmtime) 整合到邊緣計算平臺 Compute@Edge，爲邊緣上 serverless 計算提供了安全隔離和高密部署的體驗，平均啓動時間在 82µs，並達到接近於 0 的內存啓動消耗。如下圖所示爲 Fastly 提供的啓動沙箱分配內存耗時的性能測試 [8]。

圖 17: Fastly 沙箱啓動時間分佈

在語言支持上，Compute@Edge 通過 WASI 實現對不同語言接口支持，用戶可以根據 Compute@Edge hostcall ABI 使用對應的 WASI 工具生成對應的自定義 SDK ，實現了兩個基本的 (fastly_http_req, fastly_http_body) 接口後，用戶可以在應用中使用基於抽象二進制接口（ABI）自定義的 SDK ，並在 Compute@Edge 中啓動。更多的實例可以參考[9]。

除此以外，Compute@Edge 提供了豐富的工具鏈，包括運行時的實時日誌記錄以及對每個 WASM App 的請求跟蹤的能力。

2.2.4.2 Cloudflare Workers

Cloudflare 在邊緣平臺服務的運行時 Cloudflare Worker 中加入了對 WASM 的支持，基於 V8 引擎進行改進，提供了安全隔離的沙箱環境，通過統一的控制面和元數據存儲，同時提供了進程級別的管理和流量調度能力。如下圖所示 [10]：

圖 18: Cloudflare Worker 整體架構

作爲 WASM 的運行時，Cloudflare Worker 支持 C/C++，Rust 等多語言在邊緣上的函數計算。Cloudflare 認爲 WASM 主要適用於計算密集型任務，如圖片處理和數學計算。一個簡單的例子可以參考 [11]。

2.2.5 函數計算 / 無服務器計算（ FaaS/Serverless ）

函數計算 / 無服務計算（FaaS / Serverless）是一種基於事件驅動的計算模型，用戶可以通過事件觸發函數的執行，函數執行完成後，用戶可以根據需要選擇是否保留函數的執行結果。它通過將計算資源抽象爲函數，將函數的執行與事件的觸發解耦，從而實現了計算資源的彈性伸縮和按需付費。

Serverless 將會在接下來的十年裏，迅速地被採用，得到迅猛的發展。Serverless 計算將會成爲雲計算默認的計算範式，並取代 Serverful（傳統雲）計算模式

在 Serverless 計算中，現有的主流技術是利用沙箱容器技術，如 AWS Firecracker 或者阿里雲沙箱容器，來實現強隔離的安全執行環境，但是也帶來更大的資源消耗。雖然現在阿里雲沙箱容器經過優化可以實現 300ms 的冷啓動速度，接近 Docker 這樣的 OS 容器啓動速度，但是還無法滿足函數 PaaS 毫秒級的啓動要求，目前需要通過的調度策略，預留一定的 Standby 實例纔可以滿足，但是這樣也引入了更多的資源消耗。

WASM 所具備的的安全、可移植、高效率，輕量化的特點，爲應用沙箱的發展帶來了全新的思路。WASM 可以輕鬆實現毫秒級冷啓動時間和極低的資源消耗。同時 WASM 字節碼比原生機器碼有更高的安全級別。此外，WASI 實現了細粒度基於能力的安全模型，遵循最小權限原則。在執行過程中，WASI 應用只能訪問由依賴注入指明的確切資源集，這種方式與傳統粗粒度的操作系統級隔離相比，進一步收斂了安全攻擊面。

騰訊雲在 2020 年發佈的 SCF Custom Runtime（自定義運行時）可以支持用任何編程語言編寫的函數，每個函數通過託管自定義的運行時，提供函數服務。騰訊雲與 Second State (WasmEdge) 合作，提供了一個 ServerlessAI 推理的函數模板，添加了類 WASI 的擴展 wasi-tensorflow，使 TensorFlow 模型能夠以硬件速度運行。WASM 虛擬機在這個過程中提供了安全性、可移植性和開發者易用性。具體例子可以參考在騰訊雲上部署基於 WASM 的高性能 serverless 函數的例子 [12]。

AWS 同樣在 Lambda 中支持了將 WasmEdge 作爲 Docker Container 沙盒環境進行接入，用戶可以使用 Rust 編譯好的 WASM Module 構建鏡像並上傳，將本地測試通過的 WASM 應用部署到 AWS Lambda 之上，並提供與常規 AWS Lambda 相同的 Serverless 服務體驗，完整例子在 [13]。其架構爲下圖所示：

圖 19: WS 在 Lambda 中引入 WasmEdge 作爲 WASM 函數運行時

2.3 移動設備、IoT 和物聯網

之前的段落我們大篇幅介紹了在雲原生環境中 WASM 的應用，但是 WASM 的應用場景並不僅限於雲原生環境，它還可以應用於移動設備、IoT 和物聯網等場景。隨着移動設備的發展，移動設備的性能也在不斷提升，但是移動設備的計算能力仍然遠遠不及 PC 端，而 WASM 的出現，可以讓移動設備上的應用具備更高的性能，同時也可以讓移動設備上的應用具備更高的安全性。

IoT 剛剛走入人們視野的最初幾年，我們一般只能通過諸如 C/C++ 甚至是彙編語言來爲這些物聯網嵌入式設備編寫軟件程序。後來，隨着互聯網技術的不斷髮展，以及從易用性、流行程度、生態系統等其他多方面的考慮，諸如 JavaScript 、Lua 以及 Python 等高抽象層次的語言也被逐漸應用在嵌入式設備上，“性能” 可能不再是人們選擇嵌入式設備編程語言時所需要考慮的第一要素。但現實情況是，並不是所有的嵌入式設備都可以滿足這些高抽象層次語言虛擬機在其上流暢運行的要求。並且在考慮功耗以及應用環境等情況時，它們的性能和易用性便開始捉襟見肘。而此時， WASM 字節碼的高密度、高性能以及高可移植性使得我們有了可嘗試的新選擇。

一些公司已經在此領域開始了嘗試。三星在其 Tizen Studio 中支持使用 WASM 開發運行在其基於 Tizen 系統的智能電視 (Smart TV) 上的應用。小米公司則在自研的基於 Linux 的 VelaOS 物聯網操作系統之上支持了 WASM Micro Runtime（WAMR） 輕量 WASM 運行時。在天貓精靈，他們開發了面向 AIoT 場景的高性能應用開發框架 Waft。Waft 將不同語言開發的 App 編譯爲統一的基於 WASM 的 Waft App，並在不同的平臺上運行。

2.4 區塊鏈技術

這幾年，數字貨幣的概念被炒的火熱。一批數字貨幣的忠實信徒和投機者參與到了這場基於區塊鏈技術的數字貨幣的狂歡中，最後導致了一系列經濟和社會問題。

然而，僅從技術角度來看，區塊鏈技術有它獨特的優勢。毫無疑問，比特幣是區塊鏈技術應用最被人熟知的例子。比特幣開創了去中心化密碼貨幣的先河，然而比特幣並不完美，其中協議的擴展性是一項不足。比特幣協議裏使用了一套基於堆棧的腳本語言，這語言雖然具有一定靈活性，使得像多重簽名這樣的功能得以實現，然而卻不足以構建更高級的應用，例如去中心化交易所等。以太坊從設計上就是爲了解決比特幣擴展性不足的問題。

以太坊在擁有比特幣網絡中基本的數據存儲功能之外，還需要運行各種代碼進行計算，由以太坊虛擬機（ EVM ）所編譯和解釋執行的軟件或者應用就是 “智能合約”。當以太坊鏈上發生轉賬交易的時候，以太坊虛擬機（ EVM ）會進行以下一系列工作：

以太坊的原生的 EVM 在使用中暴露了不少的問題：

在新的版本中，它提供一個基於 WASM 的 eWASM 文件格式。可以把認爲是下一代虛擬機的技術標準。如何理解 eWASM 呢？下面的公式解釋了 eWASM：

eWASM = WASM - 不確定性(浮點運算) + 計費 + EEI方法(用來和以太坊溝通)

那麼在以太坊虛擬機上使用 WASM 有什麼優勢呢？主要這裏有三點：1. 速度；2. 預編譯；3. 靈活性 / 互操作性。

速度方面，EVM 只能處理 256 位字節碼，而 WASM 直接轉換爲編譯代碼，能夠更快的加載。預編譯方面，EVM 依賴預編譯，WASM 不需要預編譯，執行起來更加高效，開發者可以創建高效快速的智能合約，而不用擔心潛在的硬分叉。在靈活性 / 互操作性上，WASM 支持更多的語言編譯成 WASM 代碼，並且提供了比 EVM 更廣泛的工具集。

總的來說， 除了以太坊以外，Cosmos 和 Polkadot 也都在其區塊鏈上使用了 WASM。很多人相信 WASM 在未來將會成爲去中心化應用開發的基礎層。

2.5 其它場景

Fluvio

Fluvio 是一個用於實時數據的高性能分佈式流媒體平臺。他們實現了編寫對流數據進行內聯操作（ inline operations ）的自定義代碼的功能。該功能被稱爲 SmartModules。它由 WASM 提供支持，儘可能輕量和高性能。

圖 20. Fluvio 架構

Deno

Deno 是一個 JavaScript/TypeScript 的運行時，默認使用安全環境執行代碼，有着卓越的開發體驗。Deno 建立在 V8、Rust 和 Tokio 的基礎上。跟 Node.js 一樣，Deno 也是一個服務器運行時，但是支持多種語言，可以直接運行 JavaScript、TypeScript 和 WASM 程序。

它內置了 V8 引擎，用來解釋 JavaScript。同時，也內置了 tsc 引擎，解釋 TypeScript。它使用 Rust 語言開發，由於 Rust 原生支持 WASM ，所以它也能直接運行 WASM 。它的異步操作不使用 libuv 這個庫，而是使用 Rust 語言的 Tokio 庫，來實現事件循環（event loop）。

相比於 Node.js，Deno 提高了 Node.js 的安全性。這主要是由於 Deno 在默認情況下不允許程序訪問磁盤、網絡、子進程或環境變量。

WasmCloud

WasmCloud 是一個旨在幫助開發人員創建安全、可移植和可重用組件（稱爲 Actor ）的平臺。它利用 WASM 實現極高的可移植性，來對用戶軟件提供保護、部署、維護、觀察和升級的能力。同時在這個過程中儘可能減少用戶需要複製粘貼的和業務無關的代碼。

2.6 未來發展

目前 WASM 還在快速發展階段，仍然存在一些需要解決的問題和增添更多的特性，例如：單指令多數據流（SIMD）、異常處理、併發、垃圾收集等。同時，其性能和本地代碼相比，很多場合仍然有一定的差距。

  1. 總結

至此，我們已經討論了 WASM 在各種不同場景的應用和未來的發展趨勢。如果非要拿出一個類似的技術來讓讀者對 WASM 更加有一些直觀的理解的話，那麼我們可以把 WASM 理解成爲更有潛力的一個 Java 語言的競爭者。當然， WASM 還處在發展的初期，還有很多不完善的地方。但是，只有這樣，我們纔有更多的機會來探索和發現更多的可能性，不是嗎？這裏是一片藍海，我們可以在這裏創造屬於我們自己的價值。

  1. 參考文獻

[1]. 《The State of WebAssembly 2022》: https://blog.scottlogic.com/2022/06/20/state-of-wasm-2022.html
[2]. 《The Wasm Application & Infrastructure Landscape》: https://sapphireventures.com/blog/whats-up-with-webassembly-computes-next-paradigm-shift/
[3]. 《WebAssembly》: https://developer.mozilla.org/en-US/docs/WebAssembly
[4]. 《愛奇藝直播 WebAssembly 優化之路》: https://cloud.tencent.com/developer/news/464897
[5]. 《Qt for WebAssembly 技術預覽版發佈 Beta 版本》: https://www.codercto.com/a/15920.html
[6]. 《Envoy 教程》: https://www.amoyw.com/2021/03/05/envoy/
[7]. 《Write WASM filters for Envoy and deploy them in ASM》: https://www.alibabacloud.com/help/en/alibaba-cloud-service-mesh/latest/write-wasm-filters-for-envoy-and-deploy-them-in-asm
[8]. 《The lifecycle and performance of a Lucet instance》: https://www.fastly.com/blog/lucet-performance-and-lifecycle
[9]. 《Custom SDKs on Compute@Edge》: https://developer.fastly.com/learning/compute/custom/
[10]. 《Cloudflare Docs: Security model》: https://developers.cloudflare.com/workers/learning/security-model/
[11]. 《Cloudflare Docs: Hello World in Rust》: https://developers.cloudflare.com/workers/tutorials/hello-world-rust/
[12]. 《在騰訊雲上部署基於 WebAssembly 的高性能 serverless 函數》：https://juejin.cn/post/6994377781979283470
[13]. 《WebAssembly serverless functions in AWS Lambda》: https://www.cncf.io/blog/2021/08/25/webassembly-serverless-functions-in-aws-lambda/
[14]. 《虛擬機之戰：WASM 與 EVM | 萬向區塊鏈小課堂》: https://www.panewslab.com/zh/articledetails/D28830508.html
[15]. 《WASM 將引領下一代計算範式 [譯]》: https://www.oschina.net/news/214580

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/yHrjL3MSgkvZ65Tk93BQAA

猜你喜歡