WebAssembly不會取代Docker

語言: CN / TW / HK

時間 2022-08-10 14:05:32

最近有很多關於WebAssembly最終是否會取代Docker的討論。而討論的核心，往往集中在容器具備哪些優勢特性，比如可移植性、資源節約或者其他屬性之類的。按照支持者們的吹捧，容器終有一天會徹底取代虛擬機器，但至少在當下，容器還沒那牛到那個程度。

Fermyon Technologies公司CEO Matt Butcher告訴The New Stack，“遙想2014年，當容器第一次引起人們注意時，所有的討論都是關於容器能否取代虛擬機器。但經過多年實踐，我們意識這兩種技術其實是相互補充、而非相互替代。 ”

雖然關於Docker和Wasm如何互補的討論也不少，但這種互補性恐怕不會非常普遍。相反，Docker似乎會堅守住分散式應用這一核心據點，而Wasm則繼續攻城掠地、開拓更多新鮮用例，特別是在那些能讓Wasm發揮安全優勢的特定/極端應用場景之下。

— 1 —

應用交集

Butcher解釋道，“如果畫一張功能維恩圖，那容器和WebAssembly肯定會有交集。在未來幾年裡，行業會逐漸摸索出如何處理其中一部分交集。但我個人認為，這些交集並不算太大，而其餘非交集部分將揭示出這兩種技術的協同發展方向。”

Docker產品負責人Jake Levirne則在採訪郵件中表示，目前的交集用例已經不算少了，但他堅持認為重點根本就不在於Wasm能否有朝一日取代Docker容器，二者融合才是大勢所趨。

在Levirne看來，基於Docker的開發、測試和部署工具鏈之所以大受歡迎，依靠的就是輕鬆、易維護、可重現的應用程式交付管道，且不受具體應用程式架構的影響。他解釋道，“如今我們已經面對數百萬個預構建Docker映象，其中包括數千個官方/經過驗證的映象，足以作為資料儲存、快取、搜尋和框架等核心服務主幹，與Wasm模組配合使用。而隨著時間推移，容器執行時和登錄檔也將擴充套件並納入對原生Wasm模組的支援。實際上，這一切目前正在悄然發生。”

— 2 —

優勢與不足

跟Docker容器一樣，Wasm在誕生之初就擁有著確切且自適應的計算結構。它能夠適應多種不同程式語言，除了常見的HTML和CSS之外，它還能將JavaScript（JS）、C++和Rust整合至單一執行時平臺之內，並以二進位制格式執行函式。

Wasm既可用於支援Web應用程式，也能擴充套件至CPU上執行的各類邊緣環境/雲原生平臺，包括服務網格和邊緣Kubernetes等場景。另外，Wasm的歷史也不算短了，並於2019年被全球資訊網聯盟（W3C）指定為Web標準，成為繼HTML、CSS和JavaScript之後的第四項Web標準。

而之所以目前的競爭用例間還沒出現大量交集，主要是因為Docker容器，特別是容器自身的結構和功能特性。也正是憑藉這些特性，讓Docker和容器成了DevOps領域的寵兒。如今，除了容器和Wasm之外，市面上還存在裸機、虛擬機器、函式即服務（FaaS）等多種不同應用計算架構，未來肯定還會出現更多。

在Levirne看來，這意味著“開發者在選擇程式碼執行方式時，將繼續擁有更大的靈活性。容器的優勢在於提供豐富的應用執行能力，允許這些應用程式隨意使用當前Linux提供的全部開源和商業庫、包及工具，同時又提供了相對輕量化的隔離機制。相比之下，Wasm的隔離方法更輕量化，但卻只適用於特定一部分純新建應用程式。換句話說，這些應用程式無法依賴以往無數開源專案的既有成果。 ”

