Chìa khóa chiến thắng cho hệ sinh thái AO: kiến ​​trúc microservice trong kỷ nguyên Web3

Tác giả: ArweaveOasis, Nguồn: PermaDAO

Bài viết này thảo luận về những lợi ích của việc áp dụng kiến ​​trúc vi dịch vụ (hoặc mô hình Actor) và phân tích mức độ phức tạp về mặt logic mà nó mang lại cho việc phát triển ứng dụng ở một mức độ nhất định.

Việc phát hành @aoTheComputer chắc chắn mang đến một kiểu suy nghĩ và thực hành mới cho toàn bộ hệ sinh thái @ArweaveEco và thậm chí toàn bộ ngành Web3. Điều này không chỉ thể hiện ở việc thu hút được sự quan tâm của đông đảo nhà đầu tư mà còn thu hút một lượng lớn các nhà phát triển chất lượng cao bắt đầu nghiên cứu chuyên sâu.

Điều gì đang cản trở việc áp dụng rộng rãi Web3?

Đơn giản vì có quá ít ứng dụng phi tập trung đáng sử dụng.

Dựa trên hiện trạng cơ sở hạ tầng Web3, các công cụ phát triển, thực hành công nghệ phần mềm, v.v., nhiều loại ứng dụng phi tập trung hiện gần như không thể triển khai được.

Về cơ sở hạ tầng, tôi nghĩ sự xuất hiện của AO sẽ lấp đầy một số khoảng trống lớn. Tuy nhiên, sự phức tạp về kỹ thuật hiện tại của việc xây dựng các ứng dụng phi tập trung quy mô lớn vẫn còn khó khăn. Điều này ngăn cản chúng tôi phát triển sự phân cấp đa dạng hơn, quy mô lớn hơn và thường tốt hơn, giàu tính năng hơn với nguồn lực hạn chế - điều này thường xảy ra trong giai đoạn phát triển ứng dụng ban đầu.

Đừng tin những lời nói vô nghĩa như “hợp đồng thông minh/chương trình trên chuỗi phải rất đơn giản, không cần phải làm chúng quá phức tạp”!

Vấn đề thực sự không phải là “không muốn” mà là “không thể” - tôi không thể làm được.

AO là một hệ thống máy tính chạy trên Arweave, được thiết kế để đạt được sức mạnh tính toán không giới hạn. Nó là viết tắt của Định hướng diễn viên. Như tên cho thấy, điều này có nghĩa là các ứng dụng phi tập trung chạy trên AO cần áp dụng phương pháp thiết kế và lập trình dựa trên mô hình Actor.

Trên thực tế, AO không phải là công ty đầu tiên sử dụng mô hình Actor cho blockchain (hay “cơ sở hạ tầng phi tập trung”). Ví dụ: hợp đồng thông minh của TON được xây dựng bằng mô hình Actor. Nói về TON, cá nhân tôi cảm thấy nó khá giống AO ở một số khía cạnh.

Đối với các nhà phát triển Web2 chưa hiểu sâu về Web3, nếu họ muốn hiểu nhanh các tính năng lớn nhất của AO hoặc TON so với các "blockchain đơn lẻ" khác, điểm khởi đầu thuận tiện là: Hợp đồng thông minh (các chương trình trên chuỗi) chạy trên chúng được coi là "vi dịch vụ". AO hay TON là cơ sở hạ tầng hỗ trợ hoạt động của các microservice này, chẳng hạn như Kafka, Kubernetes, v.v.

Là một chàng trai CRUD cấp cao, người chủ yếu tập trung vào phát triển ứng dụng trong hơn 20 năm, cá nhân tôi rất vui khi thấy sự xuất hiện của các chuỗi khối không nguyên khối như AO và TON, và tôi Tôi rất quan tâm đến sự phát triển của họ đầy kỳ vọng. Bây giờ tôi muốn nói về quan điểm của tôi về AO từ góc độ của một nhà phát triển ứng dụng. Nhiều quan điểm của tôi có thể chưa chín chắn. Có thể một số nhà phát triển ứng dụng sẽ cảm thấy buồn, thế là đủ.

Việc áp dụng mô hình Actor vào blockchain có thực sự cần thiết không?

Câu trả lời là có. Chỉ cần nhìn vào các ứng dụng Web2 đã đạt được mức “áp dụng hàng loạt” là bạn sẽ hiểu.

