Actor 设计模式和现实世界的例子 [英] Actor design pattern and real-world examples
问题描述
我目前正在学习 Actor 设计模式或模型，看起来很有趣.但是，我正在努力寻找有关如何或在何处应用此模型的任何体面的现实示例(除了具有余额的简单银行帐户或游戏的敌人坐标等的基本示例).
作为我研究的一部分，我遇到了一个示例电子商务微服务应用程序 (eShopOnDapr)，其中 Order 是一个 Actor.这是可以使用 Actor 模型的真实示例吗?
这种设计模式是否可以或应该与微服务一起使用?使用上面的示例，Ordering 服务仅处理订单，而不处理产品或客户等.对我来说，订单可能是 Actor 是有道理的，但使用其他技术构建服务是否更好，例如使用 CQRS，甚至只是基本的状态管理(创建一个 Order 的实例并在每次更新时记录它的状态)
正如你所看到的，我仍然需要学习设计模式这一领域，但如果有人能指点我一些好的 doco 或 YouTube 剪辑，这很好地解释了这些事情，那就太好了——世界的例子.
如果您的应用程序相对简单，并且可以是例如一个同步的 CRUD REST 应用程序，那么actor 模型可能有点矫枉过正.
对于更大、更复杂的领域，Actor 模型具有更多活动部分，可以简化您对应用的看法，并能够将其分解为组成部分.有很多架构考虑因素和选项需要考虑，它们在很大程度上取决于您的特定用例和非功能性要求 (NFR).
正如@levi-ramsey 在他的回答中所说，CQRS可能除了用于演员，但是是可选的.添加它是一个独立的选择.事件溯源 (ES) 也是如此，例如领域驱动设计 (DDD).
演员模型有用的一些 NFR 是分布(演员的位置透明性)和弹性(委托给子演员，让他们崩溃"，主管可能会重新启动或升级错误).Actor 模型可以抽象出很多网络管道，这在微服务架构中是一个福音.
根据领域复杂性、业务逻辑、对模块化/可扩展性的需求、可扩展性等，结合各种架构实践更有意义，例如 Actors/DDD/CQRS/ES 和六边形架构.但前提是您的应用有保证.它们各有优缺点(例如微服务和事件溯源中的最终一致性").
上述组合见于分布式 DDD(DDDD)，也称为反应式 DDD.在这里可以找到 Vaughn Vernon 的一些不错的视频，例如在反应式系统中使用具有领域驱动设计 (DDD) 的 Actor 模型(他转向域聚合为演员)，以及 DDD、事件溯源和演员中的 Alexey Zimarev(他将actor逻辑放在应用层).
您会发现很多与 Akka 相关的材料.他们有很好的文档材料.我个人觉得 proto.actor 很有趣，由 Akka 创始人之一创建，团队中有 Alexey 成员.>
在设计模式方面这篇文章认识顶级 Akka.NET 设计模式 是一个好的开始.Akka 文档中有一个部分是关于交互模式.虽然我没有读过，但我认为 Applied Akka Patterns O'Reilly 的书相当不错.
在示例代码方面，Github actor-model 主题可能会导致一些伟大的项目学习，也例如Proto Actor 项目有一大堆 Golang 示例 或
I’m currently learning about the Actor design pattern, or model, and it seems quite interesting. However, I’m struggling to find any decent real-world examples of how, or where, this model could be applied (other than the basic examples of a simple bank account with a balance, or Enemy coordinates for a game, etc).
As part of my research I came across a sample e-commerce microservice application (eShopOnDapr) where the Order was an Actor. Would this be a real-world example of where the Actor model could be used?
Can this, or should this, design pattern be used with microservices? Using the example above, the Ordering service only deals with an Order, but not products or customers, etc. It makes sense to me that an Order might be an Actor, but is it better to just build the service using some other technique, like using CQRS, or even just basic state management (create an instance of an Order and record it’s state each time it’s updated)
As you can see I still have a fair bit of learning to do is this area of design patterns but it would great if anyone could point me to some good doco, or YouTube clips, that explains these things with some good real-world examples.
If your app is relatively straightforward, and it could be e.g. a synchronous CRUD REST app, then actor model may be overkill.
For larger more complex domains, with more moving parts the Actor Model may ease how you think about your app and are able to break it down into constituent parts. There are plenty of architectural considerations and options to take into account, and they largely depend on your specific use cases and non-functional requirements (NFR's).
As @levi-ramsey says in his answer CQRS might be used in addition to actors, but is optional. It is an independent choice to add it. So too are Event Sourcing (ES) and e.g. Domain-Driven Design (DDD).
Some NFR's where actor model is helpful are distribution (location-transparency of actors) and resiliency (delegate to child actors, and "just let them crash" where a supervisor may restart or escalate errors). Actor model may abstract away a lot of network plumbing which is a boon in microservices architectures.
Depending on domain complexity, business logic, need for modularity/extensibility, scalability etc. it makes more sense to combine various architectural practices, such as Actors/DDD/CQRS/ES and hexagonal architecture. But only if your app warrants it.. they each have their pros and cons (like 'eventual consistency' in microservices and event sourcing).
The above combination is found in Distributed DDD (DDDD), also called Reactive DDD. There's some good videos by Vaughn Vernon to be found here e.g. Using the Actor Model with Domain-Driven Design (DDD) in Reactive Systems (he turns domain aggregates into actors), and also Alexey Zimarev in DDD, Event Sourcing and Actors (he places the actor logic in the application layer).
You'll find lots Akka-related material. They have good documentation material. Personally I find proto.actor interesting, created by one of the Akka founders, and with Alexey part of the team.
In terms of design patterns this article Meet the Top Akka.NET Design Patterns is a good start. The Akka documentation has a section on Interaction Patterns. Though I haven't read it, I think Applied Akka Patterns book by O'Reilly is quite good.
In terms of example code the Github actor-model topic may lead to some great projects to learn from, and also e.g. the Proto Actor project has a big list of Golang examples or DotNet examples to apply from, and a Bootcamp course.
这篇关于Actor 设计模式和现实世界的例子的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
