1、win10 安裝 wasmer
powershell
iwr https://win.wasmer.io -useb | iex
2、在 wasmer「鏈接」 種創建一個賬戶，創建登錄token,完成本地命令行登錄wasmer login
3、初始化 JavaScript Service Worker Starter 模板
$ wasmer app create
App type:
Static website
HTTP server
Browser shell
> JS Worker (experimental)
Python Application
4、創建index.js
async function handler(request) {
const out=JSON.stringify({
success: true,
package: "wasmer/js-service-worker",
});
return new Response(out, {
headers: { "content-type": "application/json" },
});
}
addEventListener("fetch", handler); // Don't change this line
5、運行
$ wasmer run . --net
2023-10-05T09:46:19.513568Z INFO wasmer_winter: starting webserver
2023-10-05T09:46:19.514089Z INFO wasmer_winter::server: starting server on 0.0.0.0:8080 listen=0.0.0.0:8080
6、嘗試訪問服務
$ curl http://127.0.0.1:8080
"success":true,"package":"wasmer/js-service-worker"
7、部署 JavaScript Service Worker
$ wasmer deploy
Deploying app wasmer/js-service-worker...
? App wasmer/js-service-worker was successfully deployed!
> App URL: https://wasmer-js-service-worker-worker.wasmer.app
> Versioned URL: https://rkkh7ikcgv1r.id.wasmer.app
> Admin dashboard: https://wasmer.io/apps/wasmer/wasmer-js-service-worker-worker
WebAssembly 正在為下一波云計算提供動力，不過這得感謝 runwasi，有了runwasis， 才使得WebAssembly超越單純的瀏覽器插件， 走到 Kubernetes為主導的云原生時代！
那么什么是runwasi呢？ 簡單來說，runwasi 是官方 CNCF containerd 項目的一部分，致力于將 Wasm 運行時與 containerd 集成。
在這里將揭開了 runwasi 的神秘面紗，并解釋了它如何將 WebAssembly 引入到 Kubernetes。
首先大家都明白，Kubernetes 主要工作是編排容器。 但是，實際的情況可能超乎多數人的預料……Kubernetes 不關心容器的細節，甚至不知道如何啟動和停止它們。 Kubernetes之所以能做容器的編排工作，主要依賴于一種稱為容器運行時（container runtime）的技術來完成所有容器工作。
這就提出了一個問題——如果 Kubernetes 不關心容器并且需要容器運行時來將容器部署到 Kubernetes……我們可以借助Wasm 運行時，把 WebAssembly 部署到 Kubernetes 嗎？
答案是肯定的。
現代 Kubernetes 集群上最流行的容器運行時（runtime）是 containerd（發音為“container dee”）。 盡管 Containerd 是低級管道技術，但對于 Kubernetes 來說卻是一件大事！
containerd 可作為 Linux 和 Windows 的守護進程使用。 它管理其主機系統的完整容器生命周期，從圖像傳輸和存儲到容器執行和監督，再到低級存儲到網絡附件等等。
containerd 就是我們說的高級運行時。 這意味著它坐在舒適的辦公室里發號施令，而低級運行時則完成實際工作。
舉個簡單的例子，containerd 默認使用 runc 作為其低級運行時。 在當前設計下，containerd 提取鏡像（image），但 runc 創建并啟動容器（container instance）。
containerd架構如下所示。 請注意單個 containerd 實例如何為多個容器發號施令，而每個容器都有自己的 runc 和 shim 進程。
可能有些人對于Kubernetes的底層機制并不是很了解，尤其是shim接口， 這里對于containerd的shim接口多講解一點。
shim的中文意思是“墊片”， 維基百科中是這樣介紹shim的：
墊片是一種薄且通常呈錐形或楔形的材料，用于填充物體之間的小間隙或空間。 墊片通常用于支撐、調整以獲得更好的貼合或提供水平表面。 墊片也可用作墊片，以填充磨損部件之間的間隙。
金屬墊片，metal shim
這里有一個可能是違反我們常識的是，我們一般見到的墊片是圓形的， 而在維基百科中的墊片，通常是錐形或者契形，這點很有意思。
話說回來，前面說到，守護進程containerd并不直接啟動容器。 相反，它充當協調容器和內容活動的高級管理器或中心，稱為“運行時”的較低級程序實際上實現啟動、停止和管理容器，無論是單個容器還是容器組， 例如 Kubernetes Pod。
最常用的運行時引擎（runtime engine）是 runc，它實現了 OCI 運行時規范。 由于這是一個運行時引擎，因此它不會被containerd直接調用； 相反，它由填充程序（shim）調用，該填充程序偵聽套接字并調用運行時引擎，這就是containerd的shim+引擎架構
containerd的shim是這樣工作的，每一個 Containerd 或 Docker 容器都有一個相應的 "shim" 守護進程，這個守護進程會提供一個 API，Containerd 使用該 API 來管理容器基本的生命周期(啟動/停止)，在容器中執行新的進程、調整 TTY 的大小以及與特定平臺相關的其他操作。
以下工作流程說明了在 Kubernetes 上啟動容器時 containerd 和 runc 的角色。
Shims 可以做很多事情，例如保持容器處于活動狀態并向 Containerd 報告退出代碼，向 Containerd 報告容器的退出狀態，在容器退出狀態被 Containerd 收集之前，shim 會一直存在。這一點和僵尸進程很像，僵尸進程在被父進程回收之前會一直存在，只不過僵尸進程不會占用資源，而 shim 會占用資源。
Shims 還抽象了低級運行時的機制。shim 將 Containerd 進程從容器的生命周期中分離出來，具體的做法是 runc 在創建和運行容器之后退出，并將 shim 作為容器的父進程，即使 Containerd 進程掛掉或者重啟，也不會對容器造成任何影響。這樣做的好處很明顯，你可以高枕無憂地升級或者重啟 Containerd，不會對運行中的容器產生任何影響。Docker 的 --live-restore特征也實現了類似的功能。
關于containerd的shim api，更詳細的可以參閱https://github.com/containerd/containerd/blob/main/runtime/v2/README.md#architecture
這與 v2 containerd shim API 相結合，應該允許我們將低級容器運行時替換為 Wasm 運行時。
好了，關于kubernetes，containerd，shim的介紹就先介紹到這里，現在回到最開始，WebAssembly的runwasi，看看runwasi是如何工作的。
runwasi 是官方 CNCF containerd 項目的一部分，致力于將 Wasm 運行時與 containerd 集成。
從架構上來說，runwasi 作為一個 Containerd shim運行——位于 Containerd 和 Wasm 運行時之間。 高層架構如下所示，圖中containerd以下的所有內容對于Kubernetes來說都是不透明的。
runwasi這種 Containerd shim 方法通過利用 Containerd 的龐大安裝基礎，提供了一種將 Wasm 工作負載引入 Kubernetes 的簡單途徑。
“簡單”是一個相對術語，因為 runwasi 仍有很多工作要做。 然而已經有了IT巨頭已經開始埋頭工作…
兩者對于 runwasi 的開發和采用都具有重要意義
在容器內運行 Wasm 工作負載可能看起來有悖常理——為什么要采用比容器更小、更快、更便攜的東西，并在看起來很像容器（命名空間和 cgroup）的東西中運行它？！
至少一個答案是平臺和工具——您無需構建新平臺和學習新工具即可獲得 Wasm 的一些優點。 如果您在 Kubernetes 和 OCI 注冊表等方面投入了大量資金，那么這是一件大事。
無論如何，容器是具有 cgroup 和其他分層安全技術的命名空間的集合。 Wasm 是一個基于堆棧的虛擬機，它實現了一個默認安全的沙盒，將應用程序與內核隔離，并且僅擁有應用程序所需的功能。
所以……在類似容器的結構中運行 Wasm 應用程序可以讓您獲得 Wasm 沙箱、命名空間和 cgroup 的安全優勢。
runwasi 方法有優點也有缺點。
優點包括通往 Kubernetes 的簡單路徑，可與 Pod、Deployments、RuntimeClasses 等現有 K8s 原語配合使用。它允許 Wasm 駕馭 Kubernetes 浪潮，并使 Kubernetes 能夠大膽地去往容器無法到達的地方 – 資源受限的邊緣環境...
缺點包括現有平臺和工具不是為 Wasm 設計的，可能會限制獲得的好處。 此外，Wasm 和組件的開發人員體驗遠遠落后于容器。