WebAssembly (Wasm) Ngoài Trình Duyệt

WebAssembly (Wasm) khởi đầu là một cách để mang lại hiệu suất gần như native cho các trình duyệt web. Bằng cách cung cấp định dạng hướng dẫn nhị phân cho một máy ảo dựa trên stack, nó cho phép các nhà phát triển chạy các ngôn ngữ như C, C++, và Rust trên web cùng với JavaScript. Tuy nhiên, tiềm năng thực sự của Wasm còn vượt xa trình duyệt. Trong vài năm qua, WebAssembly đã nổi lên như một thế lực đáng gờm trong các hệ thống backend, điện toán biên (edge computing), kiến trúc plugin, và thậm chí là một ứng cử viên tiềm năng thay thế cho các công nghệ container hóa truyền thống như Docker. Trong bài viết chuyên sâu mang tính kỹ thuật cao này, chúng ta sẽ khám phá kiến trúc của WebAssembly phía máy chủ, Giao diện Hệ thống WebAssembly (WASI), mô hình thành phần (component model), và lý do tại sao Wasm đang trên đà trở thành runtime phổ quát cho các ứng dụng cloud-native.

Audio Briefing• Voice: Google Cloud Journey-F

0:00 / 0:00

Kiến trúc của WebAssembly phía máy chủ

Về cốt lõi, WebAssembly là một kiến trúc máy trừu tượng. Nó không đưa ra giả định về phần cứng hoặc hệ điều hành bên dưới. Thay vào đó, nó cung cấp một môi trường runtime an toàn, di động và nhanh chóng. Khi chạy trong trình duyệt, Wasm bị giới hạn bởi sandbox của JavaScript và tương tác với DOM thông qua các ràng buộc JavaScript. Khi chạy bên ngoài trình duyệt, những hạn chế này được dỡ bỏ, nhưng an toàn vẫn là mối quan tâm hàng đầu.

Các runtime Wasm phía máy chủ, chẳng hạn như Wasmtime, Wasmer và WasmEdge, sử dụng biên dịch Just-In-Time (JIT) hoặc Ahead-Of-Time (AOT) để dịch mã bytecode WebAssembly sang mã máy native. Quá trình biên dịch này đảm bảo rằng các module Wasm thực thi với tốc độ gần như native. Không giống như các máy ảo truyền thống (như JVM hoặc CLR) yêu cầu một runtime nặng nề, các runtime Wasm cực kỳ nhẹ. Một module Wasm có thể được khởi tạo trong micro giây, làm cho nó lý tưởng cho các môi trường mật độ cao, độ trễ thấp như các hàm serverless và các nút biên.

Bảo mật và Cô lập

Một trong những tính năng hấp dẫn nhất của Wasm là mô hình bảo mật mặc định từ chối (default-deny). Một module Wasm thực thi trong một không gian bộ nhớ được cô lập nghiêm ngặt. Nó không thể truy cập hệ thống tệp, mạng hoặc biến môi trường của hệ điều hành máy chủ trừ khi được cho phép rõ ràng. Mô hình bộ nhớ tuyến tính này đảm bảo rằng các lỗi tràn bộ đệm (buffer overflows) hoặc mã độc hại bên trong module Wasm không thể làm tổn hại hệ thống máy chủ.

Sự cô lập này làm cho WebAssembly trở thành một lựa chọn tuyệt vời để chạy mã không đáng tin cậy. Ví dụ, các nhà cung cấp dịch vụ đám mây có thể lưu trữ hàng nghìn hàm của người thuê trên một máy duy nhất mà không phải chịu chi phí ảo hóa cấp độ phần cứng (VMs) hoặc rủi ro bảo mật liên quan đến ảo hóa cấp độ hệ điều hành (containers).

Giới thiệu WASI: Giao diện Hệ thống WebAssembly

Nếu Wasm là một kiến trúc CPU, nó cần một hệ điều hành để tương tác với thế giới bên ngoài. Đây là lúc Giao diện Hệ thống WebAssembly (WASI) xuất hiện. WASI là một tập hợp các API tiêu chuẩn theo mô-đun được thiết kế để cung cấp cho các module Wasm quyền truy cập an toàn, dựa trên khả năng (capability-based) vào các tài nguyên hệ thống như tệp, mạng và đồng hồ.

Bảo mật dựa trên khả năng

WASI sử dụng bảo mật dựa trên khả năng. Thay vì cấp cho một module Wasm quyền truy cập toàn bộ vào hệ thống tệp (ví dụ: /), máy chủ sẽ chuyển các bộ mô tả tệp (file descriptors) một cách rõ ràng cho module khi khởi tạo. Nếu một module cần đọc từ /var/log và ghi vào /tmp/data, máy chủ sẽ cung cấp các khả năng cụ thể cho các thư mục đó. Module đơn giản là không thể truy cập bất cứ thứ gì khác.

