WebAssembly – Where is it going?

"WebAssembly is a safe, portable, low-level code format designed for efficient execution and compact representation" – W3C.

本文章介紹WASM與WASI的應用場景，這些場景中已經有一些探索性的項目進行中，這些項目中隱含了將來應用架構與分發的模式。本文翻譯自《WebAssembly – Where is it going?》，做者爲 MATEUS PIMENTA 。

從 WASM 到 WASI

當 WebAssembly (Wasm) 在2017年被主流瀏覽器支持的時候，表明着一種更快的（接近本地）在瀏覽器中運行計算機程序的技術標準成形。

不過，當 Mozilla 在 2019年發佈 WebAssembly System Interface (WASI) 之時，這是一個革命性的時刻。WASI 解除了 WASM 僅瀏覽器運行中的限定，擴展到了做爲一個獨立的虛擬運行環境，可運行在主機上。這表明着一種全新的計算機應用程序編碼、打包、運行的技術的誕生。

運行在瀏覽器中的WASM

在2017年 WASM 被主流瀏覽器（Microsoft Edge, Safari, Google Chrome and Firefox）支持以後，W3C起草了一個WASM標準並很快的進入"recommendation"狀態，並在2019年正式發佈。這意味着開發者能夠在瀏覽器中以"接近本地程序性能"運行重負載的程序，不受JavaScript引擎性能限制、也沒有跨瀏覽器適配問題。

在瀏覽器中使用WASM，開發者能夠繼續使用JavaScript開發傳統的頁面程序，同時將重負載的功能卸載到WASM編碼的程序中，經過 WebAssembly JS API 交互。

遊戲

遊戲是WASM最初始的目標場景，當獲得一些遊戲引擎公司的支持以後，（如 Unreal遊戲引擎 宣佈支持WASM），牽引了WASM的技術構建方向。固然，WASM不只僅用於遊戲場景，在 圖像處理 ， 視頻處理 ， 音頻處理工做室，這些場景下的工做當前只能在桌面或服務器上完成。

人工智能模型推理

人工智能的模型推理也是WASM的一個典型場景。端側的應用程序脫離服務端，直接加載複雜的模型，例如人臉識別，語音轉文字，在端側完成推理。全部的複雜邏輯都脫離了JavaScript，以Native Code方式運行。

Tensorflow.js 項目爲此場景提供了一個WASM應用程序，Tensorflow.js還可使用 multithreading and Single Instruction Multiple Data (SIMD) 技術加速計算。若是 WASM 的 Threading 與 SIMD 規範發佈，一些新的項目將會隨之出現用於工程化這些技術。

兩個重要變化

在瀏覽器中執行重載計算的技術會帶來兩個顯著變化。

1. 軟件公司會開發更多的Web客戶端應用程序。這種交付模式，相比較於軟件包安裝到用戶端的機器上，可以簡化應用程序的升級、安全補丁等維護工做。這個變化會更進一步增強SaaS這種商業模式。
2. 在客戶端運行重載計算，相比較於Client-Server模式，消除了客戶端與服務器端的運行時交互，用戶體驗會有一個越階提高，同時也會減小軟件廠商的網絡、計算費用。

超越瀏覽器的WASM

當前，WASM只能在瀏覽器沙箱裏運行Native Code。可是WASI規範中定義了WASM沙箱與主機系統的文件、網絡等交互的接口規範。這個能力容許咱們在WASM沙箱中運行通用的應用程序，且能夠得到可移植性、安全性等WebAssembly引入的特性。這裏面隱含了深入的內涵，咱們逐一解讀。

容器與容器編排

Docker 創始人 Solomon Hykes 發表過一個聲明：若是 WASM 與 WASI 早幾年出現，就沒有Docker什麼事了。固然，這個並不表示立馬要把當前全部的docker運行負載使用WebAssembly替換，可是這個代表了WebAssembly能夠彌補當前docker容器的一些缺陷。

