Sự phát triển của các tiêu chuẩn Wasm: Xây dựng mô hình thành phần

Có một số nỗ lực tiêu chuẩn hóa mới đang diễn ra trong không gian WebAssugging (Wasm), bao gồm những gì chúng tôi tin là một cách mới để viết các ứng dụng phần mềm. Bằng cách mô tả mô hình mới này, tôi muốn đi sâu vào một số lịch sử của Wasm như một cách để mô tả nơi chúng ta đang hướng tới.

Thiết kế cho WebAssugging (Wasm) bắt đầu vào năm 2015, nhiều năm trước khi chính thức trở thành ngôn ngữ thứ 4 của web vào năm 2019. Trong khi nhiều nhà công nghệ quen thuộc với Wasm như một công nghệ trình duyệt, bản thân Wasm không phụ thuộc vào JavaScript hoặc API web.

Tiền thân của Wasm, asm.js , đã trở nên nổi bật vào năm 2013. Một tập hợp con của JavaScript có khả năng tối ưu hóa cao cho các trình duyệt và có thể đóng vai trò là mục tiêu biên dịch cho các ngôn ngữ như C và C++. Một trong những bài nói chuyện yêu thích nhất mọi thời đại của tôi, “Sự ra đời và cái chết của JavaScript” đề cập đến một tương lai hư cấu lấy cảm hứng từ asm.js . Lưu ý những điểm tương đồng giữa tương lai mà chúng ta cuối cùng mở ra với những dự đoán của Wasm và Gary bằng cách xem bài nói chuyện của anh ấy từ PyCon 2014.

Tôi thường gọi asm.js là bản hack vĩ đại nhất mọi thời đại (theo cách đáng yêu nhất). Ai có thể nghĩ rằng một ngôn ngữ kịch bản cấp cao lại có thể là A")" một mục tiêu biên dịch và B")" nhanh đến khó tin? Vào năm 2012, tôi đã chuyển một số thư viện C++ sang asm.js và cảm thấy rằng tôi đã mở khóa mã bí mật cho một vũ trụ di động.

Công nghệ đã chứng minh một số điều. Đầu tiên, có nhu cầu và mong muốn đưa các ngôn ngữ khác lên web, nhưng các nhà phát triển không muốn dừng lại ở đó. Các loại ứng dụng được chuyển đòi hỏi tính toán và đồ họa, từ các công cụ trực quan hóa dữ liệu (như các thành phần tôi đã làm việc tại SAS) đến các trò chơi được xây dựng bằng Unity và Unreal Engine (UE3 được chuyển trong 4 ngày ).

Đó là lý do tại sao khi nhóm cộng đồng W3C WebAssembly và kho lưu trữ thiết kế WebAssembly tương ứng được tạo ra vào năm 2015, các nhà cung cấp trình duyệt như Mozilla, Google , Microsoft và Apple là những người đầu tiên đóng góp cho nỗ lực này và là người đầu tiên nhìn thấy cơ hội hữu hình. Thiết kế yêu cầu một ngôn ngữ có định dạng nhị phân có thể được sử dụng làm mục tiêu biên dịch di động, được tối ưu hóa về kích thước để cho phép tải xuống nhanh và hỗ trợ biên dịch trực tuyến cho phép mô-đun đã tải xuống có khả năng khởi tạo gần như tức thì. Quan trọng nhất, các mô-đun này phải tạo điều kiện thuận lợi cho [môi trường thực thi] hộp cát giống như bất kỳ mã tùy ý nào chạy trong trình duyệt.

Tại sao Wasm ngoài trình duyệt ?

Phần lớn những gì đã học được trong quá trình triển khai phía trình duyệt đã đưa ra manh mối về nhiều cách mà Wasm có thể phát huy hết tiềm năng của nó ngoài trình duyệt. “Đám mây” tạo thành một tập hợp không đồng nhất các kiến ​​trúc điện toán, hệ điều hành và các ràng buộc hệ thống trong một mạng lưới máy móc trên toàn thế giới.

Hãy coi một số thuộc tính chính của Wasm là mục tiêu biên dịch di động nhanh, được đóng hộp cát và phân phối dễ dàng nhờ định dạng nhị phân nhỏ gọn. Các thuộc tính này của Wasm làm cho nó trở thành đơn vị tính toán có thể phân phối hoàn hảo cho đám mây. Ngoài ra, các công ty muốn xây dựng các ứng dụng cho các môi trường khác nhau nhưng không muốn phải cấu trúc lại mọi lúc. Wasm loại bỏ những rào cản này.

