演员设计模式和真实世界的例子答案

【问题标题】：Actor design pattern and real-world examples演员设计模式和真实世界的例子
【发布时间】：2021-05-15 03:48:16
【问题描述】：

我目前正在学习 Actor 设计模式或模型，这似乎很有趣。但是，我正在努力寻找任何体面的真实世界示例，说明如何或在何处应用此模型（除了带有余额的简单银行帐户的基本示例，或游戏的敌人坐标等）。

作为我研究的一部分，我遇到了一个示例电子商务微服务应用程序 (eShopOnDapr)，其中 Order 是一个 Actor。这会是一个可以使用 Actor 模型的真实示例吗？

这种设计模式可以或应该与微服务一起使用吗？使用上面的示例，Ordering 服务仅处理订单，而不处理产品或客户等。对我来说，订单可能是一个演员是有道理的，但是使用其他技术构建服务是否更好，例如使用 CQRS，甚至只是基本的状态管理（创建一个 Order 实例并在每次更新时记录它的状态）

如您所见，我仍然需要学习设计模式这一领域的知识，但如果有人能指点我一些好的文档或 YouTube 剪辑，那就太好了，它们可以用一些很好的真实来解释这些事情-世界的例子。

【问题讨论】：

【解决方案1】：

如果您的应用程序相对简单，它可能是例如一个同步的 CRUD REST 应用程序，那么 Actor 模型可能是矫枉过正。

对于更大更复杂的领域，具有更多移动部分的 Actor 模型可以简化您对应用的看法，并能够将其分解为组成部分。有很多架构方面的考虑和选项需要考虑，它们在很大程度上取决于您的特定用例和非功能性要求 (NFR)。

正如@levi-ramsey 在his answer 中所说，CQRS 可能除了演员之外还可以使用，但它是可选的。添加它是一个独立的选择。事件溯源（ES）也是如此，例如领域驱动设计 (DDD)。

一些 NFR 对 Actor 模型有帮助的地方是分布（Actor 的位置透明性）和弹性（委托给子 Actor，以及“让他们崩溃”，主管可能会重新启动或升级错误）。 Actor 模型可以抽象出许多网络管道，这对微服务架构来说是一个福音。

根据领域复杂性、业务逻辑、模块化/可扩展性需求、可扩展性等，结合各种架构实践更有意义，例如 Actors/DDD/CQRS/ES 和六边形架构。但前提是您的应用需要这样做。它们各有优缺点（例如微服务和事件溯源中的“最终一致性”）。

上述组合见于分布式 DDD (DDDD)，也称为 Reactive DDD。在这里可以找到 Vaughn Vernon 的一些好视频，例如Using the Actor Model with Domain-Driven Design (DDD) in Reactive Systems（他将域聚合转换为参与者），还有 DDD, Event Sourcing and Actors 中的 Alexey Zimarev（他将参与者逻辑放在应用层中）。

您会发现很多与 Akka 相关的材料。他们有很好的文档资料。就我个人而言，我觉得 proto.actor 很有趣，它由 Akka 的一位创始人创建，并且与 Alexey 是团队的一员。

就设计模式而言，这篇文章Meet the Top Akka.NET Design Patterns 是一个好的开始。 Akka 文档有一个关于 Interaction Patterns 的部分。虽然没看过，但我觉得Applied Akka Patterns O'Reilly 的书还是不错的。

就示例代码而言，Github actor-model 主题可能会导致一些很棒的项目可供学习，例如Proto Actor 项目有一大串 Golang examples 或 DotNet examples 可供申请，还有一个 Bootcamp course。

【讨论】：

【解决方案2】：

actor 模型对微服务有着高度的机械共鸣，尽管它往往更适用于思考服务的实现。

它同样不是 CQRS 独有的。

如果您正在寻找一个在微服务中使用 Actor 模型以及事件溯源和 CQRS 的好例子，请点击 Lightbend's Akka Platform Guide。

【讨论】：

感谢@levi-ramsey 的链接。这很有趣。我正在努力确定何时使用，而不是使用 Actor 模式。在购物车示例中，购物车是一个 Actor，但是 Products 呢？产品可以成为演员吗？还是客户？
一般来说，任何具有可以改变状态的东西都可以很好地建模为参与者（几乎任何领域对象都可以）。将产品建模为特定服务中的参与者是否是一个好主意取决于服务。在购物车服务中，可能不希望在购物车中更改项目描述等，这可能没有意义，但在目录服务中处理命令以更新产品描述、价格等。演员可能非常棒适合（我个人会说是，但我喝过演员模特koolaid :)）。

【解决方案3】：

我要唤醒这个人，因为我在这里结束了，因为我正在审查 @dazfl 的确切内容，并试图弄清楚我是否只是一个纯粹主义者，或者是否使用演员是不合适的.你知道，就像用钳子钉钉子一样。它有效，但你应该这样做吗？

我通过 Azure Service Fabric 中的 Reliable Actors 框架进入了 Actor 模型。在自己应用一个想法之前，我总是试图准确地理解一个想法的创始人的想法。我已经阅读了 Carl Hewitt 的博士论文，然后是他 80 年代中期的一位研究生的更有说服力的论文。

我得出的结论之一是，一个合适的 Actor 应用程序将包含大量具有有限消息类型的小 Actor。将参与者视为消息的接收者而不是被称为对象是非常重要的。如果没有这种思维方式的转变，actor 实现最终看起来就像任何其他形式的分布式应用程序一样。我们都知道要做好这些是多么棘手。

eStoreOnDapr 订单服务没有很好地利用 Actor 模型。它有效，但演员不会为派对带来任何东西。我认为作者正在使用回合制模型来简化一些很好的事情。但只是触及模型为聚会带来的东西的表面，不值得为该用例付出学习曲线。

【讨论】：