Wasmtime vs Wasmer dla produkcji Edge Functions

WebAssembly od dawna wyznacza format środowiska wykonawczego przeglądarki. Od kilku lat jest również używany do wykonywania kodu w trybie sandbox po stronie serwera lub na brzegu: kod bajtowy skompilowany raz, przenośny na dowolnym komputerze hosta, domyślnie izolowany bez kontenera lub kompletnej maszyny wirtualnej. Wasmtime i Wasmer przenoszą to rozszerzenie z przeglądarki, oba są napisane w języku Rust i oba mogą wykonywać ten sam plik .wasm.

Wasmtime to projekt prowadzony przez Bytecode Alliance, organizację zarządzającą kilkoma komponentami ekosystemu serwerów WebAssembly, w tym kompilatorem Cranelift. Wasmer został opracowany przez Wasmer Inc., firmę, która publikuje środowisko uruchomieniowe jako oprogramowanie typu open source, jednocześnie promując powiązane z nim usługi uzupełniające (wdrażanie brzegowe, oprzyrządowanie). Dwa różne modele zarządzania, brak oceny jakości kodu stworzonego przez jeden lub drugi.

Pozostała część tego artykułu porównuje cztery weryfikowalne obszary, licencjonowanie i zarządzanie, dostępne kompilatory, standard WASI i model komponentów, model bezpieczeństwa, a następnie wyjaśnia, wraz z kodem pomocniczym, dlaczego rdzeń Rust Aurabase uruchamia Wasmtime w jego silniku Edge Functions.

Wasmtime jest wydawany na licencji Apache-2.0 z wyjątkiem LLVM, licencji permisywnej powszechnej w ekosystemie kompilatora. Zarządzanie opiera się na modelu Bytecode Alliance: kilka organizacji uczestniczy w projekcie, ale żadna nie jest jego właścicielem samodzielnie.

Wasmer jest wydawany na licencji MIT, jeszcze bardziej liberalnej na papierze, ale kierownictwo techniczne pozostaje skupione wokół jednego wydawcy, Wasmer Inc. Nie jest to wadą samą w sobie: wiele udanych projektów open source opiera się na tym modelu. To po prostu inny profil ryzyka, jeśli Twoja organizacja ceni rozproszone zarządzanie pomiędzy wieloma podmiotami.

Wasmtime kompiluje się w środowisku produkcyjnym za pośrednictwem Cranelift, generatora kodu, również należącego do Bytecode Alliance. Skrzynka dokumentuje również dodatkowy kompilator Winch, zaprojektowany w celu skrócenia czasu kompilacji w porównaniu do Cranelift w przypadkach wrażliwych na uruchamianie. Cargo.toml funkcji aury aktywuje tylko funkcję cranelift: to ten kompilator i tylko on przetwarza każdy moduł WASM załadowany w środowisku produkcyjnym.

Wasmer podąża odwrotną ścieżką: trzy wymienne backendy. Singlepass kompiluje się w jednym przebiegu, niemal natychmiast, kosztem mniej zoptymalizowanego kodu maszynowego. Cranelift oferuje zrównoważony kompromis. LLVM dąży do uzyskania najlepszej możliwej przepustowości wykonania i najdłuższego czasu kompilacji ze wszystkich trzech. Pojedyncze środowisko wykonawcze, trzy profile kompromisów wybrane podczas konfiguracji.

WASI, interfejs systemu WebAssembly, standaryzuje dostęp do plików, zegarów i sieci z modułu WASM, niezależnie od przeglądarki. Jego najnowsza wersja, WASI Preview 2, opiera się na modelu komponentów: mechanizmie tworzenia modułów napisanych w różnych językach, ze wspólnymi interfejsami typowania, a nie formatem binarnym specyficznym dla każdego środowiska wykonawczego. Zarówno Wasmtime, jak i Wasmer pracują nad wdrożeniem tego standardu, każdy w swoim własnym tempie.

Wasmer dodatkowo dokumentuje WASIX, rozszerzenie, którego celem jest pokrycie prymitywów POSIX, których oficjalny standard WASI jeszcze nie obejmuje, takich jak wątki lub bardziej wszechstronne gniazda sieciowe. Nie jest to standard wspierany przez grupę roboczą WebAssembly, ale rozszerzenie specyficzne dla ekosystemu Wasmer.

Obydwa środowiska wykonawcze izolują każdy moduł we własnej pamięci liniowej, bez bezpośredniego dostępu do systemu hosta poza jawnie zaimportowanymi funkcjami. Na tym opiera się model bezpieczeństwa WebAssembly, wspólny dla obu projektów.

