51CTO讀者成長計劃社群招募，咨詢小助手（微信號：CTOjishuzhan）

WebAssembly（又名Wasm）已被證明在瀏覽器中運行得非常好。它被廣泛用作提高速度和安全性的一種方式，尤其是直接在瀏覽器中運行的應用程序的計算簡單性，特別是使用 JavaScript 以及其他語言。這種速度和簡單性最終要歸功于它的二進制計算結構，它直接以非常干凈的方式在 CPU 上運行。

然而，WebAssembly 最終將被廣泛使用的場景，可能是作為一種在單個模塊中跨不同容器和 Kubernetes 集群、設備（例如邊緣和物聯網設備）和多云環境同時部署應用程序的方式。

WebAssembly 可以說初露崢嶸，不負眾望。盡管它是還有待觀察，但它最終能否成功在很大程度上取決于其作為一項技術的價值之外的因素。可能阻礙它的因素包括缺乏關于部署它的標準化設備的協議。

1、關鍵賣點

考慮到其低計算指令集大小，WebAssembly 提供的其他東西是它的超快速度和它的安全性——或者它的沙箱設計使用行業術語——因為在部署期間其他服務或應用程序無法訪問，因為內部代碼仍然存在隔離并且在以毫秒為單位的閃電般快速旅程中無法訪問，以部署在不同的環境中。

WebAssembly 非常適合無服務器環境，被視為克服許多阻礙其采用的無服務器問題的一種方式。今天典型的第三方用例意味著無服務器將需要第三方的支持，而第三方通常是云供應商。對于許多人來說，無服務器架構可能等同于Amazon Web Services上的 Lambda 或來自其他云供應商（例如 Azure、Google Cloud、 Oracle或 IBM）的產品。因此，在許多情況下，組織必須樂于將其多個基礎架構委托給一個第三方云提供商，而不是多個供應商來管理其關鍵應用程序。僅出于這個原因，避免供應商鎖定是 Wasm 的一個關鍵賣點。

Fermyon Technologies 聯合創始人兼首席執行官 Matt Butcher 表示：“我們在 Fermyon 一直聽到的一件事是，開發人員喜歡無服務器函數范式。” “不過，這句話幾乎總是伴隨著‘但是’：雖然每個大云都提供無服務器，但開發人員不喜歡這些產品附帶的供應商鎖定、性能和開發人員體驗?！?/p>

Wasm 的一個基本特征是它如何讓開發人員不再擔心使用大量潛在的庫來讓他們的代碼看到部署?！盁o論底層語言如何，WebAssembly 都提供了共享庫的承諾。例如，一個 JavaScript 程序可以加載一個最初用 Python 編寫的庫和另一個用 Rust 編寫的庫，并同時使用它們，”Butcher 說。“在當今的語言生態系統中，每種編程語言都有自己的YAML解析器、自己的 JPEG 庫等等。用多種語言實現相同的算法會浪費多少小時、幾天和幾個月？WebAssembly 是補救措施。”

2、有望成為新標準

事實上，WebAssembly 有潛力成為編寫應用程序的新標準，它由可以組合并塑造成許多不同應用程序的“真正通用的構建塊”組成，Enterprise Management Associates (EMA) 的分析師 Torsten Volk， 說。對于開發人員來說，這是“無需擔心讓它在這些應用程序的運行時內運行的”完成的。這為開發人員生產力的大幅提升打開了大門，因為開發人員可以從甚至可以作為運行時的一部分提供的樣板模塊庫中進行選擇”Volk 說?！八鼈兛梢园糜谏矸莨芾?、訪問控制、應用程序消息傳遞、數據存儲和數據挖掘的微服務，也可以是整個數據管道、機器學習模型或 API 集成。開發人員將專注于編寫業務代碼，并且只編寫業務代碼，這種前景讓 Wasm 如此令人興奮?！?/p>

然而，就目前而言，WebAssembly 仍然是一項正在進行的工作。除其他外，它正在等待組件接口 Wasi 的標準化，該層需要確保部署 Wasm 應用程序的不同設備和服務器之間的端點兼容性。

3、到底做了什么？

這個想法是，WebAssembly 旨在部署以開發人員選擇的語言編寫的應用程序，以便在不同的環境中同時部署到任何地方?！巴耆煌?，因為 WebAssembly 在 CPU 上運行，只需要一個設備、服務器等，就能運行一個 CPU 指令集。這意味著 WebAssembly 模塊中應用程序的單一部署理論上應該能夠在多種不同的不同設備上運行和更新，無論是服務器、邊緣設備、多云、無服務器環境等。

