问题描述
我目前正在学习 Actor 设计模式或模型，看起来很有趣。但是，我正在努力寻找有关如何或在何处应用此模型的任何体面的现实示例（除了具有余额的简单银行帐户或游戏的敌人坐标等的基本示例）。
作为我研究的一部分，我遇到了一个示例电子商务微服务应用程序 (eShopOnDapr)，其中 Order 是一个 Actor。这是可以使用 Actor 模型的真实示例吗？
这种设计模式是否可以或应该与微服务一起使用？使用上面的示例，Ordering 服务仅处理订单，而不处理产品或客户等。对我来说，订单可能是 Actor 是有道理的，但使用其他技术构建服务是否更好，例如使用 CQRS，甚至只是基本的状态管理（创建一个 Order 的实例并在每次更新时记录它的状态）
正如你所看到的，我仍然需要学习设计模式这一领域，但如果有人能指点我一些好的 doco 或 YouTube 剪辑，这很好地解释了这些事情，那就太好了——世界的例子。
解决方法
actor 模型对微服务具有高度的机械同情，尽管它更适用于思考服务的实现。
它同样不是 CQRS 独有的。
如果您正在寻找一个在微服务中使用参与者模型以及事件溯源和 CQRS 的好例子，则是 Lightbend's Akka Platform Guide。
,如果您的应用程序相对简单，并且可以是例如一个同步的 CRUD REST 应用程序，那么actor 模型可能有点矫枉过正。
对于更大、更复杂的领域，Actor 模型具有更多活动部分，可以简化您对应用的看法，并能够将其分解为组成部分。有很多架构考虑因素和选项需要考虑，它们在很大程度上取决于您的特定用例和非功能性要求 (NFR)。
正如@levi-ramsey 在 his answer CQRS 中所说的那样，可能除了演员之外还可以使用，但它是可选的。添加它是一个独立的选择。事件溯源 (ES) 也是如此，例如领域驱动设计 (DDD)。
演员模型有用的一些 NFR 是分布（演员的位置透明性）和弹性（委托给子演员，“让他们崩溃”，主管可能会重新启动或升级错误）。 Actor 模型可以抽象出很多网络管道，这在微服务架构中是一个福音。
根据领域复杂性、业务逻辑、对模块化/可扩展性的需求、可扩展性等，结合各种架构实践更有意义，例如 Actors/DDD/CQRS/ES 和六边形架构。但前提是您的应用有保证。它们各有优缺点（例如微服务和事件溯源中的“最终一致性”）。
上述组合见于分布式 DDD（DDDD），也称为反应式 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 的部分。虽然我没有读过，但我认为 O'Reilly 的 Applied Akka Patterns 书相当不错。
就示例代码而言，Github actor-model 主题可能会导致一些很棒的项目可供学习，例如Proto Actor 项目有一个很大的 Golang examples 或 DotNet examples 列表可供申请，还有一个 Bootcamp course。