容器技術在這兩大應用場景中勢頭仍然強勁，“相信這種優勢至少還能再持續幾年。”在Butcher看來，“原因有二：首先，容器仍是對現有應用程式不加修改、直接打包的最佳選項。換言之，任何現有應用程式都能輕鬆進行打包、分發並以容器形式執行。其次，資料庫和持久資料儲存天然跟容器更對路。 PostgreSQL、MongoDB和Redis等資料服務用例都更適應傳統伺服器模型，即一個程序啟動完成後，會一口氣執行數天、數月甚至數年，期間絕不中斷。在這兩點上，我認為WebAssembly在很長一段時間內還發揮不出自己的獨特優勢，所以不可能成功壓倒Docker。”

但另一方面，Wasm也不乏證明自身價值的舞臺。 Wasm的價值核心在於面向二進位制結構，因此可以直接在CPU層次上執行，並消除容器映象內包含程式碼缺陷等潛在風險。

Adobe公司高階軟體工程師Colin Murphy在採訪中表示，Wasm代表的正是“人們所說的「業務邏輯」，即用應用程式碼直接構建Web服務產品”。以Adobe為例，他們使用Wasm和WASI幫助使用者在Adobe Sign中籤署文件，並在Lightroom中編輯影象。但在除此以外的其他場景下，Docker“仍將主宰一切”，例如資料庫、代理和只執行NGINX/Apache的Web伺服器等。

Murphy還強調，“ 具體來講，任何與WASI基於能力的安全模型相沖突的事物，都還是得由Docker來處理。另外，受到安全模型或其他因素的限制，很多遺留應用程式無法被輕鬆移植至Wasm。 ”

SingleStore公司首席軟體工程師Bailey Hayes表示，使用使用者程式碼擴充套件系統的方法多種多樣，Wasm的獨到之處在於提供一種可移植且安全可靠的沙箱，能夠以接近原生的速度在程序內執行。

Hayes解釋道，“對資料庫而言，只有迴避其他解決方案的缺點，例如資料重複、網路通訊或程序間通訊，才能真正實現高效能。正因為如此，我們才選擇Wasm來支援SingleStoreDB中的程式碼引擎。”

另外，安全性也是Wasm的一大主要賣點。Murphy表示，“ 與Docker相比，Wasm的優勢主要體現在安全性、效能、模組化和大小。而且即使是在允許的範圍內，Wasm的要求也更嚴格一些。 ”

Murphy解釋道，與Docker不同，“我們不能在Wasm上簡單構建一個巨型應用程式，把它複製到容器裡再直接丟掉生產環境執行。這麼幹也有好處，比如在執行一個堆大小達128 GB的JVM時，這樣能防止效率下降。但同時，這樣會大大提升應用程式的移植難度。畢竟Wasm本身就是一種語言，雖然很多語言都能被編譯為Wasm，但最終會受到Wasm正規化的約束。事實證明，已經針對容器化完成了優化，或者說最沒必要移植的應用，反而是最易於移植的。而大部分不符合容器原則的應用程式反正處處受限、難以編譯。”

— 3 —

展望未來

前文已經提到，Docker容器和Wasm將各自孕育出能充分發揮其特徵與優勢的獨特用例。如果容器真能在幾分鐘內解決需求，沒人會閒到嘗試用Wasm工具來啟動Kubernetes叢集。

Cosmonic公司聯合創始人兼CEO Liam Randall認為，隨著“人們越來越多為自己的企業或業餘專案編寫應用程式和業務邏輯，未來Wasm的生命力將會愈發旺盛並得到廣泛認可。 Wasm更小、能夠真正跨平臺開發且輕量化程度更高，足以執行在我們在任意位置指定的任意裝置之上。而體量更大、成熟度更高的工具則可能會繼續以二進位制檔案或者容器的形式執行——比如說Nginx、Postgres以及Redis，至少從短期來看，把這些東西編譯成Wasm似乎也不會產生什麼特別的回報。而且對於那些需要針對資料庫之類的東西編寫應用程式的人來說，容器仍然是種很好的開發工具。 Docker加Postgres的組合將在可預見的未來，繼續給開發者們帶來出色的體驗。所以我估計在短期內，Wasm將主要負責應用程式構建，而容器則負責承載各類工具和軟體。”