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

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

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

WebAssembly 可以說初露崢嶸，不負(fù)眾望。盡管它是還有待觀察，但它最終能否成功在很大程度上取決于其作為一項技術(shù)的價值之外的因素?？赡茏璧K它的因素包括缺乏關(guān)于部署它的標(biāo)準(zhǔn)化設(shè)備的協(xié)議。

1、關(guān)鍵賣點(diǎn)

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

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

Fermyon Technologies 聯(lián)合創(chuàng)始人兼首席執(zhí)行官 Matt Butcher 表示：“我們在 Fermyon 一直聽到的一件事是，開發(fā)人員喜歡無服務(wù)器函數(shù)范式。” “不過，這句話幾乎總是伴隨著‘但是’：雖然每個大云都提供無服務(wù)器，但開發(fā)人員不喜歡這些產(chǎn)品附帶的供應(yīng)商鎖定、性能和開發(fā)人員體驗。”

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

2、有望成為新標(biāo)準(zhǔn)

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

然而，就目前而言，WebAssembly 仍然是一項正在進(jìn)行的工作。除其他外，它正在等待組件接口 Wasi 的標(biāo)準(zhǔn)化，該層需要確保部署 Wasm 應(yīng)用程序的不同設(shè)備和服務(wù)器之間的端點(diǎn)兼容性。

3、到底做了什么？

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

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

4、能取代容器嗎？

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

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

Docker 繼續(xù)發(fā)布關(guān)于它將如何容納和擴(kuò)展對 WebAssembly 的支持的公告。經(jīng)常討論兩者將如何協(xié)同工作，尤其是如何將 Docker 與容器一起使用以允許它們使用 WebAssembly 部署和管理應(yīng)用程序。這些調(diào)整在很大程度上被認(rèn)為是為 Wasm 的采用和與容器和 Kubernetes 一起使用鋪平道路所必需的。

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

5、比 JavaScript 快嗎？

在廣為人知的萬維網(wǎng)誕生之初，出現(xiàn)了 JavaScript。自 1995 年Brendan Eich創(chuàng)建了支持 Netscape 的語言以來，JavaScript 就已經(jīng)存在了，Netscape 是一種在當(dāng)時具有革命性意義的網(wǎng)頁瀏覽器，現(xiàn)在已不復(fù)存在但在美學(xué)上令人愉悅。從那時起，ECMAScript 標(biāo)準(zhǔn)就成為了 Web 開發(fā)的基礎(chǔ)，代表了在 Web 瀏覽器中運(yùn)行的絕大多數(shù)應(yīng)用程序。

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

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

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

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

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

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

6、會取代 JavaScript 嗎？

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

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

7、提供卓越的安全性？

與僅在 JavaScript 中部署的代碼相比，Wasm 可以提供安全優(yōu)勢。當(dāng) Wasm 被用作可以部署 JavaScript 應(yīng)用程序的“steroids編譯器”時，Wasm 可以使 JavaScript 代碼更加安全。例如，Wasm 將 JavaScript 與瀏覽器隔離開來，確保內(nèi)存安全，并實現(xiàn)與 JavaScript 的動態(tài)類型變量相比更難利用的強(qiáng)類型變量。

“Wasm 的安全模型可以讓龐大的 JavaScript 社區(qū)開始創(chuàng)建完整的應(yīng)用程序，而不是只構(gòu)建前端并依靠后端開發(fā)人員來完成其余的工作，”Volk 說。“將單個 Wasm 模塊鏈接到基本應(yīng)用程序中，為傳統(tǒng) JavaScript 前端帶來活力的能力是一個令人興奮的觀點(diǎn)。想象一下，如果前端開發(fā)人員能夠安全地在 MongoDB、Postgres 或 SalesForce API 上存儲和訪問數(shù)據(jù)，將會有怎樣的可能性。”

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

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

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

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

Wasm 框架，如 CNCF 的wasmCloud，通過提供更高級別的抽象進(jìn)一步擴(kuò)展了 Wasm 安全足跡，減少了開發(fā)人員嵌入每個應(yīng)用程序的代碼量。wasmCloud 還可以更輕松地對工件進(jìn)行簽名、啟用內(nèi)置監(jiān)控和自動化應(yīng)用程序修補(bǔ)，從而減輕開發(fā)人員的安全負(fù)擔(dān)。

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

“此外，您可以使用即將推出的組件模型來限制攻擊面——例如，主機(jī)可能甚至不提供文件系統(tǒng) API——在未來的世界中，這些類型的限制將被證明是至關(guān)重要的，”Squillace 說?！暗灰挥夼褐鳈C(jī)仍然會犯配置錯誤并為模塊提供過多的功率！”

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