WebAssembly بالغ شد: WASI 0.2، مدل کامپوننت و WASM سمت سرور در محیط تولید

WebAssembly در آغاز راهی بود برای اجرای C++ در مرورگرها، سریعتر از JavaScript. تا سال ۲۰۲۶، این کمجذابترین ویژگی آن محسوب میشود. WASI 0.2، مدل کامپوننت و اکوسیستم رو به رشدی از runtimeهای سمت سرور، WASM را به یک هدف محاسباتی چندمنظوره و معتبر تبدیل کردهاند — زبانمستقل، پیشفرض ایزوله و آغازگر چالش با استقرار مبتنی بر کانتینر در محاسبات لبه.

WASI 0.2 دقیقاً چه چیزی را تغییر داد

رابط سیستمی WebAssembly (WASI) مشخصاتی است که به ماژولهای WASM اجازه میدهد با دنیای بیرون تعامل داشته باشند — سیستمهای فایل، سوکتهای شبکه، ساعتها و تولید اعداد تصادفی. پیش از WASI، نسخه مرورگری WASM قادر به محاسبات بود اما نمیتوانست با سیستمعامل ارتباط برقرار کند. WASI همان چیزی است که WebAssembly سمت سرور را ممکن میسازد.

نسخه WASI 0.2 که در فوریه ۲۰۲۴ توسط Bytecode Alliance نهایی شد، دو تغییر بنیادین را معرفی کرد. نخست، مدل کامپوننت را استانداردسازی کرد — مدلی که تعیین میکند ماژولهای WASM چگونه رابطهای نوعدار را با استفاده از WIT (WebAssembly Interface Types) ارائه دهند و با یکدیگر ترکیب شوند. دوم، wasi:http را معرفی کرد، یک رابط HTTP استاندارد که به برنامههای WASM امکان پردازش درخواستهای وب را بدون نیاز به لایههای سازگارکننده مختص هر سکو میدهد.

اثر عملی آن این است: یک کامپوننت WASM نوشتهشده به زبان Rust، Go، Python یا C اکنون میتواند یک رابط نوعدار ارائه دهد که کامپوننتی دیگر — که احتمالاً به زبانی کاملاً متفاوت نوشته شده — قادر به فراخوانی آن باشد. تعاملپذیری بین زبانها بدون پیچیدگیهای FFI.

مدل کامپوننت: ماژولهایی که با هم ترکیب میشوند

پیش از مدل کامپوننت، تنها نوعی که از مرز ماژول در WebAssembly عبور میکرد، بایتهای خام (حافظه خطی) بودند. فراخوانی یک ماژول WASM نوشتهشده به Rust از یک ماژول WASM نوشتهشده به Python نیازمند serialسازی سفارشی در هر دو سمت بود. مدل کامپوننت یک سیستم نوع غنیتر را در مرز ماژول معرفی میکند — رشتهها، فهرستها، رکوردها و variantها — که در فایلهای رابط WIT تعریف میشوند.

این امر WASM چندزبانه را عملی میسازد. یک خط پردازش داده ممکن است از یک کامپوننت Rust برای تجزیه (به دلیل عملکرد)، یک کامپوننت Python برای استنتاج ML (به دلیل سازگاری با اکوسیستم) و یک کامپوننت JavaScript برای تبدیل JSON (به دلیل کتابخانههای موجود) استفاده کند، که همگی در یک برنامه واحد WASM با تبادلهای نوعدار میان آنها ترکیب شدهاند. ابزارهای خط فرمان wasm-tools compose و زنجیره ابزار cargo component ابزارهای فعلی در دسترس توسعهدهندگان هستند. اکوسیستم هنوز در مراحل اولیه است اما کاربردی — و runtimeهای بزرگ WASM بر سر این مشخصات همسو شدهاند.

Runtimeهای سمت سرور: Wasmtime، WasmEdge، Wasmer

