untitled(23)-1720710384.png
2024-07-09

AO 生态的胜利之匙:Web3 时代的微服务架构

摘要

本文讨论了采用微服务架构(或者说 Actor 模型)的优势,分析了它为应用开发带来的一定程度上合乎逻辑的复杂性。


作者: ArweaveOasis

原文首发于:@ArweaveOasis 推特

来源:内容公会 - 新闻


@aoTheComputer 的发布无疑给整个 @ArweaveEco 生态乃至于整个 Web3 行业带来了一种全新的思考与实践。这不仅体现在广大投资者的关注度上,更体现在吸引大量优质开发者开始深度研究之上。

今天我想首发一篇来自开发者生态的资深开发者所写的关于对 #AO 前景看法的文章。该文作者杨捷锋来头不小,他同时也是这本***《深入实践 DDD:以 DSL 驱动复杂软件开发》***一书的作者,其实力可见一斑。那我们就来看看在这样的开发大能眼里,AO 究竟是什么。

是什么阻碍了 Web3 的大规模采用?

很简单,因为值得人们使用的去中心化应用太少了。

基于 Web3 基础设施、开发工具、软件工程实践等方面的现状,很多类型的去中心化应用当前几乎是无法实现的。

在基础设施方面,我认为 AO 的出现填补了其中一部分重大的空白。但是,目前构建大型去中心化应用的工程的复杂性,仍然是令人望而生畏的。 这使得我们无法在资源受限的情况下——在事物发展的初始阶段,通常如此——开发出更多样化的、更大规模、往往也意味着更棒、功能更丰富的去中心化应用。

不要相信那些类似“智能合约 / 链上程序应该就是很简单的,没有必要搞得太复杂”之类倒果为因的鬼话!

现实问题并不是“不想”,而是“不能” —— 臣妾做不到啊。

AO 是运行在 Arweave 上的计算机系统,旨在实现可验证的无限计算能力。它是 Actor Oriented(面向参与者)的简称。顾名思义,这说明运行在 AO 上的去中心化应用需要采用 Actor 模型 为基础的设计和编程方法。

事实上,AO 并不是最早将 Actor 模型用于区块链(或者说“去中心化基础设施”)的。比如,TON 的智能合约就是使用 Actor 模型构建的。说到 TON,我个人觉得它和 AO 在某些方面颇有相似之处。

对于尚未深入了解 Web3 的 Web2 开发者来说,想要迅速理解 AO 或 TON 相对其他“单体区块链”的最大特色,一个方便的抓手是:把运行在它们之上的智能合约(链上程序)看作是**“微服务”**。而 AO 或 TON 是支持这些微服务运行的基础设施,比如 Kafka、Kubernetes 等。

作为一个 20 多年来主要专注于应用开发的一名资深 CRUD boy, 我个人非常乐见 AO、TON 这样的非单体区块链的出现,并对它们的发展充满期待。 下面我想从一个应用开发者的视角,谈谈我对 AO 的看法,可能很多观点还不太成熟。 也许部分应用开发者会心有戚戚焉,那就足矣。

将 Actor 模型应用于区块链,真的有必要吗?

答案是肯定的。看看已经取得“大规模采用”的 Web2 应用,你就会明白。

太多的架构师已经知道如何将 Web2 应用“搞大”:微服务架构(MSA)、事件驱动的架构(EDA)、消息通信机制、最终一致性模型、分片……这些东西,不管叫什么,总是与 Actor 模型共生共存的。其中的一些概念,甚至可以说只是一个事物的不同方面而已。所以在下面的行文中,我们不对“微服务”和 Actor 做区分,你可以认为它们就是同义词。

今日互联网的繁荣,离不开这些架构师的智慧。他们不断地探索、实践、总结,最终形成了一套完整的工程实践体系。

作为 Web3 基础设施,AO 做的很棒。 至少,AO 作为(我眼中的)当前 Web3 领域的最佳去中心化消息代理,已经展现出巨大的潜力。 我相信传统 Web2 应用的开发者由此可以马上理解其中的重大意义: 倘若没有 Kafka 或者类 Kafka 的消息代理可用,你能想象现在很多大型的互联网应用“程序要怎么写”吗?

虽然 Actor 模型在很多方面具有理论上的优势,但是不管是 Actor 模型也好,微服务架构也好,在我看来,更多是开发者为了开发某些应用(特别是大型应用)所不得不承受之“痛”。

让我们用一个简单的例子来向非技术读者说明这一点。假设世界上所有银行都基于一个“世界计算机”来开展业务,而这个世界计算机是一个单体架构的系统。那么,当工商银行的客户“张三”向在招商银行开设账户的“李四”汇款 100 元的时候,开发者可以这样编写转账程序的代码:

  1. 开始一个事务(或者说“交易”,它们在英文中是同一个词);

  2. 在张三的账户上扣减 100 元;

  3. 在李四的账户上增加 100 元;

  4. 提交事务。

以上步骤不管哪一步出现问题,比如说第三步,在李四的账户上增加金额,因为某种原因失败了,那么整个操作都会被回滚,就像什么都没有发生过一样。 对了,程序这样写,我们称之为采用“强一致性”模型。

倘若这个世界计算机是个采用微服务架构(MSA)的系统呢?

