我觉得在Scala中使用actor有点不安全.我已经阅读了有关如何做东西的文档,但我想我还需要一些DO NOT规则才能随意使用它们.我想我会害怕以错误的方式使用它们,我甚至都不会注意到它.
你能想到一些东西,如果应用的话,会导致Scala演员带来的好处,甚至是错误的结果吗？
最近我开始使用支持演员/代理/无共享架构的替代语言 - 即.scala,clojure等(clojure也支持共享状态).
到目前为止,我所阅读的大部分文档都集中在介绍级别.我正在寻找的是四人帮中更高级的文档,而不是基于什么共享.
为什么？它有助于改变设计思维的变化.简单的例子很简单,但在现实世界的Java应用程序(单线程)中,您可以拥有1000个具有复杂关系的成员的对象图.但是,基于代理的并发开发,它在设计大型系统时引入了一整套全新的思路.即.代理粒度 - 一个代理应管理多少状态 - 对性能的影响等,或者是将共享状态对象图映射到基于代理的系统的良好模式.将域模型映射到设计的技巧.讨论不是关于技术,而是关于如何在设计中最好地使用该技术(现实世界"复杂"的例子会很棒).
我\xe2\x80\x99m 目前正在学习Actor 设计模式或模型，它看起来很有趣。然而，我\xe2\x80\x99m正在努力寻找任何像样的现实世界示例来说明如何或在何处应用此模型（除了带有余额的简单银行帐户或游戏的敌人坐标的基本示例之外） ， ETC）。
\n作为我研究的一部分，我遇到了一个示例电子商务微服务应用程序 (eShopOnDapr)，其中订单是一个 Actor。这是否是一个可以使用 Actor 模型的真实示例？
\n这种设计模式可以或者应该与微服务一起使用吗？使用上面的示例，订购服务仅处理订单，而不处理产品或客户等。对我来说，订单可能是参与者是有道理的，但最好使用其他技术构建服务，例如使用 CQRS，甚至只是基本状态管理（创建一个 Order 实例并在每次更新时记录它\xe2\x80\x99s 状态）
\n正如你所看到的，在设计模式的这个领域，我还有很多东西需要学习，但如果有人能给我指出一些好的 doco 或 YouTube 剪辑，用一些很好的现实世界例子来解释这些事情，那就太好了。
\n基于演员的范式非常酷.它有效扩展的能力使其成为必须评估任何并发系统的范例.我已经做了一些关于它的阅读,并且对核心意图有了一个不错的想法:用消息和多个"参与者"驱动昂贵的操作,以最大限度地减少因请求/响应交互而导致的等待,从而提高系统的吞吐量.但是,我没有充分了解人们与演员使用的设计模式.我正在寻找基于演员的系统的设计模式.
演员设计模式的一个常见示例是一个系统,其中有一个主协调员角色和一群童工角色.他们掌握将昂贵的操作映射到较小的块,将较小的块作为消息发送给一堆工作者,等待来自它们的响应,然后将它们全部减少到结果.在这种模式的一些复杂的例子中,工作者通知主人他们已经准备好做更多的工作,并且主人的路线更多地按需工作.这确保了适当的工作平衡,并且在工作规模变化很大时非常有用.
我搜索了更多基于演员的模式的文献,除了上面的例子之外找不到任何其他例子.我还没有通过Akka Actors项目样本,但任何指针都非常有用.