同時，主流的容器託管產品（AWS ECS, AWS Lambda (now with containers!), Google Cloud Run, Azure Containers Instances），都開始將WebAssembly做爲一種替代傳統容器的技術啓動研究。
更進一步，微軟的 Deis Labs 已經有了個 Krustlet 項目，能夠將WebAssembly放到K8S中編排。

WebAssembly相對與傳統的docker container，有幾個優勢。

• 安全。
  即使當前的container在安全領域有不少的防禦手段，可是機制上，應用進程是能夠直接訪問到host主機的內核，由於container是經過cgroup實現的一種輕量級虛擬化技術，並非完整內核虛擬化。雖然有 security context 機制，可是攻擊面仍是很大。當前也有一種使用完整內核虛擬化的趨勢，包括 gVisor, Firecracker(AWS Lambda, AWS Farget產品都使用此虛擬化技術), Kata。這代表安全是很重要的一個考量因素。
  WebAssembly 的安全模型是完整沙箱，這代表系統調用可控，內存安全，以及更少的攻擊面。
• 包大小。
  容器鏡像包大小一直是一個詬病點，由此出現了不少技術點以及最佳實踐用於減小鏡像包大小。這是由於機制上，容器鏡像要求將內內核以外的、應用程序依賴的lib庫都打包到鏡像中，其目的是實現可移植性。
  WebAssembly的交付包只包含應用程序自己（實際狀況還會有15%的壓縮）。
  包大小減小後能夠實現更短期啓動應用程序，如縮短函數計算中的"冷啓動"時間。Fastly的Lucent疊加AOT技術，冷啓動時間約 50微秒；Cloudflare 使用 V8引擎，冷啓動時間 5毫秒。這對Serverless計算場景是很是重要的體驗提高。

邊緣計算

雲廠商邊緣計算服務已經應用了有些年了， AWS Lambda@Edge 與 Cloudflare Workers 都是基於JavaScript引擎運行用戶代碼，如今WebAssembly提供了一個新的選項。

基於前面討論的WebAssembly的有點，結合CND廠商的PoP點（point-of-presence），一種新的分佈式計算應用架構正在造成。這種模式應用不只能提高用戶體驗，還有顯著的韌性屬性、以及減小數據中心的網絡與計算負載。

到目前爲止，已經有廠商提供了基於WebAssembly的邊緣計算服務。

• Fastly Compute@Edge ，一個純基於WebAssembly的的邊緣計算解決方案。
• Cloudflare Workers ，在已有的邊緣計算平臺上增長WebAssembly支持。

嵌入式，IoT，移動應用，機器學習等

WASM正在被更多的領域採用。你能夠集成WASM到應用程序中，好比在容許用戶上傳代碼的應用，如規則引擎，可使用WebAssembly評估規則代碼的安全性。 Wasmer 估計是當前最好的 WASM 運行時。

在IoT領域也有一些 WASM 運行時，如 wasm-micro-runtime 與 wasm3 ，這些運行時下降了代碼在不一樣設備上流轉的複雜度。 wasm3 還支持 Android 與 iOS 設備。

Intel的工程師正在開發 wasi-nn ，這項工做的目的是使得機器學習代碼在不一樣架構上流轉更容易。

當前所處的階段

WASM 在瀏覽器領域的應用相關技術已經基本成熟。WASI 規範也在穩步演進中，一些模塊已經實現了，新的特性也在不斷迭代中。在變成語言領域，已經有很多語言支持編譯爲WebAssembly字節碼，且愈來愈成熟。

在瀏覽器以外，除邊緣計算以外，WASM還處於早期階段，並不能立馬替換container，最早出現的形式是混合編排，根據不一樣業務場景編排container與WASM。

WASI標準還在4個階段中的第2個，WebAssembly/WASI性能提議也在審議中。

生態方面還須要一些考量，近期由WebAssembly 4 個sponsor 成立的字節聯盟致力與WASM與WASI的生態發展。

嘗試一下

webassembly.studio

wasm.fastlylabs.com

Reference

WebAssembly-Wiki

WebAssembly

WebAssembly – Where is it going?

關注公衆號得到更多雲最佳實踐

關注公衆號得到更多雲最佳實踐