WebAssembly 元件在 WebAssembly 模組內執行的執行時部署中起著關鍵作用。 然而，它的標準化仍在進行中。
翻譯自什麼是 webassembly 元件？終極指南，作者：B cameron gain。WebAssembly 元件在部署位於 WebAssembly 模組內部的執行時中起著關鍵作用。 但是，其標準化仍在開發中。
一旦最終確定，元件模型將允許 WebAssembly 不僅將其使用擴充套件到 Web 瀏覽器和伺服器之外，而且還允許使用者通過稱為 WebAssembly 系統介面 （WASI） 的元件介面在數千個端點上同時以極高的速度部署在眾多輕量級模組中執行的不同應用程式，而無需對 WebAssembly 進行任何更改。 這至少在理論上是這樣，但與此同時，社群正在努力實現這一目標。 同時，關於元件是什麼以及它如何影響 WebAssembly 的採用，存在很多困惑。 在我們深入研究元件是什麼以及它的作用之前，我們首先需要描述 WebAssembly 是什麼，以及它的發展如何導致對元件模型的需求，特別是它與 WASI 的關係，WASI 是乙個將 Web 程式集模組鏈結到元件的標準介面或 API。 WebAssembly 旨在部署以開發人員選擇的語言編寫的應用程式，以便在各種不同的環境中同時部署。 這裡的“不同”是指 WebAssembly 執行在 CPU 上，只有裝置、伺服器等可以執行 CPU 指令集。 這意味著從理論上講，單個 WebAssembly 模組中的應用程式部署應該能夠在許多不同的裝置上執行和更新，包括伺服器、邊緣裝置、多雲、無伺服器等。
只要有乙個能夠執行指令集的 CPU，WebAssembly 就被設計為執行越來越多的應用程式，這些應用程式是用它可以託管在模組中的語言編寫的。 它現在可以容納 Python、J**Ascript、C++、Rust 等。
用不同的程式語言編寫的不同應用程式應該能夠在單個模組中共存，儘管此功能仍在大規模開發中。
從本質上講，乙個充滿微服務的模組應該能夠在各種環境中部署多個服務並啟動程式更新，而無需重新配置端點。
從理論上講，只需在模組中配置應用程式，以便在模組內完成工作後，無需單獨重新配置部署模組的每個環境。 但是，這也取決於元件標準的最終確定。
現在，正如我們在 kubernetes 和 docker 中觀察到的那樣，同時在任何地方部署應用程式的願望取決於標準化的元件模型。
這個模型經常被比作樂高積木。 這些元件通過 WASI 作為 Web 程式集模組提供執行時的介面。 這些元件堆疊在一起，將它們連線在一起，以利用各種 WebAssembly 執行時的通用性和實用性來形成由元件組成的統一包或單元。
這種方法的優點在於它提供的安全性，就像 Kubernetes 確保元件不會在記憶體、命名空間或命名空間分配中共享資料一樣。 他們通過 WebAssembly bot 模組維護乙個封閉的或沙盒介面。 然而，實現標準化是一項挑戰;目標是讓元件在任何系統上執行。 這將允許 Web Assembly 模組與元件無縫互動，在 CPU 指令集上部署和執行。 雖然它被配置為對任何遵循標準的模組執行此操作，但該標準仍在進行中，代表了 WebAssembly 旅程的最後一英里。
目前，元件開發在開源社群推進 WebAssembly 的努力中發揮著關鍵作用。 標準元件介面正在以一種創新的方式構建，預示著乙個充滿無限可能性的世界。
許多開源專案和研究計畫正在為這一最終確定過程做出貢獻。 對於開發人員，尤其是像 Kubernetes 這樣的開發人員來說，元件開發的內部工作原理可能沒有多大興趣。 他們主要尋求最終結果：隨著 WebAssembly 與 Kubernetes 的整合程度越來越高，能夠隨心所欲地部署應用程式。 這可能會讓你想起 20 世紀 80 年代和 90 年代 DOS 的出現，當時有大量的書籍深入研究了檔案互動、配置和 DOS 命令。 然而，對於大多數程式設計師和軟體工程師來說，理解這些複雜性並不重要，特別是考慮到 UNIX 和 Linux 在軟體開發領域的主導地位。
在 9 月份的 Wasmcon 大會上，Fastly 的傑出工程師 Luke Wagner 高度重視 WebAssembly 的邊緣交付平台的一些服務，他用一句話描述了 wasm 元件是什麼：乙個新興的、標準的、可移植的、輕量級的、精細沙盒的、跨語言的和復合的模組。 他解釋說，元件是乙個包含匯入、內部定義和匯出的模組。 匯入包括匯入的函式（例如日誌函式）等元素，通常捕獲元件提供的 IO 及其實現依賴項，而不是依賴於一組固定的系統呼叫或固定的執行時全域性命名空間。
內部定義表示執行的核心**，它主要由嵌入式 wasm 模組組成，“其中儲存了 99% 的位元組”。 內部定義也可以稱為進口，“華格納說。
元件可以進一步巢狀其他元件，使它們本質上是遞迴的，“Wagner說。 最後，匯出通過為名稱和型別賦值，將元件的內部定義和匯入公開給客戶端。 ”
在容器世界中，開放容器介面 （OCI） 定義了可分發容器的標準。 Wagner 說，docker build 從原始碼建立容器，docker run 和 kubernetes 執行並部署它以進行共享和組合，docker push 和 docker 組合開始發揮作用。 因此，乙個自然而然的問題出現了：我們可以將 wasm 用於此目的嗎？華格納問道。 “毫無疑問，這是一種標準的可分發格式，但挑戰在於 wasm 主要支援共享記憶體鏈結。 當我們想將兩個 wasm 模組鏈結在一起時，它們通常需要共享記憶體來通過該共享記憶體傳遞復合值，這類似於作業系統的 DLL 或共享物件。 ”
然而，當組合兩個或多個webassembly模組時，它們應該保留自己的獨立記憶體，而不是共享的，Wagner說。 他說，需要有一種方法來傳遞複雜的值並在它們之間轉移所有權，這在它們之間是無法複製的，類似於作業系統的可執行檔案。
是否可以使用可移植作業系統介面（POSIX）封裝wasm模組以建立wasm可執行檔案？
Wagner 說，分發單個 POSIX 可執行檔案通常是不夠的，因為我們經常需要分發一組必須協同工作的可執行檔案，以及配置檔案、靜態資產和目錄結構。 Wagner說，一種解決方案可能是將wasm模組放入乙個以wasm為核心指令集的容器中。
雖然這種方法可能很有用，但它並不能解鎖我們設想的令人興奮的新用例，“華格納說。 “為了實現這一點，我們需要一些新的東西，乙個允許我們使用現有編譯器的wasm包裝器。 我們提出了這個新概念，稱為“元件”。 ”
必須記住，由於其獨特的功能，業務模型是在 WebAssembly 上構建的，這在很大程度上取決於元件模型的最終確定。
Wagner 表示，已經有開發者選擇 Wasm 來“執行**，否則將無法執行”，這促使我們構建了一套可重用的工具來支援第一波語言和 API。 但是，由於這些工具不僅與平台耦合，而且它們通常使用元件模型，現在我們可以吸引新一波的平台構建者，他們正在利用這個元生態系統，並獲得很多他們不必自己構建的東西，“Wagner說。
這可能會吸引目前選擇 WebAssembly 的新一代開發人員，因為它易於重用，並且提高了所有這些可重用元件的生產力。 然後，這可以引導我們構建一套全新的工具，使我們能夠從元件中編寫應用程式並建立乙個全新的開發人員程式設計模型。 ”
重要的是要記住，由於其獨特的功能，圍繞 WebAssembly 正在形成各種商業模式，其中很大一部分取決於最終的元件模型。
目前，開發人員選擇使用 WebAssembly 是為了“執行原本無法工作的東西”，正如 Wagner 所強調的那樣。 這導致了一套可重用工具的開發，旨在支援第一波語言和 API。
由於這些工具不依賴於單個平台，因此它們廣泛基於元件模型。 因此，新一代的平台構建者已經進入了這個領域，利用這個元生態系統，並獲得了大量不必從頭開始開發的資源。
因此，新一代的開發人員被 WebAssembly 所吸引，被它的易重用性和通過這些可重用元件提供的高生產力所吸引。 這反過來又導致了一組新工具的開發，用於組合來自元件的應用程式並建立乙個全新的開發人員程式設計模型。
Wagner說，正在開發乙個正式的規範，其中包括操作語義、參考直譯器和參考測試套件。 bindgen 和 wasm 工具的使用已經實現了 wasm 時間的很大一部分。 預計明年初將實現的乙個重要里程碑是與完全引數化的鏈結、值、資源和控制代碼型別同步的元件。
隨後的主要里程碑是向元件模型中新增 futures 和 processes，引入非同步支援。 “這將是乙個具有挑戰性的步驟，但它將簡化許多原本需要重複完成的工作，”華格納說。 最後，還有一些剩餘的元素需要使用元件模型的 MVP 來完成，例如可選的匯入和匯出。 ”