WebAssembly за пределами браузера: serverless, edge, IoT

WebAssembly создавался как формат для ускорения вычислений в браузере, но за восемь лет с момента выпуска MVP-спецификации вышел далеко за изначальные рамки. Сегодня Wasm работает на серверах, в edge-сетях, внутри плагинов системного ПО, на IoT-устройствах, в базах данных и даже как замена контейнеров в облачных платформах.

Универсальный байт-код с песочницей, портативностью и предсказуемой производительностью оказался полезен далеко за пределами браузерных задач. Сценарии extra-browser Wasm стали отдельным направлением со своими спецификациями (WASI, Component Model), своими runtime’ами (Wasmtime, Wasmer, WAMR) и своей экосистемой инструментов. Разработчику инфраструктуры стоит понимать эти возможности — они меняют подход к развёртыванию и архитектуре распределённых систем.

Что такое WebAssembly

WebAssembly — это бинарный формат байт-кода для виртуальной машины со стек-ориентированной архитектурой. Wasm-модуль содержит компилированный код, спроектированный для быстрого парсинга и валидации перед выполнением. Виртуальная машина выполняет байт-код в изолированной песочнице, не имея доступа к ресурсам системы без явного разрешения от хоста.

Формат разработан W3C при участии Mozilla, Google, Microsoft, Apple. MVP-спецификация утверждена в 2017 году. С тех пор стандарт развивается: добавлены SIMD, потоки, ссылочные типы, exception handling, garbage collection, многозначные возвраты. Свежие версии runtime поддерживают спецификацию 2.0 и работают над components.

Принципы дизайна Wasm

• Безопасность через песочницу: модуль не может читать память хоста или вызывать системные функции без явного импорта
• Портативность: один и тот же модуль работает на x86, ARM, RISC-V, в Linux, Windows, macOS
• Производительность: предсказуемая скорость близкая к нативной, минимальные накладные расходы на запуск
• Языковая нейтральность: компилируется из Rust, C, C++, Go, AssemblyScript, Swift и десятков других языков
• Открытый стандарт: спецификация открыта, runtime’ы свободно реализуются

WASI — системный интерфейс для Wasm

В браузере Wasm работает через JavaScript API, получая доступ к DOM и Web API через хост. Вне браузера нужен другой механизм взаимодействия с системой: файлы, сеть, переменные окружения, время. Эту роль выполняет WASI — WebAssembly System Interface.

WASI разработан как POSIX-подобный интерфейс с фокусом на безопасность через capability-based модель. Модуль не получает доступ к файловой системе целиком — хост передаёт ему конкретные открытые директории или файловые дескрипторы. Это позволяет запускать недоверенный код с гарантированным ограничением возможностей.

WASI Preview 1 и Preview 2

Текущая стабильная версия — WASI Preview 1 — поддерживает базовые операции с файлами, сокетами, временем, случайными числами. Preview 2, основанный на Component Model, расширяет возможности и стандартизирует более сложные сценарии: HTTP-серверы, базы данных, асинхронные операции.

Component Model — модульность для Wasm

Изначально Wasm-модули общались через примитивные типы: числа и указатели в линейной памяти. Это затрудняло композицию модулей на разных языках — разные представления строк, структур, объектов несовместимы. Component Model вводит высокоуровневую систему типов (records, variants, lists, strings) и WIT — Wasm Interface Type для описания интерфейсов модулей.

Компонент Wasm — это переносимая единица, описанная WIT-интерфейсом. Модули на Rust и JavaScript могут общаться без знания друг друга, через стандартизированные интерфейсы. Это превращает Wasm в практический фундамент для plugin-архитектур и микросервисов.

Wasm в serverless и облаке

Запуск Wasm-функций в облаке — одно из самых развитых extra-browser направлений. Wasm выигрывает у контейнеров по нескольким параметрам: время холодного старта в милисекунды против секунд, размер артефакта в килобайты против десятков мегабайт, плотность размещения на ноде в тысячи модулей против десятков контейнеров.

