Bạn có thể đã nghe nói về Blazor, một frontend framework của .NET để viết các ứng dụng web. Blazor cho phép bạn sử dụng các kỹ năng C# hiện có của mình để xây dựng các ứng dụng full-stack, từ client đến server. Một cách để xây dựng ứng dụng Blazor là “compile” frontend của bạn thành tệp WebAssembly (WASM) và triển khai cũng như chạy ứng dụng của bạn trong trình duyệt web. Phương pháp tiếp cận Blazor WASM có thể giúp bạn xây dựng trải nghiệm client tương tự như các ứng dụng máy tính để bàn gốc với cấu hình hiệu suất gốc.
Nhưng còn WebAssembly trên máy chủ thì sao? Trong bài đăng này, chúng ta sẽ thấy những lợi ích của việc sử dụng WASM bên ngoài trình duyệt và tiềm năng của nó như một công nghệ biến đổi trên máy chủ.
WebAssembly là gì?
WebAssembly là một ngôn ngữ giống như hợp ngữ cấp thấp với định dạng nhị phân chạy trong các trình duyệt web hiện đại. Do đó, các chương trình WebAssembly có thể hoạt động ở tốc độ gần như nguyên gốc, cho phép tạo ra các ứng dụng mới và thú vị cho các ứng dụng web client từ các ứng dụng giống như máy tính để bàn, trình giả lập, trò chơi video hiệu suất cao, trình chỉnh sửa ảnh, v.v… Lợi ích bổ sung của WebAssembly là nó có thể được chạy dưới dạng tiện ích bổ sung thông qua service workers, nâng cao hoặc thay thế trải nghiệm JavaScript hiện có trên máy client.
Các nhà thiết kế của WebAssembly luôn muốn nó chạy song song với mô hình web hiện tại. Các nhà phát triển không quen với JavaScript có thể chọn trong số nhiều ngôn ngữ để viết WebAssembly, bao gồm C, C++, C#, Go, Python và Rust, với nhiều ngôn ngữ khác đang nhắm mục tiêu WASM như một phần mềm biên dịch. Đối với các nhà phát triển .NET, bạn có thể coi phần mở rộng tệp .wasm là định dạng .dll hoặc .exe. Định dạng tệp là tiêu chuẩn và thời gian chạy tuân thủ WebAssembly System Interface (WASI) sẽ có thể sử dụng chúng.
Một thời gian chạy như vậy mà chúng ta sẽ khám phá trong bài viết này là Wasmtime.
Wasmtime là gì?
Được phát triển bởi Bytecode Alliance, Wasmtime là thời gian chạy cho WebAssembly, cho phép bạn sử dụng các tệp .wasm và chạy chúng trên các hệ thống Windows, macOS hoặc Linux bên ngoài máy khách web. Wasmtime là thời gian chạy nhanh, an toàn và tuân thủ tiêu chuẩn dành cho WebAssugging và hỗ trợ WebAssembly System Interface (WASI).
Tính năng quan trọng nhất của Wasmtime là khả năng tương tác với hệ điều hành gốc, cho phép truy cập có thể định cấu hình vào tài nguyên hệ thống. Tài nguyên bao gồm quyền truy cập disk, trình nghe TCP, giao diện đầu vào phần cứng, v.v…
Ngoài việc chạy các tệp .wasm độc lập, bạn có thể sử dụng Wasmtime bên trong các ứng dụng của mình để sử dụng các phần phụ thuộc của bên thứ ba. Tính di động của định dạng WASM mở ra một thế giới nơi bạn có thể tương tác gốc với định dạng chuẩn trên tất cả các ngôn ngữ.
Wasmtime cũng hỗ trợ gỡ lỗi bằng cách sử dụng các công cụ gỡ lỗi gốc phổ biến như GDB hoặc LLDB, mà nhiều sản phẩm dòng IntelliJ đã hỗ trợ. Trải nghiệm gỡ lỗi phụ thuộc vào các công cụ xây dựng của kỹ thuật stack của bạn.
Nói về các công cụ xây dựng, hãy xây dựng ứng dụng máy chủ WASM đầu tiên của chúng tôi, nhưng trước tiên, hãy cài đặt Wasmtime.
Ứng dụng compine WASM.NET
Lưu ý: Bạn sẽ cần cài đặt phiên bản .NET 7 SDK mới nhất
Mục tiêu của chúng ta trong phần này là lấy ứng dụng Bảng điều khiển C# và biên dịch nó thành tệp .wasm. Giải pháp sẽ là một ứng dụng độc lập không cần các tài nguyên WASI duy nhất như trình nghe TCP, quyền truy cập tệp hoặc biến môi trường.
Trước tiên, hãy bắt đầu với một dự án Console Application hoàn toàn mới. Từ cửa sổ giải pháp mới của JetBrains Rider, hãy chọn template “Console Application” và gọi nó là “HelloWasm” hoặc bất kỳ thứ gì bạn muốn.
Khi giải pháp đã sẵn sàng, bạn sẽ cần thêm gói NuGet “Wasi.Sdk” vào dự án bảng điều khiển của mình. Nếu bạn không thấy gói này, hãy đảm bảo rằng bạn đã chọn hộp kiểm Prerelease.
Bạn đã sẵn sàng biên dịch ứng dụng bảng điều khiển thành một phần mềm .wasm. Trước khi làm như vậy, hãy thay đổi dòng trong Program.cs như sau:
Xây dựng dự án của bạn, bạn sẽ thấy các tham chiếu đến các thư viện Hệ thống thường được sử dụng trong các ứng dụng .NET. Hãy nhớ rằng WASM là mã byte gốc. Thời gian chạy .NET phải được đóng gói và vận chuyển như một phần của phần mềm của bạn. Điều này không khác gì việc triển khai Blazor WASM cho một web client.
Xây dựng dự án của bạn, bạn sẽ thấy các tham chiếu đến các thư viện Hệ thống gói thường được sử dụng trong các ứng dụng .NET. Hãy nhớ rằng WASM là mã byte gốc. Thời gian chạy .NET phải được đóng gói và vận chuyển như một phần của phần mềm của bạn. Điều này không khác gì việc triển khai Blazor WASM cho web client.
Khi thành công, bạn sẽ thấy đầu ra của ứng dụng Console của mình.
Thật tuyệt vời! Bạn vừa viết ứng dụng .NET nhắm mục tiêu WASM đầu tiên của mình. Bây giờ bạn có thể triển khai tệp .wasm cho bất kỳ máy chủ nào hỗ trợ WebAssmebly.
Consuming các mô-đun WASM và WAT từ .NET
Mặc dù chắc chắn có thể sử dụng tệp .wasm trong .NET, nhưng nó tẻ nhạt hơn một chút so với trải nghiệm plug-and-play của gói NuGet. Hiện tại, có gói Wasmruntime NuGet chứa các API cấp thấp để xử lý các thành phần của máy chủ lưu trữ. Các yếu tố này bao gồm Engine, Module, Linker, Store và nhiều hơn nữa v.v… Chúng cho phép bạn xác định máy chủ tùy chỉnh của mình, bao gồm các lệnh gọi hệ thống cấp thấp và những lệnh gọi chúng có thể thực hiện trên hệ thống tuân thủ WASI.
Tôi không khuyên hầu hết các nhà phát triển cố gắng viết server của họ; thay vào đó, cộng đồng nên đợi Byte Code Alliance tạo máy chủ lưu trữ an toàn theo mặc định.
Hãy xem một ví dụ trong đó chúng tôi sử dụng WebAssembly Text (WAT) để liên kết một hàm C# với WebAssembly. WAT là định dạng mà con người có thể đọc và chỉnh sửa được đại diện cho định dạng nhị phân WASM.
Điều quan trọng cần lưu ý trong ví dụ này là mô-đun WebAssugging của chúng tôi sử dụng tham chiếu đến $hello. Vì ứng dụng C# của chúng ta quản lý ngữ cảnh WebAssembly nên chúng ta có thể tạo định nghĩa cho $hello bằng phương thức Function.FromCallback. Trong C#, chúng tôi yêu cầu trình liên kết, hiện chứa cả định nghĩa .wat của chúng tôi và triển khai mới $hello của chúng tôi cho phương thức chạy. Tất cả những gì còn lại là gọi Action của chúng tôi và xem kết quả.
Mặc dù nó có vẻ tầm thường, nhưng chúng tôi sẽ có thể chạy và sử dụng WASM trong các ứng dụng .NET của mình. Điều đó mở ra khả năng giải quyết vấn đề bằng cách sử dụng các giải pháp từ các hệ sinh thái khác.
Thực tế hiện tại của WASM trên máy chủ
Mặc dù bài đăng này tương đối lạc quan về triển vọng của WASM, nhưng có những hạn chế đối với công nghệ mà mọi người nên biết và chúng sẽ thay đổi tùy theo máy chủ WASM.
Hạn chế đáng kể đầu tiên là phân luồng. Cho đến nay, với thử nghiệm của tôi, Wasmtime chỉ có quyền truy cập vào một chuỗi duy nhất để thực thi. Giới hạn luồng không hoàn toàn là một công cụ phá vỡ thỏa thuận, nhưng bạn sẽ cần phải viết lại một số giải pháp của mình để giảm nhu cầu tạo luồng. Hạn chế này trở nên rõ ràng khi sử dụng API liên quan đến Thread hoặc Task.Delay, điều này sẽ tạm dừng quá trình đang chạy của bạn hoặc chấm dứt nó. Tuy nhiên, phân luồng có thể không còn là vấn đề trong tương lai gần vì .NET bổ sung hỗ trợ đa luồng cho WASM. Wasmtime cũng cho phép nhiều luồng với cờ thử nghiệm, nhưng công nghệ stack của bạn sẽ cần tận dụng tính năng đó.
Thời gian chạy .NET nhắm mục tiêu WASM giống như Blazor WASM, nghĩa là nó có giới hạn. API sẽ không hoạt động do thiếu hỗ trợ từ máy chủ WASM hiện tại. Thiếu API có thể hạn chế khả năng giải quyết các sự cố cụ thể của bạn. Các API vẫn đang được phát triển tích cực và có thể thay đổi dựa trên các tính năng được thêm vào Wasmtime và các thời gian chạy WASI khác.
Một vấn đề khác mà tôi phát hiện ra là hiện tại không có hỗ trợ outward socket. Việc thiếu hỗ trợ socket sẽ hạn chế khả năng giao tiếp của ứng dụng WASM với các phần phụ thuộc như cơ sở dữ liệu hoặc dịch vụ web. Các cuộc thảo luận về Socket specification sẽ giải quyết vấn đề này, cho phép các ứng dụng WASM mạnh mẽ hơn. Ngoài ra, điều này sẽ cho phép các nhà phát triển .NET sử dụng các công cụ truy cập dữ liệu như Entity Framework Core hoặc Dapper mà không gặp phải sự cố nào.
Công cụ là một mối quan tâm khác; các nhà cung cấp phải bắt kịp những kinh nghiệm mà các nhà phát triển .NET đã quen với việc phát triển các ứng dụng .NET. May mắn cho các nhà phát triển, Wasmruntime sử dụng các công cụ sửa lỗi tiêu chuẩn như LLDB và GDB, giúp việc tích hợp chúng vào các công cụ hiện có trở nên dễ quản lý hơn nhiều.
Cơ sở hạ tầng sẽ đóng một vai trò thiết yếu trong cách bạn xây dựng các giải pháp WASM của mình. Sức mạnh của WASM đến từ khả năng bắt đầu và xử lý các mô-đun đang thực thi một cách nhanh chóng theo kiểu “microservices” hoặc “functions”. Tuy nhiên, một cách tiếp cận kiến trúc khác sẽ yêu cầu bạn suy nghĩ lại về cách phối hợp và các đơn vị công việc của các ứng dụng hiện tại của bạn. Ngoài ra, bạn và nhóm của bạn có thể không đủ khả năng để giải quyết đồng thời các thách thức về kỹ thuật và khái niệm.
Ứng dụng hỗ trợ WASM hiện đại trông như thế nào khi được triển khai? Một số người cho rằng nó giống như các chức năng như một dịch vụ (FaaS), trong khi những người khác coi nó như một sự thay thế cho các thùng chứa trong cụm Kubernetes và cả hai đều hoàn toàn hợp lệ. May mắn thay, nhiều máy chủ WASM mới đang mọc lên cùng với các nhà cung cấp đám mây đáng tin cậy AWS, Microsoft Azure và Cloudflare, thêm các tùy chọn vào danh sách dịch vụ ngày càng mở rộng của họ.
Tưởng tượng về tương lai của WASM trên máy chủ
Nếu bạn đã phát triển bất kỳ ứng dụng Blazor WASM nào, bạn có thể sẽ nhận ra rằng có chút khác biệt khi viết mã. Rốt cuộc, đó là C#! Trải nghiệm sửa lỗi có thể hơi khác một chút, vì giờ đây bạn xử lý một máy chủ và thời gian chạy hoàn toàn khác, cụ thể là trình duyệt web. Tuy nhiên, việc viết các giải pháp để nhắm mục tiêu WASM sẽ có cảm giác rất giống với Blazor WASM và tôi hy vọng trải nghiệm sẽ được cải thiện khi công cụ bắt kịp. Hầu hết các nhà phát triển sẽ dễ dàng chuyển sang ứng dụng WASM hơn là chuyển sang mô hình lập trình mới.
Các frameworks targeting WASM có thể sẽ thay đổi, vì bạn sẽ muốn xem xét lại cách thức và thời điểm các chức năng đang thực thi. Ví dụ: Fermyon đã phát hành .NET Spin SDK dành riêng cho nền tảng lưu trữ nhắm mục tiêu WASM của họ. Hãy xem cách bạn có thể viết một hàm cho SDK của họ.
Ví dụ này đặt ra câu hỏi. Ví dụ: làm thế nào để bạn chuyển đổi từ ASP.NET Core Minimal Endpoints hoặc ASP.NET Core MVC sang phương pháp mới này? ASP.NET Core có cần suy nghĩ lại về cách biên dịch các ứng dụng hiện có thành các đơn vị có thể triển khai không? Tôi mong đợi nhiều cuộc trò chuyện và chiến lược sẽ xuất hiện khi các nhà phát triển áp dụng WASM.
Chúng ta có thể thấy WASM thay thế hầu hết các phiên bản chứa, đặc biệt là khi WASM có thể đóng gói cả thời gian chạy và ứng dụng phụ thuộc vào chúng trong một gói di động. Những ưu điểm mà bạn có thể hy vọng thấy: Giảm mức sử dụng CPU và bộ nhớ, giảm thời gian khởi động nguội, giảm hóa đơn lưu trữ và mang lại hiệu quả kinh tế theo quy mô đáng kể hơn.
Các tệp .wasm này cũng có thể nhỏ hơn đáng kể vì chúng không có cùng nhu cầu đối với các lớp được tìm thấy trong hình ảnh được tạo trên toàn bộ hệ điều hành. Tính di động và hiệu quả của máy chủ WASM sẽ dẫn đến nhiều tùy chọn lưu trữ hơn từ các nhà cung cấp, mới và cũ.
Cuối cùng, triển vọng thú vị nhất của WASM trên máy chủ là sự hoàn thiện của môi trường đám mây bất khả tri, nơi bạn, với tư cách là nhà phát triển, không còn phải lo lắng về các khu vực. WASM có thể được triển khai đồng thời tới nhiều khu vực toàn cầu ngoài các khu vực hạn chế và tắc nghẽn của nhà cung cấp đám mây. WASM có thể bắt đầu gần người dùng của bạn nhất và cung cấp cho họ trải nghiệm nhanh nhất có thể bất kể họ đến từ quốc gia nào. Việc dân chủ hóa trải nghiệm người dùng này là thú vị nhất đối với những người cung cấp các ứng dụng quy mô toàn cầu.
Kết luận
Trong bài đăng này, chúng tôi đã đào sâu vào WebAssembly và những nỗ lực để chạy nó trên máy chủ bằng Wasmtime. Mặc dù nó vẫn còn tương đối mới, nhưng lời hứa về WASM trên máy chủ rất thú vị và .NET đi đầu trong việc cung cấp cho các nhà phát triển nhiều tùy chọn lưu trữ hơn. Khi kinh nghiệm phát triển và công cụ được cải thiện, các nhà phát triển giải pháp sẽ cung cấp cho khách hàng. Như bạn đã thấy, trải nghiệm ngay cả bây giờ vẫn tốt.
Có những hạn chế với WASM, nhưng giống như tất cả các công nghệ, cộng đồng sẽ thúc đẩy các giải pháp và tiến trình sẽ xảy ra. Điều quan trọng vẫn là phải cẩn thận khi chọn các công nghệ tiên tiến làm giải pháp, vì bạn có thể sẽ là một trong số những người đầu tiên và duy nhất gặp phải những vấn đề đó.
Điều đó nói rằng, tôi lạc quan một cách thận trọng về tương lai của WASM và tôi hy vọng bạn đã tìm thấy điều gì đó trong bài viết này khiến bạn tò mò muốn khám phá thêm về chủ đề này.
Tác giả: Ekaterina Petrova
Nguồn: JetBrains Blog