Wasmtime udostępnia także natywny interfejs API nagrań z wykonania, fuel: każda instrukcja zużywa ustalony z góry budżet, a wykonanie zatrzymuje się prawidłowo po wyczerpaniu tego budżetu. Drugie API, przerwanie epoch, umożliwia nałożenie limitu czasu bez blokowania silnika podczas oczekiwania. Wasmer dokumentuje własną mechanikę pomiaru i limitów pamięci na instancje; W tym artykule nie zweryfikowano ich w repozytorium strony trzeciej, więc nie opisano ich szczegółowo.

To jest dokładnie to, co umożliwia usługa aura-functions firmy Aurabase, co opisano szczegółowo w następnej sekcji z rzeczywistym kodem źródłowym.

Usługa aura-functions deklaruje wasmtime jako zależność produkcyjną, bez komentarzy dezaktywacyjnych ani konfiguracji zależności deweloperskiej. Żaden plik w repozytorium, ani plik Cargo.toml, ani .rsnie wspomina o Wasmerze.

# Środowisko wykonawcze WASM
wasmtime = { version = "43", features = ["async", "cranelift"] }

Kod inicjujący jawnie aktywuje paliwo i przerwanie według epoki, a następnie ogranicza pamięć poprzez wywołanie za pomocą StoreLimits:

let mut cfg = Config::new();
cfg.consume_fuel(true);
cfg.epoch_interruption(true);
let engine = Engine::new(&cfg)?;

// przez wywołanie:
let limits = StoreLimitsBuilder::new()
    .memory_size(self.max_memory_mb as usize * 1024 * 1024)
    .build();
store.set_fuel(self.max_fuel)?;
store.epoch_deadline_async_yield_and_update(1);

Wszystkie trzy limity można konfigurować dla każdej zmiennej środowiskowej, przy czym wartości domyślne są zaznaczone w config/mod.rs: WASM_MAX_MEMORY_MB przy 64, WASM_TIMEOUT_SECS przy 10, WASM_MAX_FUEL przy miliardzie jednostek. Limit czasu jest wyzwalany w tle: tokio::spawn czeka przez skonfigurowany czas, a następnie zwiększa epokę silnika, bez blokowania bieżącego wykonania podczas oczekiwania.

ABI udostępniane modułom gościa pozostaje celowo minimalne: cztery funkcje hosta, aura.log, aura.get_input, aura.set_output i aura.get_env, zarejestrowane za pośrednictwem linker.func_wrap. Nie jest to Model Komponentowy ani WASI Preview 2: jest to kontrakt wewnętrzny, węższy, przeznaczony do jednorazowego użytku, wykonujący funkcję brzegową HTTP i odzyskujący odpowiedź JSON.

Ten tryb wasm jest wyborem dla danej funkcji, a nie globalnym przełącznikiem. Omówienie architektury Aurabase zawiera szczegółowe informacje na temat drugiej ścieżki, domyślnego trybu deno, który wykonuje JavaScript/TypeScript w oddzielnej usłudze. Obydwa współistnieją w tej samej usłudze aura-functions.

Źródła: Cargo.toml i wasm/mod.rs z repozytorium Aurabase, zweryfikowane bezpośrednio 24 sierpnia 2026. Ogólna charakterystyka Wasmtime i Wasmer zaczerpnięta z publicznej dokumentacji każdego projektu; w tej tabeli nie publikowano ponownie żadnych danych porównawczych stron trzecich.

Uruchamiasz nowe środowisko wykonawcze brzegowe, bez istniejących zależności. Wasmtime, wspierany przez fundację składającą się z wielu dostawców, zmniejsza ryzyko uzależnienia przyszłości projektu od jednego wydawcy.

Masz bardzo częste i krótkotrwałe zimne starty. Backend Singlepass firmy Wasmer bezpośrednio odpowiada na tę potrzebę, zapewniając niemal natychmiastową kompilację, kosztem mniej zoptymalizowanego kodu maszynowego.

Potrzebujesz prymitywów POSIX wykraczających poza bieżący standard WASI. WASIX, rozszerzenie Wasmer, obejmuje wątki i rozszerzone gniazda, których sam WASI Preview 2 jeszcze nie obejmuje.

Potrzebujesz natywnego API do nagrywania filmów i limitów czasu, bez oprogramowania pośredniczącego innych firm. Wasmtime wystawia fuel i epoch bezpośrednio w skrzyni, dokładnie to, co umożliwia aura-functions w Aurabase.