Kiểm soát chi tiết này là một cải tiến đáng kể so với các container Linux truyền thống, vốn thường dựa vào các không gian tên người dùng phức tạp, hồ sơ seccomp và các chính sách AppArmor/SELinux để đạt được sự cô lập tương tự. Với WASI, ranh giới bảo mật được vẽ chặt chẽ xung quanh chính module.

Sự phát triển của WASI

WASI đang tích cực phát triển. Các phiên bản đầu tiên (preview 1) tập trung vào các khả năng cơ bản giống POSIX. WASI Preview 2 sắp tới giới thiệu một mô hình trừu tượng hơn, dựa trên thành phần. Nó loại bỏ các giả định POSIX (vốn gắn liền với các khái niệm hệ điều hành giống Unix) và áp dụng một giao diện cấp cao, linh hoạt hơn, phù hợp với môi trường cloud-native. Điều này bao gồm các API tiêu chuẩn cho các yêu cầu HTTP, kho lưu trữ khóa-giá trị, hàng đợi tin nhắn, v.v., cho phép các module Wasm tích hợp liền mạch với cơ sở hạ tầng đám mây.

Mô hình thành phần: Wasm có thể kết hợp

Một trong những thách thức lịch sử với Wasm là khả năng tương tác giữa các ngôn ngữ khác nhau. Nếu bạn biên dịch một chương trình Rust và một chương trình Go sang Wasm, việc liên kết chúng với nhau theo truyền thống rất khó khăn vì Wasm chỉ hiểu các số (số nguyên và số thực) một cách tự nhiên. Việc truyền các kiểu dữ liệu phức tạp như chuỗi hoặc cấu trúc qua ranh giới module đòi hỏi thao tác bộ nhớ và tuần tự hóa cồng kềnh.

Mô hình thành phần WebAssembly giải quyết vấn đề này. Nó giới thiệu một ABI (Giao diện nhị phân ứng dụng) cấp cao hơn cho phép các module Wasm hiển thị và tiêu thụ các kiểu dữ liệu phức tạp một cách an toàn. Với Mô hình thành phần, các nhà phát triển có thể xây dựng các thành phần nhỏ, có thể tái sử dụng bằng các ngôn ngữ khác nhau và kết hợp chúng thành một ứng dụng duy nhất.

Hãy tưởng tượng viết một thành phần xử lý hình ảnh hiệu suất cao bằng Rust, một thành phần logic nghiệp vụ bằng Go và một thành phần định tuyến API bằng Python. Mỗi thành phần được biên dịch thành một thành phần Wasm. Một runtime máy chủ có thể liên kết các thành phần này lại với nhau, giải quyết các phụ thuộc và ánh xạ các kiểu dữ liệu một cách liền mạch. Mức độ kết hợp đa ngôn ngữ này là chưa từng có trong kỹ thuật phần mềm hiện đại.

Wasm so với Docker: Một tương lai bổ sung

WebAssembly có phải là Docker mới không? Câu trả lời ngắn gọn là: không hoàn toàn, nhưng nó cạnh tranh trong nhiều lĩnh vực chồng chéo. Các container Docker đóng gói một ứng dụng với toàn bộ userland của hệ điều hành (thư viện, tệp nhị phân, hệ thống tệp). Điều này làm cho chúng lớn và khởi động chậm so với các module Wasm.

Ngược lại, các module WebAssembly chỉ chứa mã ứng dụng đã biên dịch. Chúng thường chỉ có vài megabyte về kích thước và khởi động trong micro giây. Điều này làm cho Wasm vượt trội cho điện toán biên, kiến trúc serverless và các thiết bị IoT bị hạn chế tài nguyên.

Tuy nhiên, Docker vẫn cần thiết cho các ứng dụng kế thừa không thể dễ dàng biên dịch sang Wasm hoặc phụ thuộc nhiều vào các tính năng hạt nhân Linux cụ thể. Tương lai có thể là hỗn hợp: Wasm chạy cùng với các container Docker, thường được điều phối bởi Kubernetes. Các dự án như Krustlet đã chứng minh cách Kubernetes có thể lên lịch các khối lượng công việc Wasm một cách tự nhiên như các khối lượng công việc container.

Kết luận

WebAssembly đã vượt ra ngoài trình duyệt. Sự kết hợp giữa hiệu suất gần như native, thời gian khởi động cực nhỏ, bảo mật mặc định từ chối và khả năng di động đa nền tảng làm cho nó trở thành nền tảng lý tưởng cho thế hệ điện toán đám mây tiếp theo. Khi WASI trưởng thành và Mô hình thành phần được áp dụng rộng rãi, chúng ta sẽ thấy một sự thay đổi mô hình trong cách chúng ta xây dựng, triển khai và mở rộng ứng dụng. Các nhà phát triển nên bắt đầu khám phá Wasm phía máy chủ ngay hôm nay, vì nó đang nhanh chóng trở thành một nền tảng của kiến trúc hệ thống hiện đại.

WebAssembly (Wasm) Ngoài Trình Duyệt: Một Kỷ Nguyên Mới Của Compute