我目前正在学习Actor设计模式或模型，它看起来很有趣。然而，我很难找到任何关于如何或在哪里应用这个模型的真实例子(除了一个有余额的简单银行账户或游戏的敌人坐标等的基本例子)。
作为我研究的一部分，我发现了一个示例电子商务微服务应用程序(eShopOnDapr)，其中Order是Actor。这会是一个现实世界中可以使用Actor模型的例子吗？
这种设计模式可以或者应该与微服务一起使用吗？使用上面的例子，Ordering服务只处理订单，而不处理产品或客户等。对我来说，订单可能是一个参与者是有道理的，但最好使用其他技术来构建服务，比如使用CQRS，甚至只是基本的状态管理(创建订单的实例，并在每次更新时记录其状态)
正如你所看到的，在设计模式的这一领域，我还有相当多的学习要做，但如果有人能给我指一些好的纪录片或YouTube剪辑，用一些好的现实世界例子来解释这些事情，那就太好了。
如果你的应用程序相对简单，而且它可能是一个同步的CRUD REST应用程序，那么actor模型可能有些过头了。
对于更大、更复杂的域，有了更多可移动的部分，Actor Model可以简化你对应用程序的思考，并能够将其分解为组成部分。有很多体系结构考虑因素和选项需要考虑，它们在很大程度上取决于您的特定用例和非功能需求(NFR)。
正如@levi ramsey在他的回答中所说，除了演员之外，CQRS可能也会使用，但这是可选的。添加它是一个独立的选择。事件源(ES)和领域驱动设计(DDD)也是如此。
演员模型有帮助的一些NFR是分布(演员的位置透明度)和弹性(委托给儿童演员，"让他们崩溃"，主管可能会重新启动或升级错误)。Actor模型可能会抽象出许多网络管道，这在微服务架构中是一个福音。
根据领域复杂性、业务逻辑、模块化/可扩展性需求、可扩展性等，将各种架构实践(如Actors/DDD/CQRS/ES和六边形架构)结合起来更有意义。但前提是你的应用程序有保证。它们各有利弊(比如微服务和事件来源的"最终一致性")。
上述组合可在分布式DDD(DDDD)中找到，也称为反应性DDD。Vaughn Vernon的一些好视频可以在这里找到，例如在反应系统中使用具有域驱动设计(DDD)的参与者模型(他将域聚合转化为参与者)，以及在DDD、事件源和参与者中使用Alexey Zimarev(他将参与者逻辑放在应用层中)。
你会发现很多与阿卡有关的材料。他们有很好的文件材料。就我个人而言，我觉得proto.actor很有趣，它是由Akka的创始人之一创建的，Alexey是团队的一员。
在设计模式方面，本文Meet the Top Akka.NET设计模式是一个良好的开端。Akka文档中有一节是关于交互模式的。虽然我还没读过，但我觉得奥的《应用阿卡模式》一书还是很不错的。
在示例代码方面，Github actor模型主题可能会带来一些值得学习的伟大项目，例如Proto-actor项目有一大堆Golang示例或DotNet示例可供应用，还有一个训练营课程。
actor模型与微服务有着高度的机械同情，尽管它往往更适用于思考服务的实现。
它同样不是CQRS独有的。
如果你正在寻找一个在微服务中使用参与者模型以及事件源和CQRS的好例子，那就是Lightbend的Akka平台指南。
我要把这个唤醒，因为我来到这里是因为我正在审查@dazfl的确切内容，并试图弄清楚我是纯粹主义者，还是使用演员不合适。你知道，就像用钳子钉钉子一样。它有效，但你应该这样做吗？
我通过Azure Service Fabric中的Reliable Actors框架进入了actor模型。在我自己应用之前，我总是试图准确地理解一个想法的发起者的想法。我读过卡尔·休伊特的博士论文，然后是他80年代中期一位研究生的一篇更为有力的论文。
我得出的结论之一是，一个合适的actor应用程序将有许多消息类型有限的小actor。将参与者视为消息的接收者而不是被称为对象，这一点非常重要。如果没有这种心态的转变，actor实现最终看起来就像任何其他形式的分布式应用程序。我们都知道要想做好这些事情有多么棘手。
eStoreOnDapr订单服务没有很好地利用actor模型。它很管用，但演员们不会给派对带来任何东西。我认为作者正在使用基于回合的模型来简化一些事情，这很好。但这只触及了该模型给聚会带来的东西的表面，不值得为该用例学习。