Khi tôi lần đầu tiên biết về asm.js , tôi đang tìm kiếm một giải pháp về cách đưa ứng dụng Flash hiện có của chúng tôi sang HTML5. Ứng dụng ActionScript/Flex này là phiên bản được viết lại của ứng dụng đối tác Java của nó, vốn là cổng của các phiên bản trước đó của cùng logic nghiệp vụ được viết bằng C. Câu chuyện này có vẻ hoang đường đối với bạn nếu bạn chưa từng làm việc trong các doanh nghiệp lớn, nhưng bạn có thể tìm thấy loại chuyển đổi này giữa mỗi kỷ nguyên điện toán trong mọi tổ chức đủ may mắn để tồn tại qua thử thách của thời gian.

Wasm cho phép toàn bộ tính di động đối với bất kỳ thời gian chạy nào tuân thủ Wasm, bao gồm cả trình duyệt, thời gian chạy được xây dựng có mục đích cho FaaS hoặc thứ gì đó được thiết kế để chạy trên các kiến ​​trúc nhỏ cho IoT. Trong web, các mô-đun Wasm có thể sử dụng mã "keo" JavaScript để truy cập các API web như WebGL, kết nối mạng và thiết bị để thực hiện những việc ngoài tính toán thuần túy. Vào cuối ngày, một chương trình Wasm thực sự chỉ hoạt động trên các giá trị số, hay nói cách khác, một mô-đun Wasm là một loạt các i32 trong một chiếc áo choàng. Để thực hiện những điều thú vị, mô-đun Wasm cần có khả năng gọi các hàm từ thời gian chạy máy chủ.

WASI: biên giới của Wasm phía máy chủ

Cũng trong khoảng thời gian mà WebAssembly 1.0 trở thành một tiêu chuẩn web được đề xuất, một nhóm con mới trong nhóm làm việc W3C WebAssembly đã được tạo để khám phá giao diện cấp hệ thống cho WebAssugging được gọi là WASI (Giao diện Hệ thống WebAssembly). Kể từ đó, nhóm đã làm việc để tạo ra một tập hợp các giao diện được tiêu chuẩn hóa.

WASI tồn tại để làm cho WebAssugging hoạt động tốt ở mọi nơi, không chỉ trong trình duyệt, nhưng tính năng xác định chính của WASI là mô hình bảo mật dựa trên khả năng của nó. Bảo mật dựa trên khả năng đã xuất hiện từ những năm 60 ( Dennis & Van Horn, 1966 ), nhưng Dan Gohman đã thiết kế một giải pháp mới cho vấn đề này bằng cách xây dựng dựa trên các ý tưởng từ Cloud ABI .

Có thể hiểu được, công nghệ này đã sớm thu hút sự chú ý của các công ty quan tâm đến việc chạy Wasm bên ngoài web. Các công ty như Fastly, Intel, Red Hat và Mozilla đã nhìn thấy cơ hội đưa Wasm hoạt động trên đám mây, trên thiết bị và ở vùng biên. Những công ty đó là thành viên sáng lập của Liên minh Bytecode (BA), một tổ chức phi lợi nhuận nhằm xây dựng nền tảng phần mềm an toàn cho Wasm bằng cách sử dụng các tiêu chuẩn như WASI. Nhiều tổ chức khác đã sớm tham gia BA, bao gồm cả những người chơi lớn trong ngành công nghiệp phần mềm và nó hiện có hơn 30 thành viên và đang phát triển!

Trong vài năm qua, chúng tôi đã đạt được tiến bộ lớn trong việc xây dựng công cụ cần thiết để chạy Wasm trong các ứng dụng gốc trên đám mây . Cộng đồng đã học được rất nhiều từ những trải nghiệm ban đầu này và điều này đã ảnh hưởng đến chúng tôi để tạo ra một tiêu chuẩn mới mà bây giờ chúng tôi gọi là Mô hình Thành phần. Mô hình Thành phần ở mức thấp hơn WASI, nó hoạt động tốt với WASI nhưng không phụ thuộc vào WASI. Đây là kết quả của việc chúng tôi hình dung ra một hệ sinh thái phần mềm không chỉ dựa trên một đơn vị tính toán di động mà còn là một thứ hoàn toàn mới với các mô-đun WebAssugging có thể kết hợp, có thể tương tác và ảo hóa nền tảng.

Hãy phá vỡ điều đó:

• Khả năng kết hợp: Cho phép tái sử dụng mã mô-đun theo cách độc lập với ngôn ngữ.

• Ảo hóa nền tảng: Khả năng phân lớp trong các phần dành riêng cho nền tảng mà một thành phần cần chạy trong một môi trường nhất định. Một đề xuất trước đó cho tính năng ảo hóa nền tảng và khả năng kết hợp được gọi là liên kết mô-đun.

