我目前正在学习 Actor 设计模式，或者模型，它看起来很有趣。然而，我正在努力寻找任何像样的现实世界示例来说明如何或在何处应用此模型（除了带有余额的简单银行帐户或游戏的敌人坐标等的基本示例之外）。
作为我研究的一部分，我遇到了一个示例电子商务微服务应用程序 (eShopOnDapr)，其中订单是一个 Actor。这是否是一个可以使用 Actor 模型的真实示例？
这种设计模式可以或者应该与微服务一起使用吗？使用上面的示例，订购服务仅处理订单，而不处理产品或客户等。对我来说，订单可能是参与者是有意义的，但最好使用其他技术构建服务，例如使用 CQRS，甚至只是基本的状态管理（创建订单的实例并在每次更新时记录其状态）
正如你所看到的，在设计模式的这个领域，我还有很多东西需要学习，但如果有人能给我指出一些好的 doco 或 YouTube 剪辑，用一些很好的现实世界例子来解释这些事情，那就太好了。
如果您的应用程序相对简单，它可能是例如一个同步的 CRUD REST 应用程序，那么 Actor 模型可能就有点过分了。
对于更大、更复杂的领域，具有更多移动部分的 Actor 模型可以简化您对应用程序的思考，并能够将其分解为组成部分。有很多架构注意事项和选项需要考虑，它们在很大程度上取决于您的特定用例和非功能性需求 (NFR)。
正如@levi-ramsey 所说他的回答 CQRS might除了 actor 之外还可以使用，但是是可选的。添加它是一个独立的选择。事件溯源（ES）也是如此。领域驱动设计（DDD）。
参与者模型有用的一些 NFR 是分布（参与者的位置透明性）和弹性（委托给子参与者，并且“让他们崩溃”，其中主管可能会重新启动或升级错误）。 Actor 模型可以抽象出大量的网络管道，这对于微服务架构来说是一个福音。
根据领域复杂性、业务逻辑、模块化/可扩展性、可扩展性等需求，结合各种架构实践（例如 Actors/DDD/CQRS/ES 和六边形架构）更有意义。但前提是您的应用程序保证......它们各有优缺点（例如微服务和事件溯源中的“最终一致性”）。
上述组合出现在分布式 DDD (DDDD) 中，也称为响应式 DDD。在这里可以找到 Vaughn Vernon 的一些精彩视频，例如在响应式系统中使用具有领域驱动设计 (DDD) 的 Actor 模型（他将领域聚合转变为演员），还有 Alexey ZimarevDDD、事件溯源和参与者（他将参与者逻辑放在应用程序层中）。
您会发现很多与 Akka 相关的材料。他们有很好的文档材料。我个人发现原型演员有趣的是，由 Akka 创始人之一创建，Alexey 是团队的一员。
本文就设计模式而言认识顶级 Akka.NET 设计模式是一个好的开始。 Akka 文档有一节介绍交互模式。虽然我没读过，但我想应用 Akka 模式奥莱利的书相当不错。
就示例代码而言，Github演员模型主题可能会带来一些值得学习的伟大项目，例如Proto Actor 项目有一个很大的清单Go 语言示例 or 点网示例申请，以及训练营课程.
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