Quá nhiều kiến ​​trúc sư đã biết cách "mở rộng quy mô" các ứng dụng Web2: kiến ​​trúc microservice (MSA), kiến ​​trúc hướng sự kiện (EDA), cơ chế truyền thông điệp, mô hình nhất quán cuối cùng, sharding... …Những thứ này, dù được gọi là gì đi nữa, chúng vẫn luôn tồn tại cộng sinh với mô hình Diễn viên. Một số khái niệm này thậm chí có thể được coi là những khía cạnh khác nhau của cùng một sự vật. Do đó, trong văn bản sau, chúng tôi sẽ không phân biệt giữa "microservice" và Actor. Bạn có thể coi chúng là từ đồng nghĩa.

Sự thịnh vượng của Internet ngày nay không thể tách rời khỏi trí tuệ của những kiến ​​trúc sư này. Họ tiếp tục khám phá, thực hành và tổng hợp, và cuối cùng đã hình thành nên một hệ thống thực hành kỹ thuật hoàn chỉnh.

Là cơ sở hạ tầng Web3, AO thực hiện rất tốt công việc của mình. Ít nhất, AO đã cho thấy tiềm năng lớn với tư cách là (trong mắt tôi) nhà môi giới tin nhắn phi tập trung tốt nhất trong lĩnh vực Web3 hiện tại. Tôi tin rằng các nhà phát triển ứng dụng Web2 truyền thống có thể hiểu ngay tầm quan trọng của điều này: nếu không có sẵn nhà môi giới tin nhắn giống Kafka hoặc Kafka, bạn có thể tưởng tượng "cách viết chương trình" cho nhiều ứng dụng Internet quy mô lớn hiện nay không?

Mặc dù mô hình Actor có những ưu điểm về mặt lý thuyết về nhiều mặt, dù là mô hình Actor hay kiến ​​trúc microservice, nhưng theo tôi, các nhà phát triển sẽ phát triển một số ứng dụng nhất định hơn (đặc biệt là "nỗi đau" mà các ứng dụng lớn) phải chịu đựng.

Hãy minh họa điều này cho những độc giả không rành về kỹ thuật bằng một ví dụ đơn giản. Giả sử tất cả các ngân hàng trên thế giới đều hoạt động dựa trên một “máy tính thế giới” và máy tính thế giới này là một hệ thống kiến ​​trúc nguyên khối. Sau đó, khi "Zhang San", một khách hàng của ICBC, chuyển 100 nhân dân tệ cho "Li Si", người có tài khoản tại China Merchants Bank, nhà phát triển có thể viết mã của chương trình chuyển khoản như thế này:

1. Bắt đầu giao dịch (Hoặc "giao dịch", chúng là cùng một từ trong tiếng Anh);

2. Trừ 100 nhân dân tệ từ tài khoản của Zhang San;

3. Tài khoản của Li Si Thêm 100 nhân dân tệ vào tài khoản;

4.

Cho dù bước nào trong các bước trên có vấn đề, ví dụ như bước thứ ba, việc thêm số tiền vào tài khoản của Li Si không thành công vì lý do nào đó thì toàn bộ thao tác sẽ bị khôi phục, coi như có không có gì cả. Điều tương tự đã xảy ra. Nhân tiện, khi chương trình được viết như thế này, chúng tôi gọi nó bằng mô hình "tính nhất quán mạnh mẽ".

Điều gì sẽ xảy ra nếu máy tính trên thế giới này là một hệ thống sử dụng kiến ​​trúc microservices (MSA)?

Khi đó, hầu như không có khả năng vi dịch vụ (hoặc Tác nhân) quản lý tài khoản ICBC và vi dịch vụ quản lý tài khoản China Merchants Bank là giống nhau. Trước tiên hãy giả sử rằng chúng thực sự không giống nhau. Cái trước được gọi là Actor ICBC và cái sau được gọi là Actor CMB. Lúc này, nhà phát triển có thể cần viết mã chuyển khoản như sau:

1. Diễn viên ICBC trước tiên ghi lại thông tin sau: "Zhang San chuyển 100 nhân dân tệ cho Li Si"; Trừ 100 tệ và gửi tin nhắn cho Diễn viên CMB: "Zhang San chuyển 100 tệ cho Li Si";

