"WebAssembly is a safe, portable, low-level code format designed for efficient execution and compact representation" – W3C.
本文章介紹WASM與WASI的應用場景，這些場景中已經(jīng)有一些探索性的項目進行中邑闲，這些項目中隱含了未來應用架構與分發(fā)的模式算行。本文翻譯自《WebAssembly – Where is it going?》，作者為 MATEUS PIMENTA 苫耸。
從 WASM 到 WASI
當 WebAssembly (Wasm) 在2017年被主流瀏覽器支持的時候州邢，代表著一種更快的（接近本地）在瀏覽器中運行計算機程序的技術標準成形。
不過褪子，當 Mozilla 在 2019年發(fā)布 WebAssembly System Interface (WASI) 之時量淌，這是一個革命性的時刻。WASI 解除了 WASM 僅瀏覽器運行中的限定嫌褪，擴展到了作為一個獨立的虛擬運行環(huán)境呀枢，可運行在主機上。這代表著一種全新的計算機應用程序編碼笼痛、打包裙秋、運行的技術的誕生。
運行在瀏覽器中的WASM
在2017年 WASM 被主流瀏覽器（Microsoft Edge, Safari, Google Chrome and Firefox）支持之后缨伊，W3C起草了一個WASM標準并很快的進入"recommendation"狀態(tài)摘刑，并在2019年正式發(fā)布。這意味著開發(fā)者可以在瀏覽器中以"接近本地程序性能"運行重負載的程序刻坊，不受JavaScript引擎性能限制枷恕、也沒有跨瀏覽器適配問題。
在瀏覽器中使用WASM谭胚，開發(fā)者可以繼續(xù)使用JavaScript開發(fā)傳統(tǒng)的頁面程序徐块，同時將重負載的功能卸載到WASM編碼的程序中未玻，通過 WebAssembly JS API 交互。
游戲
游戲是WASM最初始的目標場景蛹锰，當?shù)玫揭恍┯螒蛞婀镜闹С种笊罡欤ㄈ?Unreal游戲引擎 宣布支持WASM），牽引了WASM的技術構建方向铜犬。當然舞终，WASM不僅僅用于游戲場景，在 圖像處理 癣猾， 視頻處理 敛劝， 音頻處理工作室，這些場景下的工作當前只能在桌面或服務器上完成纷宇。
人工智能模型推理
人工智能的模型推理也是WASM的一個典型場景夸盟。端側的應用程序脫離服務端，直接加載復雜的模型像捶，例如人臉識別上陕，語音轉文字，在端側完成推理拓春。所有的復雜邏輯都脫離了JavaScript释簿，以Native Code方式運行。
Tensorflow.js 項目為此場景提供了一個WASM應用程序硼莽，Tensorflow.js還可以使用 multithreading and Single Instruction Multiple Data (SIMD) 技術加速計算庶溶。如果 WASM 的 Threading 與 SIMD 規(guī)范發(fā)布，一些新的項目將會隨之出現(xiàn)用于工程化這些技術懂鸵。
兩個重要變化
在瀏覽器中執(zhí)行重載計算的技術會帶來兩個顯著變化偏螺。
- 軟件公司會開發(fā)更多的Web客戶端應用程序。這種交付模式匆光，相比較于軟件包安裝到用戶端的機器上套像，能夠簡化應用程序的升級、安全補丁等維護工作殴穴。這個變化會更進一步加強SaaS這種商業(yè)模式凉夯。
- 在客戶端運行重載計算，相比較于Client-Server模式采幌，消除了客戶端與服務器端的運行時交互劲够，用戶體驗會有一個越階提升，同時也會減少軟件廠商的網(wǎng)絡休傍、計算費用征绎。
超越瀏覽器的WASM
當前，WASM只能在瀏覽器沙箱里運行Native Code。但是WASI規(guī)范中定義了WASM沙箱與主機系統(tǒng)的文件人柿、網(wǎng)絡等交互的接口規(guī)范柴墩。這個能力允許我們在WASM沙箱中運行通用的應用程序，且可以獲得可移植性凫岖、安全性等WebAssembly引入的特性江咳。這里面隱含了深刻的內涵，我們逐一解讀哥放。
容器與容器編排
Docker 創(chuàng)始人 Solomon Hykes 發(fā)表過一個聲明：如果 WASM 與 WASI 早幾年出現(xiàn)歼指，就沒有Docker什么事了。當然甥雕，這個并不表示立馬要把當前所有的docker運行負載使用WebAssembly替換踩身，但是這個表明了WebAssembly可以彌補當前docker容器的一些缺陷。
同時社露，主流的容器托管產(chǎn)品（AWS ECS, AWS Lambda (now with containers!), Google Cloud Run, Azure Containers Instances）挟阻，都開始將WebAssembly作為一種替代傳統(tǒng)容器的技術啟動研究。
更進一步峭弟，微軟的 Deis Labs 已經(jīng)有了個 Krustlet 項目附鸽，可以將WebAssembly放到K8S中編排。
WebAssembly相對與傳統(tǒng)的docker container瞒瘸，有幾個優(yōu)點拒炎。
安全。
即便當前的container在安全領域有很多的防護手段挨务，但是機制上，應用進程是可以直接訪問到host主機的內核玉组，因為container是通過cgroup實現(xiàn)的一種輕量級虛擬化技術谎柄，并不是完整內核虛擬化。雖然有 security context 機制惯雳，但是攻擊面還是很大朝巫。當前也有一種使用完整內核虛擬化的趨勢，包括 gVisor, Firecracker(AWS Lambda, AWS Farget產(chǎn)品都使用此虛擬化技術), Kata石景。這表明安全是很重要的一個考量因素劈猿。
WebAssembly 的安全模型是完整沙箱，這表明系統(tǒng)調用可控潮孽，內存安全揪荣，以及更少的攻擊面。包大小往史。
容器鏡像包大小一直是一個詬病點仗颈，由此出現(xiàn)了很多技術點以及最佳實踐用于減少鏡像包大小。這是因為機制上椎例，容器鏡像要求將內內核之外的挨决、應用程序依賴的lib庫都打包到鏡像中请祖，其目的是實現(xiàn)可移植性。
WebAssembly的交付包只包含應用程序本身（實際情況還會有15%的壓縮）脖祈。
包大小減少后可以實現(xiàn)更短時間啟動應用程序肆捕，如縮短函數(shù)計算中的"冷啟動"時間。Fastly的Lucent疊加AOT技術盖高，冷啟動時間約 50微秒慎陵；Cloudflare 使用 V8引擎，冷啟動時間 5毫秒或舞。這對Serverless計算場景是非常重要的體驗提升荆姆。
邊緣計算
云廠商邊緣計算服務已經(jīng)應用了有些年了， AWS Lambda@Edge 與 Cloudflare Workers 都是基于JavaScript引擎運行用戶代碼映凳，現(xiàn)在WebAssembly提供了一個新的選項胆筒。
基于前面討論的WebAssembly的有點，結合CND廠商的PoP點（point-of-presence）诈豌，一種新的分布式計算應用架構正在形成仆救。這種模式應用不僅能提升用戶體驗，還有顯著的韌性屬性矫渔、以及減少數(shù)據(jù)中心的網(wǎng)絡與計算負載彤蔽。
到目前為止，已經(jīng)有廠商提供了基于WebAssembly的邊緣計算服務庙洼。
- Fastly Compute@Edge 顿痪，一個純基于WebAssembly的的邊緣計算解決方案。
- Cloudflare Workers 油够，在已有的邊緣計算平臺上增加WebAssembly支持蚁袭。
嵌入式，IoT石咬，移動應用揩悄，機器學習等
WASM正在被更多的領域采用。你可以集成WASM到應用程序中鬼悠，比如在允許用戶上傳代碼的應用删性，如規(guī)則引擎，可以使用WebAssembly評估規(guī)則代碼的安全性焕窝。 Wasmer 估計是當前最好的 WASM 運行時蹬挺。
在IoT領域也有一些 WASM 運行時，如 wasm-micro-runtime 與 wasm3 袜啃，這些運行時降低了代碼在不同設備上流轉的復雜度汗侵。 wasm3 還支持 Android 與 iOS 設備。
Intel的工程師正在開發(fā) wasi-nn ，這項工作的目的是使得機器學習代碼在不同架構上流轉更容易晰韵。
當前所處的階段
WASM 在瀏覽器領域的應用相關技術已經(jīng)基本成熟发乔。WASI 規(guī)范也在穩(wěn)步演進中，一些模塊已經(jīng)實現(xiàn)了雪猪，新的特性也在不斷迭代中栏尚。在變成語言領域，已經(jīng)有不少語言支持編譯為WebAssembly字節(jié)碼只恨，且越來越成熟译仗。
在瀏覽器之外，除邊緣計算之外官觅，WASM還處于早期階段纵菌，并不能立馬替換container，最先出現(xiàn)的形式是混合編排休涤，根據(jù)不同業(yè)務場景編排container與WASM咱圆。
WASI標準還在4個階段中的第2個，WebAssembly/WASI性能提議也在審議中功氨。
生態(tài)方面還需要一些考量序苏，近期由WebAssembly 4 個sponsor 成立的字節(jié)聯(lián)盟致力與WASM與WASI的生態(tài)發(fā)展。
