Shopify如何在瀏覽器之外使用WebAssembly-ESG跨境

Shopify如何在瀏覽器之外使用WebAssembly

Shopify如何在瀏覽器外使用WebAssembly

Shopify致力于讓大多數(shù)商家需要的功能變得簡(jiǎn)單易用，通過接口在Shopify平臺(tái)上進(jìn)行查詢、擴(kuò)展和更改，從而為商家提供更多的可能性。有了這些接口，我們豐富的合作伙伴生態(tài)系統(tǒng)可以解決許多問題。這個(gè)生態(tài)系統(tǒng)主要由“App”(獨(dú)立托管的Web服務(wù))來運(yùn)營(yíng)。該應(yīng)用程序通過網(wǎng)絡(luò)與Shopify進(jìn)行通信。這種模式雖然功能強(qiáng)大，但是會(huì)帶來一系列的技術(shù)問題。我們的合作伙伴需要建立可以隨著Shopify的規(guī)模而擴(kuò)展的Web服務(wù)，這使得一些資源有限的合作伙伴更加捉襟見肘。即使合作伙伴擁有無限的資源，但與Shopify的通信所帶來的網(wǎng)絡(luò)延遲，也足以讓我們的App在要求高時(shí)效性的用例中失敗。

我們希望我們的合作伙伴可以專注于使用他們的專業(yè)知識(shí)來解決問題，而不是花費(fèi)時(shí)間來管理可伸縮的Web服務(wù)。為了實(shí)現(xiàn)這個(gè)目標(biāo)，我們保持了不受信任的伙伴代碼的靈活性，并在我們的基礎(chǔ)設(shè)施上運(yùn)行它。為了保證這些代碼的性能、安全性和靈活性，我們選擇了WebAssembly作為通用格式。

web程序集

什么是WebAssemblyWebAssembly.org給出了如下定義:

WebAssembly (Wasm)是一種基于棧虛擬機(jī)的二進(jìn)制指令格式。Wasm是一個(gè)為編程語言設(shè)計(jì)的可移植編譯目標(biāo)，它使客戶機(jī)和服務(wù)器應(yīng)用程序能夠部署在Web上。"

要了解更多關(guān)于WebAssembly及其歷史的信息，您可以瀏覽這篇由Mozilla的Lin Clark撰寫的圖文并茂的文章。本文在此不再贅述。

Wasm通常與JavaScript一起運(yùn)行在瀏覽器中，但Shopify采取了不同的方式，在瀏覽器外運(yùn)行Wasm，不使用JavaScript。作為一種高性能語言，Wasm絕不是JavaScript的簡(jiǎn)單替代品:它是為Web和非Web嵌入而設(shè)計(jì)的，解決了瀏覽器和代碼執(zhí)行引擎中廣泛存在的一個(gè)難題，即如何在不可信環(huán)境中高效執(zhí)行程序。Wasm滿足我們的三個(gè)主要技術(shù)要求:安全性、性能和靈活性。

安全

運(yùn)行不受信任的代碼非常危險(xiǎn)。本質(zhì)上，這些代碼不僅難以預(yù)測(cè)，而且很可能對(duì)整個(gè)Shopify平臺(tái)造成損害。雖然市面上沒有100%安全可靠的應(yīng)用程序，但我們?nèi)匀灰婪栋踩┒?，并在問題發(fā)生后采取措施減輕其影響。

Wasm將代碼執(zhí)行放在基于堆棧的沙盒環(huán)境中，依靠顯式導(dǎo)入與主機(jī)通信。因此，我們不能在Wasm中編寫任何惡意代碼。我們只能使用提供的輸入端口來操作虛擬環(huán)境。Wasm在這方面不同于字節(jié)碼，因?yàn)樽止?jié)碼直接引用它們想要運(yùn)行的計(jì)算機(jī)或操作系統(tǒng)。

Wasm還有許多不同的功能來保護(hù)用戶免受錯(cuò)誤代碼的影響，包括受保護(hù)的調(diào)用堆棧和運(yùn)行時(shí)類型檢查。關(guān)于Wasm安全模型的更多細(xì)節(jié)在WebAssembly.org上提供。

表演

在電子商務(wù)領(lǐng)域，更快的運(yùn)行速度是商家推動(dòng)業(yè)績(jī)?cè)鲩L(zhǎng)的必要武器。如果Shopify提供的功能不能平衡加載時(shí)間和定制價(jià)值，那么這個(gè)功能就根本沒有價(jià)值。

Wasm自己的設(shè)計(jì)充分利用了常見的硬件功能，在各種平臺(tái)上發(fā)揮最接近的原生性能。面向追求最高性能，優(yōu)化瀏覽器執(zhí)行的開發(fā)者群體。因此，無論是現(xiàn)在還是未來，Wasm及其外圍工具在設(shè)計(jì)上都將側(cè)重于性能優(yōu)化。

靈活性