• Khả năng tương tác: Với các thành phần có thể kết hợp và ảo hóa, chúng ta cần một cách để trao đổi thông tin giữa các thành phần. Chúng tôi đã bắt đầu với một đề xuất được gọi là các loại giao diện, nhưng đây cũng là một tính năng chính của đề xuất mô hình thành phần.

  
  

Đây là câu chuyện về cách Mô hình Thành phần bắt đầu hình thành. Mỗi một trong những đề xuất trước đây hiện đã được tinh chỉnh thành tiêu chuẩn bao trùm này. Chúng tôi hy vọng sẽ thấy sự lặp lại ổn định lớn tiếp theo của Tiêu chuẩn WASI và Mô hình Thành phần vào cuối năm nay.

Tiêu chuẩn WASI - chúng ta đang ở đâu ?

Dưới đây, chúng tôi sẽ đưa bạn qua lịch sử theo sơ đồ của Wasm, WASI và sự phát triển của Mô hình Thành phần.

2019 : Mục tiêu biên dịch thuần túy, thêm các giao diện ban đầu kết nối các tòa nhà chọc trời với máy chủ. Ở nhiều khía cạnh, có vẻ như chúng tôi đang hướng tới phiên bản WebAssugging của POSIX. Chúng tôi đã có thể viết một CLI thực sự đơn giản và chạy nó với Wasmtime trên máy tính để bàn hoặc trong chức năng không có máy chủ.

2020 : API WASI tập trung vào những thứ mà bất kỳ chương trình CLI nào cũng có thể cần, ví dụ: đồng hồ hệ thống hoặc hệ thống tệp. Thời gian chạy Lucet Wasm của Fastly được hợp nhất với Wasmtime (một dự án BA).

2021 : Tất nhiên, tất cả các yếu tố này tiếp tục phát triển và cải thiện. Vào năm 2021, chúng ta bắt đầu thấy sự phát triển của các giao diện WASI dành riêng cho trường hợp sử dụng mới, ví dụ wasi-nn khi cần tăng tốc phần cứng để suy luận. Đây cũng là năm Luke Wagner bắt đầu định nghĩa Mô hình Thành phần.

Năm 2022 : Chúng tôi bắt đầu thấy các API cấp cao hơn mới để làm cho các mô-đun Wasm chạy tốt trong môi trường đám mây, nơi cần có các khả năng như làm việc với kho lưu trữ khóa-giá trị hoặc dịch vụ nhắn tin pub/sub. Cuối cùng, sau rất nhiều nỗ lực, ổ cắm WASI đã được giới thiệu. Năm 2023 : Chúng tôi đang nỗ lực hướng tới các mốc ổn định cho mô hình thành phần và các tiêu chuẩn WASI.

Nhìn vào hành trình từ năm 2019, bạn có thể bắt đầu thấy các tiêu chuẩn đã đa dạng hóa như thế nào khi các trường hợp sử dụng đã tăng lên và người dùng bắt đầu lựa chọn những gì họ cần và không cần. Từ một khối phổ biến đến một bộ các khối xây dựng nhỏ hơn đang phát triển được thiết kế để hoạt động với nhau trong một khuôn khổ linh hoạt: Mô hình Thành phần.

Mô hình Hợp phần là gì ?

Trong mô hình này, các nhà phát triển có thể chọn và chọn các phần trong ứng dụng của họ, được triển khai bằng các ngôn ngữ khác nhau, dưới dạng các đề xuất giá trị khác nhau. Khi các nhà phát triển bắt đầu tạo các thư viện thành phần Wasm, các nhà phát triển khác có thể coi chúng như thùng 'LEGO' lớn nhất thế giới.

Trong một thời điểm toàn diện, chúng tôi tin rằng sự đổi mới mới sẽ đến khi Mô hình Thành phần bắt đầu ảnh hưởng đến cách chúng ta viết các ứng dụng web. Điều này có ý nghĩa khi coi web là một trong những môi trường thú vị nhưng bị hạn chế, với những người dùng rất thiếu kiên nhẫn - nơi sinh sản cho những thử nghiệm mới.

Ví dụ: tôi mong đợi các thành phần giúp việc thiết kế hệ thống plugin trung lập về ngôn ngữ cho ứng dụng web trở nên dễ dàng hơn. Nếu có một phần cần thiết cho thời gian chạy ngôn ngữ như Python, thì nhiều thành phần tận dụng thời gian chạy ngôn ngữ đó có thể sử dụng nó. So sánh điều này với thế giới ngày nay, nơi chúng ta chỉ có các mô-đun Wasm (không phải thành phần) và chúng thường được xây dựng với tất cả các phụ thuộc thời gian biên dịch của chúng được đưa vào một tệp nhị phân duy nhất. Nếu một ứng dụng lớn hỗ trợ plugin của bên thứ ba, thì có khả năng mỗi plugin Wasm sẽ có các phụ thuộc trùng lặp dẫn đến kích thước và bộ nhớ phình to cũng như tải xuống chậm hơn.

