Component Model در WebAssembly دارد به استاندارد افزونه‌نویسی‌ای تبدیل می‌شود که هیچ‌کس به آن رأی نداده

برای یک دهه، WebAssembly فناوری‌ای بود که همیشه گفته می‌شد «یک سال دیگر» تا اهمیت‌یافتن در بیرون از مرورگر فاصله دارد. آن سال بالاخره فرا رسیده است. بر اساس نظرسنجی سالانه ۲۰۲۶ CNCF، اکنون ۳۸ درصد از سازمان‌های cloud-native بارهای کاری WebAssembly را در محیط تولید اجرا می‌کنند؛ این رقم در سال ۲۰۲۲ تنها ۴ درصد بود. دلیل این رشد یک اپلیکیشن فوق‌العاده خاص نیست. دلیل واقعی این است که Component Model در WebAssembly به آرامی مشکلی را حل کرد که کانتینرها، افزونه‌ها به شکل کتابخانه‌های مشترک، و هر رویکرد sandboxing پیشین هرگز به طور کامل حل نکرده بودند: اجرای امن کد غیرقابل‌اعتماد و چندزبانه، بدون خطرهای حافظهٔ مشترک و بدون سربار سطح کانتینر.

آنچه Component Model واقعاً حل می‌کند

ماژول‌های ساده WebAssembly از قبل می‌توانستند کد نوشته‌شده به هر زبانی را که به WASM کامپایل می‌شود، به‌صورت ایزوله از host اجرا کنند. اما انتقال داده‌های پیچیده بین ماژول‌ها -رشته‌ها، structها، variantها- به مدیریت دستی حافظه در مرز linear memory وب‌اسمبلی نیاز داشت؛ کاری که دقیقاً به همان اندازه که به نظر می‌رسد مستعد خطا بود. Component Model این فرایند را با یک Canonical ABI جایگزین می‌کند: روشی استاندارد برای توصیف و انتقال انواع دادهٔ پیچیده در مرز کامپوننت‌ها، بدون آنکه هیچ‌یک از دو طرف نیاز به دانستن زبان پیاده‌سازی طرف دیگر داشته باشد.

در عمل، این یعنی یک اپلیکیشن host نوشته‌شده به C# می‌تواند یک افزونهٔ نوشته‌شده به Rust را اجرا کند، که خود کامپوننتی نوشته‌شده به Python را فرا می‌خواند، و آن کامپوننت داده را به کامپوننتی نوشته‌شده به Go استریم می‌کند -در حالی‌که هر مرحله از نظر type بررسی‌شده و از نظر حافظه ایزوله است، بدون آنکه هیچ‌یک از این زبان‌ها نیاز به اشتراک‌گذاری runtime یا حتی دانستن زبان پیاده‌سازی بقیه داشته باشند. WIT (زبان WebAssembly Interface Type) شمایی است که این امر را ممکن می‌سازد: یک رابط را فقط یک‌بار تعریف می‌کنید و هر کامپوننتی که آن را پیاده‌سازی کند، صرف‌نظر از زبان مبدأ، با بقیه قابل‌جایگزینی است.

چه کسانی واقعاً این فناوری را در تولید استفاده می‌کنند

این یک کنجکاوی آزمایشگاهی نیست. American Express یک پلتفرم داخلی function-as-a-service بر پایهٔ wasmCloud ساخته و از کامپوننت‌های WASM نگهداری‌شده توسط جامعهٔ متن‌باز برای پشتیبانی از توابع مستقل از توپولوژی در سراسر زیرساخت خود استفاده می‌کند. Akamai شرکت Fermyon (سازندهٔ فریم‌ورک WASM با نام Spin) را تصاحب کرد و Spin را در سراسر شبکهٔ edge خود مستقر کرده است؛ یعنی اکنون کامپوننت‌های WASM، نه کانتینرها، در یکی از بزرگ‌ترین اپراتورهای CDN اینترنت، محاسبات edge را در محیط تولید ارائه می‌دهند. SpinKube، روش native Kubernetes برای اجرای بارهای کاری WASM، امسال به CNCF Sandbox پیوست و مسیر ورود را برای تیم‌هایی که از قبل روی Kubernetes کار می‌کنند و می‌خواهند بدون ساختن یک پشتهٔ زیرساختی موازی، WASM را اضافه کنند، رسمی کرد.