那么,管理工商银行账户的那个微服务(或者说 Actor)与管理招商银行账户的那个微服务,几乎不太可能是同一个。我们先假设它们确实不是同一个,前者我们称为 Actor ICBC,后者我们称为 Actor CMB。此时,开发者可能需要这样编写转账的代码:

  1. Actor ICBC 先记录好以下信息:“张三向李四转账 100 元”;Actor ICBC 在张三的账户上扣减 100 元,并向 Actor CMB 发送一条消息:“张三向李四转账100 元”;

  2. Actor CMB 收到消息,在李四的账户上增加 100 元,然后向 Actor ICBC 发送一条消息“李四已收到张三汇入的 100 元”;

  3. Actor ICBC 收到消息,记录好:“张三向李四转账 100 元,已成功”。

上面只是“一切都好”的过程。但是,如果某个步骤,比如说第二个步骤,“在李四的账户上增加 100 元”,出现了问题,怎么办?

开发者需要针对这个可能发生的问题,编写这样的处理逻辑:

  • Actor CMB 向 Actor ICBC 发送一条消息:“张三向李四转账 100 元,处理失败”。

  • Actor ICBC 收到消息,在张三的账户上增加 100 元,并记录:“张三向李四转账 100 元,已失败”。

程序这样写,我们称之为采用最终一致性模型。

以上,非技术读者应该能直观感受到开发单体架构的应用与开发 MSA 应用之间在工作量上的巨大差异了吧? 要知道,上面所说的转账示例只是一个非常简单的应用而已,如果我们把它称之为应用,而不是功能的话。大型应用里面的功能往往比这样的例子要复杂的太多。

这个微服务应该多大?

换句话说,"这个微服务是不是太大了,应该一分为二?”

很不幸,这个问题没有标准答案,它是一门艺术😂。微服务越小,就越容易通过创建新实例并按需移动它们来优化系统。但是,微服务越小,开发人员就越难实施复杂的流程,正如上面展示的那样。

对了,将一个应用拆分为多个微服务,从数据库设计角度看,即所谓的“分片(Sharding)”。微服务架构的最佳实践之一,就是每个微服务仅使用一个属于自己的本地数据库。简单来说,分片允许水平扩展。当数据集变得太大,无法通过传统方式处理时,除了将它们拆分成更小的片段以外,别无他法(来进行扩展)。

回到微服务的拆分问题。为了更好的践行这门艺术,我们需要掌握一些思维工具的使用。 DDD(领域驱动设计)的 “聚合(Aggregate)”就是这样一件你必须拥有的“大杀器”。 我的意思是,它能帮助你摧毁软件设计中的“核心复杂性”。

我认为聚合是 DDD 在战术层面最为重要的一个概念。

什么是聚合?聚合在对象之间,特别是实体与实体之间划出边界。一个聚合一定包含且仅包含一个聚合根实体,以及可能包含不定数量的聚合内部实体(或者叫非聚合根实体)。

我们可以使用聚合这一概念对应用所服务的领域进行分析和建模;然后在编码的时候,就可以按照聚合来切分微服务。 最简单的做法,就是将每个聚合实现为一个微服务。

不过,即使你的手艺再娴熟,这种事情你也不能保证第一次就做对。 这个时候,一件让你可以尽快对建模结果进行验证、不行就推倒重来的工具,对你来说就弥足珍贵了。

还有什么东西可能构成大型 Web2 应用迁移到 AO 生态的障碍?

我想谈谈语言和程序运行时的问题。

AO 是一个数据协议。你可以认为它是一套定义 AO 网络中的各个“单元”如何实现协作的接口规范。目前,AO 的官方实现包含了一个基于 WASM 的虚拟机环境,以及一个编译为 WASM 的 Lua 运行时环境(ao-lib),旨在简化 AO 进程的开发。

Lua 是一种小而美的语言。一般认为,Lua 的优势在于它的轻量级和易于嵌入其他语言,这使得它在特定场景(比如游戏开发)中特别有用。但是,对于开发大型互联网应用来说,Lua 语言并不是主流的选择。大型的互联网应用开发通常倾向于使用如 Java、C#、PHP、Python、JavaScript、Ruby 等语言,因为这些语言提供了更全面的生态系统和工具链,以及更广泛的社区支持。

有人可能要争论,这些语言都可以编译成 WASM 字节码,在 WASM 虚拟机里运行。但是事实上,虽然 WASM 在 Web 前端开发领域的表现很强势,但目前互联网应用采用 WASM 作为后端的运行环境并不是一个主流选择。注意,智能合约(链上程序)是 Web3 时代的“新后端”。

总结

综上,我们已经讨论了采用微服务架构(或者说 Actor 模型)的优势,以及它为应用开发带来的复杂性。有些复杂性是不可避免的。比如,即使在工程化更成熟的 Web2 环境中,基于消息通信来实现“最终一致性”对于许多开发者而言已经是不小的挑战。 在新生的 AO 平台上开发 Dapp,这个挑战似乎还要更加明显——当然这是完全可以理解的。 这个链接 文章的开篇就展示了一个例子。

我们都知道,公链之争,其实是争夺应用开发者的战争。那么,在这种情况下 AO 要如何赢得开发者?

我认为需要继续向已经获得“大规模采用”的 Web2 学习。这不仅包括学习其基础设施,还包括开发方法论、开发工具和软件工程实践等各个方面。在下一篇文章中,我会为大家展示我坚信的一种解决方案:低代码开发。


🏆 “捉虫”有奖:在本文发现错字、病句、描述有误,点我报告,可得激励。

免责声明:本文不代表 PermaDAO 的观点或立场。PermaDAO 不提供投资建议,亦不为任何项目背书。请读者遵守所在国法律,合规进行 Web3 活动。

🔗 关于 PermaDAO:Website | Twitter | Telegram | Discord | MediumYoutube

In AO
Tagged with In AO

Sign up for newsletter

Sign up here to get the latest news and updates delivered directly to your inbox.