Với một hệ thống các thành phần Wasm cho web trong tương lai, trong đó một ứng dụng có thể có lựa chọn các thành phần được viết bằng bất kỳ ngôn ngữ nào, một ứng dụng sẽ chỉ cần tải xuống chính xác những gì nó cần và tương tác với các thành phần giống như bất kỳ mô-đun ES nào khác bằng một lần nhập. Trong thế giới này, thành phần tốt nhất sẽ vươn lên dẫn đầu. Tốt nhất có thể có nghĩa là API nhanh nhất hoặc sạch nhất, nhưng quan trọng nhất là đặc điểm xác định của nó sẽ không phải là ngôn ngữ nguồn. Có thể thành phần tốt nhất giành chiến thắng!

Xây dựng nền tảng kỹ thuật ổn định cho WASI và Linh kiện

Một phần quan trọng trong việc biến các tiêu chuẩn WASI và Mô hình thành phần thành hiện thực là vai trò của BA trong việc tạo ra một khung kỹ thuật có thể sử dụng được: SDK, công cụ và các thành phần cốt lõi; tất cả được xây dựng theo một cách nhất quán và an toàn, và tất cả mọi người đều có thể truy cập được như những ví dụ về phương pháp hay nhất.

Tương tự, vai trò của Ban chỉ đạo kỹ thuật (TSC) của BA sẽ rất quan trọng trong việc cung cấp quản trị và hỗ trợ kỹ thuật cho mọi dự án BA. Chúng tôi làm việc cùng với những người thiết kế bộ tiêu chuẩn tốt nhất có thể trong các nhóm làm việc của W3C WebAssembly và WASI, điều đó có nghĩa là chúng tôi cộng tác với họ để đảm bảo mọi thứ hoạt động trong thực tế. Các nhóm W3C WebAssugging và WASI tập trung vào việc hoàn thiện các tiêu chuẩn này và BA tập trung vào việc làm cho chúng có thể tiêu thụ được trong cộng đồng càng nhanh càng tốt để thiết lập một vòng phản hồi tích cực.

Một phần quan trọng khác trong điều lệ của BA là cho phép khả năng tương tác giữa ngôn ngữ và môi trường. BA cung cấp công cụ để tạo các ràng buộc ngôn ngữ cho nhiều ngôn ngữ khác nhau, nhưng một khía cạnh của cách đạt được trạng thái niết bàn về khả năng tương tác ngôn ngữ là chúng tôi cần các cơ quan đăng ký và trình quản lý gói trong các hệ sinh thái ngôn ngữ khác nhau để tương tác với các thành phần Wasm. Đó là lý do tại sao chúng tôi đang nghiên cứu thiết kế một giao thức đăng ký (được gọi là warg) như một phần của SIG-Registries cho phép bất kỳ cơ quan đăng ký nào triển khai giao thức xuất bản, sử dụng, lưu trữ và chia sẻ các thành phần Wasm.

Có lẽ phần quan trọng nhất của bất kỳ ngăn xếp phần mềm Wasm nào là thời gian chạy Wasm và BA lưu trữ hai! Wasmtime được viết bằng Rust và thường là nơi thử nghiệm để thử nghiệm các đề xuất WASI và WebAssembly mới. WebAssugging Micro-Runtime ( WAMR ) được viết bằng C và hỗ trợ nhiều kiến ​​trúc bao gồm cả những kiến ​​trúc nhỏ như ESP32. Cả hai thời gian chạy này đóng vai trò là triển khai tham chiếu tuyệt vời của thời gian chạy Wasm. SDK và công cụ để xây dựng mô-đun Wasm phù hợp với tiêu chuẩn Wasm, do đó, bất kỳ thời gian chạy Wasm tuân thủ tiêu chuẩn nào (bao gồm cả thời gian chạy không được lưu trữ bởi BA) đều có thể xây dựng trên các nền tảng phần mềm này.

Với tất cả các tiêu chuẩn mới và thú vị được phát triển thông qua WASI và Mô hình Thành phần cũng như các triển khai từ Liên minh Bytecode, tôi kỳ vọng năm 2023 sẽ là một năm thú vị!

Bắt đầu với Cosmonic miễn phí ngay hôm nay: Khởi chạy ngay!

Bởi Bailey Hayes | Giám đốc Liên minh Bytecode TSC và Cosmonic