能夠幫助開發(fā)者提高開發(fā)效率的代碼執(zhí)行服務(wù)才是真正有用的服務(wù)。Wasm作為一種字節(jié)碼格式，兼容各種編譯器，為代碼開發(fā)者提供支持多種編程語言的一流開發(fā)體驗(yàn)。這也使我們能夠在不改變底層執(zhí)行模型的情況下提供多語言支持。

基于社區(qū)

Shopyify基本保持了相同的開發(fā)目標(biāo)和設(shè)計(jì)，這為我們選擇Wasm提供了一個(gè)技術(shù)上的理由，但事實(shí)并不僅限于此:我們選擇Wasm不僅關(guān)乎技術(shù)，更關(guān)乎人。如果Wasm生態(tài)系統(tǒng)被忽視了，或者只是奄奄一息，那么我們不會(huì)選擇它。集結(jié)號(hào)社區(qū)充滿活力和創(chuàng)新，潛力無窮。自從加入這個(gè)熱情的社區(qū)后，Shopify受益匪淺。

同樣，我們也在為社區(qū)貢獻(xiàn)自己的力量。通過收集用戶反饋，探索功能缺陷，并為我們使用的開源工具提交代碼貢獻(xiàn)。我們相信這為與WebAssembly社區(qū)建立良好的互利合作關(guān)系奠定了堅(jiān)實(shí)的基礎(chǔ)基礎(chǔ)，我們也期待在未來繼續(xù)為這個(gè)充滿活力的社區(qū)貢獻(xiàn)我們的力量。

代碼執(zhí)行服務(wù)的架構(gòu)

在簡(jiǎn)單介紹了WebAssembly以及我們選擇它的原因之后，接下來就是深入探討我們的運(yùn)行方案了。

我們使用Lucet，一個(gè)最初由Fastly開發(fā)的開源工具。Fastly，一家公司，為大量短命的、不可信的模塊提供了可編程的邊緣云平臺(tái)，使得它們可以在盡可能接近其發(fā)起地的地方執(zhí)行請(qǐng)求。這和我們的合作伙伴提供的代碼是一個(gè)問題，所以我們很自然的選擇了Lucet。

朗訊

Lucet是Wasm的運(yùn)行時(shí)和編譯器。Wasm中的模塊保證了系統(tǒng)的安全性。因?yàn)槲覀儾荒茉赪asm中編寫惡意代碼，所以Lucet利用Wasm模塊的驗(yàn)證來檢查安全性。驗(yàn)證后，模塊會(huì)被編譯成可執(zhí)行文件，性能可以達(dá)到原生狀態(tài)。此外，Wasm還支持預(yù)編譯，可以避免運(yùn)行時(shí)編譯帶來的延遲。Lucet container在啟動(dòng)時(shí)不需要做任何事情，這使得它的啟動(dòng)時(shí)間達(dá)到了驚人的35μs。如果你對(duì)Lucet及其工作原理感興趣，可以查看Fastly的CTO泰勒·麥克馬倫的視頻。

Shopify Wasm發(fā)動(dòng)機(jī)工作原理流程圖

我們將Lucet包裝在一個(gè)管理I/O和模塊存儲(chǔ)的Rust Web服務(wù)中，并稱之為Wasm engine。運(yùn)行時(shí)，Shopify通過Web請(qǐng)求調(diào)用Wasm引擎來處理一些功能。之后，引擎在站點(diǎn)的上下文中調(diào)用應(yīng)用程序輸出，其中上下文可能涉及創(chuàng)建折扣、執(zhí)行約束或同步任何商家希望在平臺(tái)中進(jìn)行個(gè)性化定制的服務(wù)。

行駛性能

下圖顯示了從我們最新的性能測(cè)試中提取的一些指標(biāo)。我們選擇了一個(gè)小函數(shù)和逆行測(cè)試:讓模塊限制添加到購(gòu)物車的商品數(shù)量。測(cè)試過程中，每分鐘執(zhí)行10萬個(gè)模塊，時(shí)長(zhǎng)約5分鐘。

模塊執(zhí)行所需的時(shí)間

此圖表顯示了執(zhí)行模塊所需時(shí)間的詳細(xì)信息，包括容器的I/O和模塊的執(zhí)行。y軸代表時(shí)間(單位:ms)，x軸代表測(cè)試運(yùn)行的具體時(shí)間。

圖中淺紫色的圖例表示在Lucet中執(zhí)行模塊所需的時(shí)間，其寬度徘徊在100μs左右，其余圖標(biāo)是I/O處理和引擎的細(xì)節(jié)?？梢钥闯?，總執(zhí)行時(shí)間約為4 ms。所有時(shí)間顯示都是第99個(gè)百分比(99p)。為了更好的理解圖中時(shí)間的含義，我們來對(duì)比一下Shopify中優(yōu)秀的在線商店渲染服務(wù)Storefront Renderer的測(cè)試請(qǐng)求時(shí)間。

店面渲染器響應(yīng)時(shí)間