Wasmtime (از Bytecode Alliance) runtime مرجع برای انطباق با WASI است. این پروژه به زبان Rust نوشته شده و از Cranelift برای کامپایل JIT استفاده میکند و اولویت آن انطباق با مشخصات و ایزولهسازی امنیتی است. سکو Compute شرکت Fastly بر پایه Wasmtime اجرا میشود و ترافیک تولیدی را در مقیاس بزرگ پردازش میکند.

WasmEdge (پروژه CNCF) برای استقرارهای ابری و لبه بهینه شده است. این پروژه از طریق containerd-wasm-shims با Kubernetes یکپارچه میشود، از استنتاج LLM مبتنی بر GGML در WASM پشتیبانی میکند و در پروکسی Envoy برای قابلیت توسعهپذیری مبتنی بر افزونه WASM به کار گرفته میشود — یک مورد استفاده تولیدی بزرگ.

Wasmer بر تجربه توسعهدهنده با گستردهترین پشتیبانی از SDKهای زبانی تمرکز دارد: پیوندهایی برای Python، JavaScript، Go، PHP و Ruby. شرکت Wasmer همچنین وبگاه Wasmer.io را اداره میکند، یک رجیستری بستههای WASM که مشابه npm است اما برای توزیع ماژولهای WASM مستقل از سکو.

کجا WASM پیروز میشود

سه الگوی استقرار ظهور کردهاند که در آنها WASM واقعاً از جایگزینها بهتر عمل میکند:

محاسبات لبه: سرویس Cloudflare Workers زبانهای JavaScript و WASM را در بیش از ۳۰۰ مکان لبهای در سراسر جهان اجرا میکند. Fastly Compute مستقیماً WASM را اجرا میکند. مزیت شروع سرد تعیینکننده است — یک ماژول WASM در عرض میکروثانیهها آغاز میشود، در مقابل صدها میلیثانیه برای یک کانتینر. برای توابع لبه حساس به تأخیر، این تفاوت میان یک تأخیر محسوس و عدم تأخیر است.

سیستمهای افزونه: نرمافزارهایی که به قابلیت توسعهپذیری بدون خطر امنیتی افزونههای کد بومی نیاز دارند، WASM را به عنوان میزبان افزونه ایزوله پذیرفتهاند. پروکسی Envoy از WASM برای سیستم توسعهپذیری خود استفاده میکند. Zellij (مولتیپلکسر ترمینال) افزونهها را به صورت WASM اجرا میکند. مدل ایزولهسازی ویژگی کلیدی است: یک افزونه WASM بدون اعطای صریح قابلیتها نمیتواند به حافظه میزبان یا فراخوانیهای سیستمی دسترسی پیدا کند و این اجرای کد افزونه غیرقابل اعتماد را ایمن میسازد.

استنتاج ML در سمت مرورگر: WebLLM مدلهای LLM کوانتیزهشده — Llama 3، Phi-3، Mistral — را در مرورگر از طریق ترکیب WASM با WebGPU برای دسترسی به GPU اجرا میکند. این ترکیب امکان اجرای مدلهای ۳ تا ۷ میلیارد پارامتری را در سمت کاربر بدون نیاز به سرور فراهم میکند و قابلیت آفلاین را ممکن ساخته و ارسال داده به APIهای خارجی را حذف میکند.

کجا WASM هنوز شکست میخورد

WASM در بارهای کاری سرور چندمنظوره پیروز نشده است. یک سرور HTTP نوشتهشده به Go یا Node.js که در کانتینر اجرا میشود، هنوز برای بیشتر موارد استفاده به اندازه کافی سریع آغاز میشود، ابزارهای بالغی دارد و نیازی به پیچیدگی اهداف کامپایل WASM و تعریف رابطهای WIT ندارد. اکوسیستم هنوز در مراحل اولیه است — بیشتر کتابخانهها به WASM منتقل نشدهاند و اشکالزدایی از WASM کامپایلشده به مراتب دشوارتر از اشکالزدایی کد بومی است.