خود wasmCloud به جایگاه incubator در CNCF رسید و نسخهٔ ۲.۵ را با پشتیبانی از WASI Preview 3 به‌صورت پیش‌فرض فعال عرضه کرد؛ نقطه‌عطفی مهم، چون Preview 3 انواع native از جمله Future و Stream را مستقیماً به مشخصات WIT اضافه می‌کند و برای اولین بار امکان I/O ناهم‌زمان و غیرمسدودکننده را در مرز کامپوننت‌ها فراهم می‌سازد. پیش از این، کد ناهم‌زمان در عبور از مرز یک کامپوننت به الگوهای callback دست‌وپاگیر نیاز داشت؛ اما اکنون این قابلیت بخشی درجه‌یک از تعریف رابط است.

چرا سیستم‌های افزونه دقیقاً همان کاربرد برنده هستند

Extism، فریم‌ورکی که مشخصاً برای سیستم‌های افزونه ساخته شده، نشان می‌دهد چرا این الگو در سناریوهای توسعه‌پذیری سریع‌تر از میکروسرویس‌های عمومی در حال گسترش است. اگر در حال ساخت محصولی هستید که باید کد غیرقابل‌اعتماد شخص ثالث را اجرا کند -یک اکوسیستم افزونه برای یک CMS، یک پایپ‌لاین داده با مراحل تبدیل سفارشی، یا لایهٔ اسکریپت‌نویسی یک موتور بازی- به سه چیز به‌طور همزمان نیاز دارید: sandboxing تا یک افزونهٔ ناقص نتواند host را از کار بیندازد یا آلوده کند، انعطاف‌پذیری زبانی تا نویسندگان افزونه به زبان host شما محدود نشوند، و کارایی تقریباً native تا sandbox هزینهٔ سنگینی روی هر فراخوانی نگذارد. کانتینرها sandboxing را فراهم می‌کنند، اما با سربار سطح process که برای فراخوانی‌های ریزدانهٔ افزونه مناسب نیست. زبان‌های اسکریپت‌نویسی جاسازی‌شده (مثل Lua یا JavaScript-in-a-box) کارایی می‌دهند، اما نویسندگان افزونه را به یک زبان محدود می‌کنند. کامپوننت‌های WASM نخستین رویکردی هستند که واقعاً هر سه ویژگی را همزمان ارائه می‌دهند.

محدودیت‌های صادقانه

WASM سمت سرور برای دستهٔ خاصی از بارهای کاری -توابع edge، FaaS و سیستم‌های افزونه- آمادهٔ محیط تولید است، اما هنوز جایگزینی عمومی برای میکروسرویس‌ها نیست. مزیت‌های cold-start نسبت به کانتینرها واقعی‌اند، اما وقتی سربار نمونه‌سازی کامپوننت‌ها در مقیاس بزرگ را در نظر بگیریم، محدودتر از چیزی هستند که بازاریابی‌های اولیه القا می‌کردند. و ابزارها، هرچند به‌طرز چشمگیری بهتر از دو سال پیش شده‌اند، هنوز لبه‌های خام دارند: دیباگ کردن یک زنجیرهٔ کامپوننت چندزبانه دشوارتر از دیباگ یک سرویس تک‌زبانه است، و ابزارهای observability که برای بارهای کاری کانتینری ساخته شده‌اند، همیشه به‌خوبی به این محیط منتقل نمی‌شوند.

واقعاً باید با این موضوع چه کرد

اگر در سال ۲۰۲۶ در حال ساخت هر نوع سیستم افزونه یا extension هستید و همچنان به‌طور پیش‌فرض سراغ زبان‌های اسکریپت‌نویسی جاسازی‌شده یا معماری «یک کانتینر برای هر افزونه» می‌روید، ارزش دارد ابتدا با Component Model پروتوتایپ بسازید -اگر سریع‌ترین مسیر برای ساخت یک host کارآمد برای افزونه‌ها را می‌خواهید با Extism شروع کنید، یا اگر از قبل در بستر Kubernetes یا edge-computing هستید، با wasmCloud یا Spin. اگر سیستم افزونه نمی‌سازید، سیگنال مرتبط‌تر پشتیبانی ناهم‌زمان WASI Preview 3 است: این همان بخشی است که WASM را برای بارهای کاری سنگین از نظر I/O -که پیش‌تر گزینهٔ مناسبی نبودند- باز می‌کند، و ارزش دارد WASM را به‌عنوان گزینه‌ای برای edge computing که پیش‌تر به دلایل کارایی کنار گذاشته بودید، دوباره بررسی کنید.