2. Diễn viên CMB nhận được tin nhắn, thêm 100 tệ vào tài khoản của Li Si, sau đó gửi 100 tệ vào tài khoản của Li Si. Diễn viên ICBC gửi tin nhắn "Li Si đã nhận được 100 nhân dân tệ do Zhang San chuyển";

3. Diễn viên ICBC nhận được tin nhắn và ghi lại: "Zhang San đã chuyển 100 nhân dân tệ cho Li. Si, thành công rồi”.

Trên đây chỉ là quá trình "mọi thứ đều ổn". Tuy nhiên, chúng ta nên làm gì nếu có vấn đề ở một bước nào đó, chẳng hạn như bước thứ hai, "thêm 100 nhân dân tệ vào tài khoản của John Doe"?

Các nhà phát triển cần viết logic xử lý sau đây cho vấn đề có thể xảy ra này:

• Actor CMB báo cáo cho Actor ICBC Gửi một Tin nhắn: "Trương Tam chuyển 100 tệ cho Lý Tư, xử lý không thành công."

• Diễn viên ICBC nhận được tin nhắn, thêm 100 nhân dân tệ vào tài khoản của Zhang San và ghi lại: " Zhang San chuyển 100 tệ cho Li Si không thành công.”

Viết chương trình như thế này được gọi là sử dụng mô hình nhất quán cuối cùng.

Ở trên, những người đọc không rành về kỹ thuật có thể cảm nhận được bằng trực giác sự khác biệt lớn về khối lượng công việc giữa việc phát triển ứng dụng kiến ​​trúc nguyên khối và phát triển ứng dụng MSA, phải không? Bạn biết đấy, ví dụ chuyển giao nêu trên chỉ là một ứng dụng rất đơn giản, nếu chúng ta gọi nó là một ứng dụng chứ không phải là một hàm. Các chức năng trong các ứng dụng lớn thường phức tạp hơn nhiều so với các ví dụ như thế này.

Dịch vụ vi mô này nên lớn đến mức nào?

Nói cách khác, "Có phải microservice này quá lớn và nên chia làm hai?"

Thật không may, không có câu trả lời chuẩn mực cho câu hỏi này; Microservice càng nhỏ thì càng dễ tối ưu hóa hệ thống bằng cách tạo các phiên bản mới và di chuyển chúng khi cần. Tuy nhiên, microservice càng nhỏ thì nhà phát triển càng khó thực hiện các quy trình phức tạp, như đã trình bày ở trên.

Nhân tiện, việc chia một ứng dụng thành nhiều vi dịch vụ được gọi là "Sharding" từ góc độ thiết kế cơ sở dữ liệu. Một trong những cách thực hành tốt nhất về kiến ​​trúc microservice là mỗi microservice chỉ sử dụng cơ sở dữ liệu cục bộ của riêng nó. Nói một cách đơn giản, sharding cho phép mở rộng quy mô theo chiều ngang. Khi các tập dữ liệu trở nên quá lớn để có thể xử lý bằng các phương pháp truyền thống, không có cách nào khác ngoài việc chia chúng thành các phần nhỏ hơn.

Quay lại vấn đề chia nhỏ microservice. Để thực hành tốt hơn nghệ thuật này, chúng ta cần nắm vững cách sử dụng một số công cụ tư duy. "Tổng hợp" của DDD (Thiết kế hướng tên miền) là một "sát thủ lớn" mà bạn phải có. Ý tôi là nó giúp bạn phá bỏ "sự phức tạp cốt lõi" trong thiết kế phần mềm.

Tôi nghĩ tổng hợp là khái niệm quan trọng nhất của DDD ở cấp độ chiến thuật.

Tập hợp là gì? Tập hợp vẽ ra ranh giới giữa các đối tượng, đặc biệt là các thực thể. Một tập hợp phải chứa và chỉ chứa một thực thể gốc tổng hợp và có thể chứa một số lượng không xác định các thực thể nội bộ tổng hợp (hoặc các thực thể gốc không tổng hợp).

Chúng ta có thể sử dụng khái niệm tổng hợp để phân tích và mô hình hóa các trường mà ứng dụng phục vụ, sau đó khi mã hóa, chúng ta có thể phân chia các vi dịch vụ theo tổng hợp; Cách tiếp cận đơn giản nhất là triển khai từng tập hợp dưới dạng một dịch vụ vi mô.