此圖表顯示了一段時(shí)間內(nèi)店面呈現(xiàn)器的請(qǐng)求時(shí)間。y軸表示請(qǐng)求時(shí)間(單位:秒)，x軸表示返回值的具體時(shí)間。淺藍(lán)色線代表大約700毫秒的第99個(gè)百分比。

如果粗略估計(jì)模塊處理時(shí)間在5毫秒以內(nèi)，可以說Lucet執(zhí)行時(shí)間的性能影響幾乎可以忽略不計(jì)。

生成WebAssembly

為了讓我們優(yōu)秀的執(zhí)行引擎發(fā)揮作用，我們還需要授權(quán)開發(fā)者創(chuàng)建兼容的Wasm模塊。Wasm的作用不是讓用戶自己寫代碼(如果他們?cè)敢猓?dāng)然可以寫)，而是作為編譯目標(biāo)存在。這讓我們思考以下問題:我們支持哪些編程語言，支持到什么程度。

理論上，Wasm支持的任何開發(fā)語言都是可能的。然而，我們更希望開發(fā)者能夠?qū)Ｗ⒂跒槠髽I(yè)解決問題，而不是研究如何符合我們的API。這就是為什么我們選擇單一語言Ruby支持，并為開發(fā)人員提供快速入門工具。但是，由于Ruby動(dòng)態(tài)語言的特性，我們不能直接將其編譯成Wasm，涉及編譯解釋器的解決方案會(huì)有嚴(yán)重的性能損失。正因?yàn)槿绱?，我們最終決定采用靜態(tài)編譯的語言，并把動(dòng)態(tài)語言編譯的可能性留給了未來。

通過我們的研究發(fā)現(xiàn)，Shopify生態(tài)系統(tǒng)中的大多數(shù)開發(fā)者都能熟練應(yīng)用JavaScript。不幸的是，JavaScript和Ruby一樣，是一種動(dòng)態(tài)語言，所以不得不排除。最后，我們選擇了一種語法類似于TypeScript的開發(fā)語言:AssemblyScript。

使用匯編腳本

盡管WebAssembly支持大量的開發(fā)語言，但有兩種主要類型的編譯器我們不能使用:

生成環(huán)境或開發(fā)語言的特定產(chǎn)品的編譯器，即節(jié)點(diǎn)或?yàn)g覽器。(例如Asterius、Blazor)

僅適用于特定運(yùn)行時(shí)的編譯器。這些編譯器生成的模塊依賴于特定語言的特定導(dǎo)入，通常是為了支持某些特定語言的標(biāo)準(zhǔn)庫而存在的，這樣它們就可以在系統(tǒng)調(diào)用或運(yùn)行時(shí)擁有可用的函數(shù)。因?yàn)槲覀儾幌氡绘i定在某個(gè)特定的語言中，所以這種編譯器不在我們的考慮范圍之內(nèi)。(例如流明)

這些強(qiáng)大的編譯器在其他情況下可能會(huì)創(chuàng)造奇跡，但不幸的是它們不能被我們使用。我們需要可以生成WebAssembly的工具，而不是WebAssembly支持的工具。腳本是我們選擇的工具。

與WebAssembly中的其他工具一樣，AssemblyScript仍在開發(fā)中。它缺少一些關(guān)鍵功能，比如閉包支持，在邊緣情況下仍然會(huì)報(bào)告錯(cuò)誤。這時(shí)，社區(qū)的重要性就顯現(xiàn)出來了。

開發(fā)語言AssemblyScript及其外圍工具擁有活躍用戶的愛好者和維護(hù)者社區(qū)，他們自2019年Shopify首次使用AssemblyScript以來一直支持我們。而且我們還通過OpenCollective長(zhǎng)期貢獻(xiàn)代碼支持社區(qū)。我們已經(jīng)編寫了一個(gè)語言服務(wù)器，在實(shí)現(xiàn)閉包方面取得了一些進(jìn)展，并為編譯器和外圍工具提供了錯(cuò)誤修復(fù)。

我們還將AssemblyScript整合到我們的早期工具中。在Shopify CLI中，我們?cè)试S開發(fā)人員通過命令行集成AssemblyScript來創(chuàng)建、測(cè)試和部署模塊。為了提高開發(fā)效率，我們提供了一個(gè)SDK，可以處理Shopify定義對(duì)象(比如“錢”)的底層實(shí)現(xiàn)。除了這些工具之外，我們還建立了一個(gè)允許合作伙伴監(jiān)控模塊的系統(tǒng)，以便他們可以在模塊出現(xiàn)故障時(shí)收到警報(bào)。我們的最終目標(biāo)是讓合作伙伴能夠?qū)⑺麄兊拇a遷移到我們的平臺(tái)上，而不會(huì)失去代碼在原始平臺(tái)上的靈活性和可觀察性。

特別聲明：以上文章內(nèi)容僅代表作者本人觀點(diǎn)，不代表ESG跨境電商觀點(diǎn)或立場(chǎng)。如有關(guān)于作品內(nèi)容、版權(quán)或其它問題請(qǐng)于作品發(fā)表后的30日內(nèi)與ESG跨境電商聯(lián)系。