Платформы Wasm-serverless

• Cloudflare Workers — запуск Wasm-функций на edge во всех точках присутствия Cloudflare, более 300 локаций. Cold start менее миллисекунды
• Fastly Compute@Edge — компиляция Rust, JavaScript, Go в Wasm для выполнения на edge Fastly
• Fermyon Spin — платформа для разработки и запуска Wasm-приложений с моделью аналогичной FaaS
• wasmCloud — распределённая платформа для Wasm-компонентов с автоматической миграцией и масштабированием
• Cosmonic — managed wasmCloud, коммерческое решение для enterprise-разработки

Преимущества Wasm для serverless

Wasm на edge

Edge-вычисления получили от Wasm идеальный runtime: быстрый запуск, малый размер, безопасная изоляция, мультиплексирование тысяч запросов на одной ноде. CDN-провайдеры активно развивают эту модель, превращая точки присутствия в распределённые вычислительные сети.

Сценарии Wasm на edge:

• A/B-тесты и feature flags с принятием решения близко к пользователю
• Авторизация и проверка JWT-токенов без обращения к origin
• Image optimization: resize, format conversion на лету
• Персонализация контента по геолокации, языку, типу устройства
• Защита от ботов и rate limiting
• Реверс-прокси с кастомной логикой маршрутизации

Wasm как plugin-runtime

Расширяемость через плагины — типовая задача системного ПО. Традиционные подходы (динамические библиотеки, embedded скриптовые языки) имеют ограничения: библиотеки небезопасны, скриптовые языки медленны. Wasm закрывает обе проблемы: песочница даёт безопасность, JIT-компиляция — производительность.

Реальные применения

• Envoy Proxy — поддержка Wasm-фильтров для расширения логики маршрутизации, аутентификации, трансформации трафика. Используется в Istio
• OpenPolicy Agent (OPA) — компиляция Rego-политик в Wasm для встраивания в любое приложение
• Vercel Edge Middleware — Wasm для запуска middleware на edge без оверхеда контейнеров
• Notion blocks — экспериментальное расширение блочной системы через Wasm-плагины
• Shopify Functions — кастомизация поведения checkout, скидок, доставки через Wasm-функции
• Figma plugins — некоторые плагины используют Wasm для тяжёлых вычислений

Wasm в базах данных

Базы данных давно поддерживают пользовательские функции (UDF) на встроенных языках или динамических библиотеках. Wasm даёт альтернативу: универсальный формат UDF, безопасно работающий в песочнице.

• SQLite WASM — компиляция SQLite в Wasm для запуска в браузере и edge-окружениях
• TiDB — экспериментальная поддержка Wasm UDF
• Cloudflare D1 — SQLite-based база данных на edge с Wasm-функциями
• DuckDB — встраиваемая аналитическая БД с поддержкой Wasm-расширений
• Postgres WASM — экспериментальные проекты компиляции PostgreSQL в Wasm

Wasm на IoT и embedded

Embedded-разработчики получили от Wasm способ обновлять прошивку устройств без полной перепрошивки. Бизнес-логика упаковывается в Wasm-модуль и выкатывается отдельно от системного ПО. Это резко ускоряет цикл обновлений и снижает риск bricking устройства.

Runtime’ы для embedded

• WAMR (WebAssembly Micro Runtime) от Bytecode Alliance — оптимизирован под устройства с ограниченными ресурсами, от единиц килобайт RAM
• Wasm3 — interpreter с минимальным footprint, работает на микроконтроллерах
• wasmer-light — облегчённая версия Wasmer для встраивания

WAMR может работать на устройствах с 64 КБ RAM — это уровень дешёвых микроконтроллеров вроде ESP32. Промышленные применения: умные счётчики, медицинские устройства, автомобильная электроника, носимая электроника.