在任何有 CPU 能夠運行指令集的地方，WebAssembly 旨在運行以越來越多的語言編寫的應用程序，它可以托管在一個模塊中。它現在支持 Python、JavaScript、C++、Rust 等。用不同編程語言編寫的不同應用程序應該能夠在單個模塊中運行，盡管這種功能在很大程度上仍處于開發階段。從本質上講，一個微服務模塊應該能夠用于在多個不同的環境中部署多個服務，并在不重新配置端點的情況下提供應用程序更新。理論上，只需在模塊中配置應用程序即可，一旦模塊內部完成工作，就不必為部署模塊的每個環境單獨重新配置。

4、能取代容器嗎？

WebAssembly 將取代容器和 Kubernetes 的論點在很大程度上是不合邏輯的。這是因為 WebAssembly 和容器以及 Kubernetes 是不同但重要的技術。即使有一些重疊的目的，它們也滿足特定和獨立的計算需求。

至少在不久的將來，許多組織將不愿意更換他們的容器基礎設施和 Kubernetes 環境。除了可能會因為用 WebAssembly 替換它們而失去對它們的投資之外，WebAssembly 并不是一種適用于所有容器化環境的全部替換技術。事實上，最近人們非常關注使用 Wasm 在容器和 Kubernetes 環境中部署應用程序。

Docker 繼續發布關于它將如何容納和擴展對 WebAssembly 的支持的公告。經常討論兩者將如何協同工作，尤其是如何將 Docker 與容器一起使用以允許它們使用 WebAssembly 部署和管理應用程序。這些調整在很大程度上被認為是為 Wasm 的采用和與容器和 Kubernetes 一起使用鋪平道路所必需的。

“憑借超音速啟動速度和輕型運行時要求，Wasm 非常適合無服務器功能——這在歷史上很難在 Docker 中很好地實現。相反，Docker 的突出特點是它能夠以可移植的方式輕松捆綁長期運行的服務器及其環境，”Butcher 說?！伴L期運行的服務器還不是 Wasm 的強項?，F在 Wasm 可以以與容器相同的圖像格式打包，我們將看到這兩種技術結合起來構建那種使用現有技術難以實現的混合無服務器和服務器微服務應用程序?！?/p>

5、比 JavaScript 快嗎？

在廣為人知的萬維網誕生之初，出現了 JavaScript。自 1995 年Brendan Eich創建了支持 Netscape 的語言以來，JavaScript 就已經存在了，Netscape 是一種在當時具有革命性意義的網頁瀏覽器，現在已不復存在但在美學上令人愉悅。從那時起，ECMAScript 標準就成為了 Web 開發的基礎，代表了在 Web 瀏覽器中運行的絕大多數應用程序。

最近，WebAssembly——實際上已經存在了一段時間——出現了。繼 2019 年萬維網聯盟（W3C）將其命名為網絡標準后，它也因此成為繼 HTML、CSS、JavaScript 之后的第四個網絡標準。但是，雖然Web 瀏覽器應用程序 代表了 Wasm 的中心和歷史用例，但重點是它被設計為可以在正確配置的 CPU 上的任何地方運行——這就是 Wasm 和 JavaScript 在某些用例中分叉并變得更加集成的地方。

Wasm 和 JavaScript 保持緊密聯系，但 Wasm 除了 JavaScript 之外還有其他很多東西。簡而言之，Wasm 幫助 JavaScript 在網絡瀏覽器中更高效地運行的最初目的仍然是它們集成的關鍵組成部分。這種集成現在已經超越了 Web 瀏覽器，并擴展到邊緣和服務器應用程序，而 JavaScript 本身并不是最適合的應用程序。

這是由于 Wasm 如何在 CPU 級別以二進制格式運行。別忘了，與 JavaScript 不同，Wasm 不是一種編程語言。Wasm 的主要優點之一是它的功能使其能夠適應除 JavaScript 之外的多種不同語言，當然包括 Python、Rust以及 Go、.NET、C++、Java 和 PHP。

所以，WebAssembly 既可以在需要的時候集成 JavaScript，當然也不限于集成 JavaScript。這種與 JavaScript 的集成和使用一直是 WebAssembly 和 JavaScript 共生的基石，尤其是在 Web 應用程序領域。