Tuy nhiên, dù bạn có kỹ năng đến đâu, bạn cũng không thể đảm bảo rằng mình sẽ làm đúng việc này ngay lần đầu tiên. Tại thời điểm này, một công cụ cho phép bạn xác minh kết quả lập mô hình càng sớm càng tốt và bắt đầu lại nếu thất bại là vô cùng quý giá đối với bạn.

Điều gì khác có thể gây trở ngại cho việc di chuyển các ứng dụng Web2 quy mô lớn sang hệ sinh thái AO?

Tôi muốn nói về vấn đề ngôn ngữ và thời gian chạy chương trình.

AO là một giao thức dữ liệu. Bạn có thể coi nó như một tập hợp các thông số kỹ thuật giao diện xác định cách mỗi "đơn vị" trong mạng AO cộng tác. Hiện tại, việc triển khai AO chính thức bao gồm môi trường máy ảo dựa trên WASM và môi trường thời gian chạy Lua (ao-lib) được biên dịch thành WASM, nhằm đơn giản hóa việc phát triển quy trình AO.

Lua là một ngôn ngữ nhỏ nhưng đẹp. Người ta thường tin rằng điểm mạnh của Lua nằm ở sự nhẹ nhàng và dễ nhúng vào các ngôn ngữ khác, điều này khiến nó đặc biệt hữu ích trong các tình huống cụ thể như phát triển trò chơi. Tuy nhiên, ngôn ngữ Lua không phải là lựa chọn phổ biến để phát triển các ứng dụng Internet quy mô lớn. Phát triển ứng dụng Internet quy mô lớn thường có xu hướng sử dụng các ngôn ngữ như Java, C#, PHP, Python, JavaScript, Ruby, v.v., vì các ngôn ngữ này cung cấp hệ sinh thái và chuỗi công cụ toàn diện hơn cũng như cộng đồng rộng lớn hơn ủng hộ.

Một số người có thể lập luận rằng những ngôn ngữ này​​có thể được biên dịch thành mã byte WASM và chạy trong máy ảo WASM. Nhưng trên thực tế, mặc dù WASM có hiệu suất mạnh mẽ trong lĩnh vực phát triển Web front-end nhưng hiện tại việc các ứng dụng Internet sử dụng WASM làm môi trường hoạt động back-end không phải là lựa chọn phổ biến. Lưu ý rằng hợp đồng thông minh (chương trình trên chuỗi) là "phụ trợ mới" trong kỷ nguyên Web3.

Tóm tắt

Tóm lại, chúng ta đã thảo luận về những lợi ích của việc áp dụng kiến ​​trúc microservice (hoặc mô hình Actor) và những lợi ích mà nó mang lại cho việc phát triển Ứng dụng. . Một số phức tạp là không thể tránh khỏi. Ví dụ: ngay cả trong môi trường Web2 hoàn thiện hơn, việc đạt được "sự nhất quán cuối cùng" dựa trên giao tiếp bằng tin nhắn đã là một thách thức lớn đối với nhiều nhà phát triển. Khi phát triển Dapps trên nền tảng AO non trẻ, thách thức này dường như càng rõ ràng hơn - tất nhiên điều này hoàn toàn dễ hiểu.  Một ví dụ được hiển thị ở đầu bài viết được liên kết bên dưới.

https://github.com/dddappp/A-AO-Demo?tab=readme-ov-file#an-ao-dapp-development-demo -với cách tiếp cận mã thấp

Tất cả chúng ta đều biết rằng cuộc chiến giành chuỗi công khai thực chất là cuộc chiến dành cho các nhà phát triển ứng dụng. Vậy làm thế nào để AO thu phục được các nhà phát triển trong tình huống này?

Tôi nghĩ chúng ta cần tiếp tục rút kinh nghiệm từ việc "áp dụng hàng loạt" Web2. Điều này không chỉ bao gồm việc tìm hiểu cơ sở hạ tầng của nó mà còn bao gồm các khía cạnh như phương pháp phát triển, công cụ phát triển và thực tiễn công nghệ phần mềm. Trong bài viết tiếp theo, tôi sẽ chỉ cho bạn một giải pháp mà tôi tin tưởng chắc chắn: phát triển low-code.