Сравнение с альтернативами

Языки, компилирующиеся в Wasm

Поддержка компиляции в Wasm есть у большинства современных языков, но качество и удобство различаются. Условно языки делятся на три категории.

First-class поддержка

• Rust — официально поддерживает Wasm как target, отличный tooling (wasm-pack, cargo-wasi), минимальный runtime overhead
• C/C++ — компиляция через Emscripten и Clang, ручное управление памятью без garbage collector
• AssemblyScript — субсет TypeScript, компилирующийся в Wasm; знакомый синтаксис плюс предсказуемая производительность
• Zig — современная альтернатива C с отличной Wasm-поддержкой

Хорошая поддержка

• Go — Wasm-target в стандартном компиляторе, но runtime крупный из-за goroutines и GC. TinyGo даёт меньший бинарь
• Swift — поддержка через SwiftWasm
• Kotlin — Wasm-target в Kotlin Multiplatform
• .NET — Blazor компилирует .NET в Wasm

Развивающаяся поддержка

• Python — Pyodide компилирует CPython в Wasm, но артефакт большой
• Ruby — ruby.wasm экспериментален
• PHP — wasm-php в разработке
• Java — TeaVM компилирует Java-байткод в Wasm

Runtime’ы вне браузера

Ограничения Wasm

Технология не закрывает все сценарии и имеет существенные ограничения.

Производительность не равна нативной

Wasm обычно работает на 10–30% медленнее нативного кода. JIT-компиляция, проверки границ памяти, ограниченный доступ к SIMD-инструкциям дают этот разрыв. Для большинства задач это приемлемо, но в hot-path вычислений (числодробилки, криптография, графика) разрыв заметен.

Многопоточность ограничена

Шаредная память между потоками поддерживается с расширением threads, но требует SharedArrayBuffer и работает не во всех окружениях. Полноценные high-level потоки доступны через WASI-threads, но эта спецификация молодая. Goroutines и async-runtime в Wasm пока неэффективны.

Linear memory как ограничение

Wasm работает с одной линейной памятью адресуемой 32-битно (4 ГБ максимум). 64-битная адресация в стандарте wasm64 уже принята, но runtime’ы только начинают её поддерживать. Для большинства задач 4 ГБ хватает, но для in-memory баз данных или большой аналитики это ограничение существенно.

Доступ к ОС через WASI

Не вся функциональность POSIX доступна через WASI: процессы, IPC, продвинутая работа с сетью, многие системные вызовы. Это снижает применимость для задач, требующих глубокой интеграции с системой.

Языковая зрелость

Для Rust и C компиляция в Wasm — first-class сценарий. Для других языков работа с памятью, FFI, runtime’ом требует больше усилий и часто даёт большие бинари.

Wasm не заменяет контейнеры или нативный код — он занимает свою нишу там, где важны быстрый старт, безопасная изоляция и портативность. Использовать его повсеместно — ошибка такая же, как игнорировать его возможности.

Bytecode Alliance и стандартизация

Bytecode Alliance — некоммерческий консорциум, координирующий развитие Wasm и WASI вне браузера. Основан в 2019 году Mozilla, Fastly, Intel, Red Hat. К 2024 году в альянс входят также Microsoft, Google, Cosmonic, Fermyon, ARM. Альянс развивает Wasmtime, WAMR, эталонные реализации WASI и Component Model, обеспечивая консистентность экосистемы.

Перспективы развития

Несколько направлений активно развиваются и определят применимость Wasm в ближайшие годы:

1. Component Model — переход от изолированных модулей к компонуемой системе с типами на интерфейсах
2. WASI Preview 2 и далее — стандартизация HTTP, БД, асинхронных операций, ML inference
3. Garbage collection — встроенный GC в Wasm для эффективной поддержки языков с управляемой памятью (Java, .NET, Kotlin)
4. Exception handling — нативная поддержка исключений, упрощающая компиляцию языков с try-catch семантикой
5. Wasm-AI — стандартизация ML inference через WASI-NN, переносимые модели между runtime’ами