對于純計算性能以及圖像處理等任務，WebAssembly 無疑顯示了其比 JavaScript 快得多的優點。但可以說，上下文要比這復雜得多。關于更快的計算時間是否同樣重要，這并不是一個真正的問題，例如移動和 Web 應用程序的輕型編碼任務需要 JavaScript 代碼。

JavaScript 是一種幾乎任何人都可以使用的語言，它提供了許多社區支持的庫，這些庫支持許多用例，而無需每次都重新發明輪子，Volk 指出?！皩?JavaScript 和 Python 等依賴于解釋器的語言作為字節碼執行，并將樣板代碼與核心應用程序分開，可以帶來巨大的性能和容量優勢，”Volk 說。

6、會取代 JavaScript 嗎？

重點不在于 WebAssembly 是否會取代 JavaScript，因為沒有可預見的原因。相反，WebAssembly 將做的是擴展 JavaScript 的范圍，使其更易于部署，而不僅僅是瀏覽器。

“我們在 Fermyon 看到的一切讓我們感到驚訝。開發人員要求在 WebAssembly 中執行 JavaScript 和 TypeScript。我們從我們的社區聽到的是，無服務器范式是他們喜歡的，而 JavaScript 只是他們在構建無服務器功能時希望擁有的多種語言之一，”Butcher 說。“所以，如果 Wasm 最初是 JavaScript 的補充，那么在某些方面這種關系已經倒轉了?！?/p>

7、提供卓越的安全性？

與僅在 JavaScript 中部署的代碼相比，Wasm 可以提供安全優勢。當 Wasm 被用作可以部署 JavaScript 應用程序的“steroids編譯器”時，Wasm 可以使 JavaScript 代碼更加安全。例如，Wasm 將 JavaScript 與瀏覽器隔離開來，確保內存安全，并實現與 JavaScript 的動態類型變量相比更難利用的強類型變量。

“Wasm 的安全模型可以讓龐大的 JavaScript 社區開始創建完整的應用程序，而不是只構建前端并依靠后端開發人員來完成其余的工作，”Volk 說?！皩蝹€ Wasm 模塊鏈接到基本應用程序中，為傳統 JavaScript 前端帶來活力的能力是一個令人興奮的觀點。想象一下，如果前端開發人員能夠安全地在 MongoDB、Postgres 或 SalesForce API 上存儲和訪問數據，將會有怎樣的可能性?！?/p>

事實上，Wasm 在許多方面都提供了安全優勢。這是因為，正如網絡資產管理和治理解決方案提供商 JupiterOne 的首席信息安全官Sounil Yu所說：

Wasm 作為 JavaScript 的編譯器可以通過減少漏洞攻擊面、提供更好的內存安全性、模糊代碼、沙盒化執行環境和利用現有的安全生態系統來提高應用程序的安全性。Wasm 具有有限的指令集和更好的內存管理，這有助于減少漏洞的攻擊面并防止一些常見類型的漏洞，例如緩沖區溢出。

Wasm 代碼通過晦澀難懂的方式提供了一點安全性，因為它不是人類可讀的，這使得攻擊者更難對代碼進行逆向工程，從而更難發現和利用漏洞。

Wasm 還可以在沙盒環境中運行，這有助于將代碼與系統的其余部分隔離開來，以防止它訪問敏感信息或執行非法操作。

Wasm 框架，如 CNCF 的wasmCloud，通過提供更高級別的抽象進一步擴展了 Wasm 安全足跡，減少了開發人員嵌入每個應用程序的代碼量。wasmCloud 還可以更輕松地對工件進行簽名、啟用內置監控和自動化應用程序修補，從而減輕開發人員的安全負擔。

但我們不能說 JavaScript 天生就是不安全的。事實上，Javascript“可以變得非常安全，”微軟 Azure Core Upstream 的首席項目經理 Ralph Squillace 在一封電子郵件回復中說。“瀏覽器是地球上最受攻擊的表面之一。然而，WebAssembly 通過數學上可證明的沙箱模型更容易進行深度防御，Veriwasm 等工具利用了這種模型，”他說。

“此外，您可以使用即將推出的組件模型來限制攻擊面——例如，主機可能甚至不提供文件系統 API——在未來的世界中，這些類型的限制將被證明是至關重要的，”Squillace 說。“但不要被愚弄：主機仍然會犯配置錯誤并為模塊提供過多的功率！”

原文鏈接：https://thenewstack.io/webassembly-the-ultimate-guide/