【译】虚拟演员：Dapr vs Orleans

小渣渣

在过去的一周里，我通过研究虚拟演员的概念踏入了软件开发领域。我最终研究了两个不同的框架：Dapr和Orleans。

两者都是非常简洁的项目，有大量有趣的用例。两者都使用“虚拟”演员的想法。虚拟演员是一个状态和逻辑单元，它：

• 可以通过id唯一标识
• 是单线程的
• 可以在内存中或持久化 - 它的生命周期由框架管理
  

我真的很喜欢虚拟演员的想法，并且觉得它们对我构建可扩展且可靠的工具来处理复杂任务工作流的探索非常有帮助。如果每个任务都是单线程虚拟参与者，那么竞争条件问题就会消失。

因为 Orleans 和 Dapr 都是 Microsoft 项目，所以我设想有一天在 Microsoft 自助餐厅进行西部故事风格的对决。

Orleans

我从 Orleans 开始，因为在 YouTube 上看到一些关于它的视频后，它已经出现在我的雷达上一段时间了。它的开始真的很糟糕，因为我想我会使用他们所有 NuGet 包的 4.x 版本。然而，他们的文档绝对没有一个适用于 4.x 包。我最终使用的是 3.6.2 版本。

Grains / State / Timers

创建一个跟踪其自身状态并执行操作的 grain 非常简单。我什至能够遵循谷物持久性的文档并创建我自己的 IGrainStorage 的 CosmosDB（SQL API）实现。

Reminders

提醒也很容易设置。直到我尝试为他们配置真实世界的持久性。在我研究的这一点上，我试图保持一切整洁，并将所有内容存储在 ComsosDB 中。不幸的是，我根本无法让 Orleans 的提醒持久性包工作。我最终不得不改用AzureStorage包。所以现在我的数据一半在 SQL API 帐户中，一半在表 API 帐户中。

Streams

这就是我不顺利的地方。在 Orleans 中，流是用 GUID 和可选的命名空间来标识的。我敢肯定，流必须由 GUID 标识是有充分理由的，但哇，这是不切实际的。

我对流感到非常沮丧，因为我能够轻松地创建它们，但是一旦我停止并重新启动我的项目并触发一个新事件，一切都会崩溃。

接下来是一条非常有价值的信息，因为我花了 8 个小时对 Orleans 代码进行逆向工程才弄清楚：

当 grain 是流订阅者时，该 grain 必须在其 OnActivateAsync 方法中的订阅句柄上调用 ResumeAsync，否则您将因无法辨认的错误而崩溃。

登录可见。

我还遇到了相同订阅被复制的问题，所以我使用代码删除了所有 grain 的订阅，然后重新创建它：

登录可见。

Other Orleans Gotchas / Tips

Streams 与 Azure 事件中心一起工作得很好（通过 AddEventHubStreams）。

不要在 CosmosDB SQL API 的 grain 名称中使用 / 或其他特殊字符！

Orleans 结论

我喜欢 Orleans ，我认为它有潜力。但是，它的学习曲线非常陡峭。由于我与流的长期斗争，我没有时间研究集群/部署是如何工作的。

Dapr

我通过寻找 Orleans 的替代品找到了 Dapr。有点奇怪的是它也是微软赞助的项目。也许他们在这里采取适者生存的方法。如果是，我认为 Dapr 将成为幸存者。

首先，Dapr 基于 REST/gRPC 的设计允许使用任何编程语言实现 actor。我还发现在单个 Redis 实例上运行所有内容（参与者、状态、计时器、提醒、事件）是微不足道的。最重要的是，我只花了大约三分之一的时间就开始使用 Dapr。如此快速的启动时间归功于 Dapr 出色的文档。

Actors / Timers / Reminders

我刚才是说 Dapr 的文档很棒吗？好吧，它无处不在，除了 JavaScript 示例。我大部分时间都花在 Dapr 上，试图弄清楚如何在 actor 上调用方法。Dapr Javascript 示例的代码如下：

登录可见。

这显然已经过时了。我不得不花费大量时间通过 Dapr 的测试/示例代码探索来哄骗这三行

登录可见。

获取/设置状态的代码示例也存在类似问题，因此我为它们创建了一个GitHub 问题。

除了那些小问题，设置演员是小菜一碟。

为我的演员设置计时器和提醒也非常简单。

State

我能够非常轻松地将 Dapr 配置为使用 Postgres 进行持久化。

我注意到的一件事是提醒的存储方式可能存在可扩展性问题。Dapr 将特定参与者类型的所有提醒存储在单个 JSON 数组中。有人有大量提醒会发生什么？



Other Dapr Gotchas / Tips

在浏览 JavaScript SDK 的代码时我注意到的一件事是代码库中根本没有很多注释。这使得弄清楚一些事情几乎是不可能的。例如，在状态管理器的 addOrUpdateState 方法中，有一个名为updateValueFactory的第三个参数。如果代码中没有任何注释，则几乎不可能分辨出该回调的用途。

我也不确定我有多喜欢“dapr init”命令尝试为我设置和运行一个 redis 容器。如果我已经有一个 redis 容器怎么办？如果我想改用 postgres 怎么办？我找不到解释如何更改 dapr init 功能的文档。

任何在使用 pubsub 时遇到问题的人的注意事项。您必须使用“dapr run”同时运行您的发布者和订阅者：

登录可见。

对于 actors 和 pubsub 请注意，使用 --app-port 参数让 dapr 知道您的服务正在运行的端口很重要。pubsub 事件和 actor 调用通过 http 调用从 Dapr sidecar 发送到您的服务，因此它需要知道将它们发送到哪里：

登录可见。

我通过在我的家庭网络上的两台不同机器上启动我的 pubsub 订阅者实例来测试一个小型 Dapr 自托管“集群”。它刚刚起作用！

Dapr 结论

如果你想了解更多关于分布式应用程序或虚拟演员的想法，我建议你从 Dapr 开始。Orleans 是最初的开拓者，而 Dapr 是将事情提升到一个新水平的重启。

原文链接：https://dev.to/aaronblondeau/virtual-actors-dapr-vs-orleans-30f0

小渣渣

Microsoft Orleans

Orleans 是一个跨平台框架，用于构建可靠且可缩放的分布式应用程序。 分布式应用程序定义为跨多个进程的应用，通常使用对等通信来超越硬件边界。 Orleans 从单个本地服务器扩展到了云中成百上千的分布式、高度可用的应用程序。 Orleans 将熟悉的概念和 C# 习语扩展到了多服务器环境。 Orleans 在设计上可弹性缩放。 当主机加入群集时，它可以接受新的激活。 当主机因纵向缩减或计算机故障而退出群集时，该主机上的先前激活将根据需要在其余主机上重新激活。 Orleans 群集可以纵向缩减为单个主机。 用于启用弹性缩放的相同属性也会启用容错。 群集可自动检测故障并快速从故障中恢复。

Orleans 的主要设计目标之一是通过提供一组通用模式和 API 来简化分布式应用程序开发的复杂性。 熟悉单一服务器应用程序开发的开发人员可以轻松地改为使用 Orleans 构建可复原、可缩放的云原生服务和其他分布式应用程序。 因此，Orleans 经常被称为“分布式 .NET”，并且是用于构建云原生应用的首选框架。 Orleans 可以在支持 .NET 的任意位置运行。 这包括将它托管在 Linux、Windows 和 macOS 上。 Orleans 应用可以部署到 Kubernetes、虚拟机和 PaaS 服务，例如 Azure 应用服务和 Azure 容器应用。

文档：https://learn.microsoft.com/zh-cn/dotnet/orleans/overview