داستان شبکهسازی نیز ناقص است. WASI 0.2 دارای wasi:http است اما هنوز wasi:sockets پایداری برای TCP/UDP دلخواه ارائه نمیدهد. کاربردهایی که نیازمند دسترسی به سوکت خام هستند — پایگاههای داده، پروتکلهای سفارشی، شبکه همتابههمتا — هنوز بهخوبی توسط WASM سمت سرور پشتیبانی نمیشوند.

پشتیبانی زبانی در سال ۲۰۲۶

اکوسیستم زبانی در دو سال گذشته بهطور قابلتوجهی بالغ شده است:

• Rust: پشتیبانی در کلاس برتر. wasm-pack برای اهداف مرورگری، cargo component برای مدل کامپوننت. پشتیبانی کامل از WASI 0.2.
• Go: TinyGo برای WASI (نسخه استاندارد Go دارای پشتیبانی آزمایشی WASM با محدودیتهایی در کتابخانه استاندارد است). TinyGo باینریهای کوچکی تولید میکند اما از تمام قابلیتهای کتابخانه استاندارد Go پشتیبانی نمیکند.
• Python: CPython از طریق Emscripten به WASM کامپایل میشود (Pyodide برای استفاده مرورگری). پروژه py-wasi بهطور مستقیمتر WASM سمت سرور را هدف قرار میدهد.
• JavaScript/TypeScript: SpiderMonkey کامپایلشده به WASM توسط Cloudflare برای اجرای ایزولههای JS بهصورت قابل حمل استفاده میشود. ComponentizeJS زبان JavaScript را به کامپوننتهای WASM تبدیل میکند.
• C/C++: Emscripten همچنان مسیر بالغ باقی مانده است. wasi-sdk یک زنجیره ابزار مینیمالتر با تمرکز بر WASI ارائه میدهد.
• Swift: هدف آزمایشی WASM در نسخه Swift 5.9 اضافه شد و در طول سال ۲۰۲۵ به سرعت در حال بهبود است.

مقایسه با کانتینر

استدلال Bytecode Alliance برای ترجیح WASM بر کانتینر سهبعدی است: مصنوعات کوچکتر (یک ماژول WASM معمولاً در مقیاس کیلوبایت است، نه صدها مگابایت لایههای کانتینر)، شروع سرد سریعتر (میکروثانیهها در مقابل صدها میلیثانیه) و مدل ایزولهسازی قویتر (امنیت مبتنی بر قابلیت WASM در مقابل بردارهای فرار از کانتینر که بهطور منظم در CVEها ظاهر میشوند).

برای سرویسهای طولانیمدت که شروع سرد در آنها اهمیت ندارد و ابزارهای کانتینری موجود دارید، کانتینرها پاسخ درست هستند. برای سرویس بهعنوان تابع، محاسبات لبه و قابلیت توسعهپذیری افزونهها، مدل WASM واقعاً قابلتوجه است — و بهطور فزایندهای، استقرارهای تولیدی این موضوع را اثبات میکنند.

مسیر به سوی WASI 0.3

نسخه WASI 0.3 در حال توسعه فعال است و افزودههای اصلی آن wasi:sockets برای TCP/UDP، پشتیبانی از I/O ناهمگام و رابطهای اضافی برای منابع سیستمی هستند. مشخصات مدل کامپوننت نیز به تکامل خود ادامه میدهد — سیستم نوع و ابزارهای ترکیبسازی هنوز ناهمواریهایی دارند که Bytecode Alliance فعالانه در حال رفع آنهاست.

مسیر روشن است: WASM دیگر یک کنجکاوی مرورگری یا یک پروژه تحقیقاتی نیست. این فناوری در Cloudflare، Fastly و دهها شرکتی که از آن برای سیستمهای افزونه و بارهای کاری لبه استفاده میکنند، در محیط تولید قرار دارد. انحصار runtime JavaScript در مرورگر در سال ۲۰۱۷ با عرضه WASM به پایان رسید. انحصار کانتینر در محاسبات سرور دیواری است که WASM اکنون از آن بالا میرود — و WASI 0.2 کلنگ آن است.