Практические сценарии для команды

Где Wasm уже сегодня имеет смысл рассматривать в коммерческих проектах:

• Plugin-система для собственного продукта: безопасное выполнение пользовательского кода
• Edge-логика на CDN: минимизация задержек, разгрузка origin-сервера
• Sandboxing недоверенного кода: ML-моделей, пользовательских формул, шаблонов
• Кросс-платформенная бизнес-логика: одна реализация работает в браузере, на сервере, на мобильных устройствах
• Облегчённые FaaS-функции: дешевле и быстрее контейнерных аналогов
• Расширения для системного ПО: фильтры прокси, политики безопасности, форматеры данных

Часто задаваемые вопросы

Заменит ли Wasm Docker

В целевой нише — лёгкие функции, быстрый старт, безопасная песочница — Wasm уже теснит контейнеры. В общем случае — нет: контейнеры остаются стандартом упаковки сложных stateful-приложений с зависимостями ОС. Скорее всего, эти технологии будут сосуществовать: Wasm для edge и serverless, контейнеры для основных рабочих нагрузок.

Можно ли скомпилировать существующий код в Wasm

Зависит от языка и кода. Rust и C/C++ обычно компилируются без серьёзных правок. Go, .NET, Java потребуют адаптации runtime. Код, использующий специфические системные вызовы или GUI-библиотеки, потребует существенной переработки. Простые библиотеки переносятся легко, монолитные приложения с глубокой системной интеграцией — сложно.

Чем Wasm безопаснее обычного кода

Песочница изолирует модуль от хоста: нельзя читать память за пределами своего линейного пространства, нельзя вызывать системные функции без импорта от хоста, нельзя обращаться к произвольным адресам. Это резко снижает поверхность атак для запуска недоверенного кода. Полностью безопасным Wasm не делает — уязвимости в самом коде модуля (логические ошибки, утечки данных) остаются возможны.

Как отлаживать Wasm-код

Базовая отладка возможна через DWARF debug info — поддерживается в Chrome DevTools, VSCode. Логирование работает через хост-импорты. Профилирование сложнее: профайлеры пока менее зрелые, чем для нативного кода. Современная практика — разрабатывать локально как обычное приложение, в Wasm компилировать для финальной сборки.

Где смотреть актуальное состояние спецификаций

Основные источники — webassembly.org, репозитории WebAssembly Working Group на GitHub, документация Bytecode Alliance. Спецификации развиваются активно, читать новости стоит хотя бы раз в квартал. Книги быстро устаревают, лучше следить за блогами разработчиков runtime’ов.

Подходит ли Wasm для машинного обучения

Для inference — да, особенно на edge. ONNX Runtime поддерживает Wasm, WASI-NN стандартизирует API для ML-нагрузок. Производительность обычно ниже нативной CUDA или специализированных ускорителей, но достаточна для запуска моделей средней сложности на CPU. Для обучения Wasm не используется — слишком велик performance gap.

Заключение

WebAssembly давно перерос изначальную задачу ускорения веба. Сегодня Wasm работает на серверах, в edge-сетях, как plugin-runtime, в IoT-устройствах, базах данных и облачных платформах. Преимущества — быстрый старт, малый размер, безопасная песочница, портативность между архитектурами — закрывают целые классы задач, для которых контейнеры и нативный код избыточны.

Технология остаётся развивающейся. Component Model, WASI Preview 2, GC и exception handling появятся в стабильных формах в ближайшие годы, что расширит применимость для языков с управляемой памятью. Уже сейчас Wasm пригоден для конкретных сценариев — edge-вычислений, plugin-систем, sandbox-исполнения, edge-AI. Архитектору инфраструктуры стоит включить Wasm в свой инструментарий и применять там, где он даёт явное преимущество над альтернативами.