构建基于 Actor 的系统的设计模式/最佳实践

Posted 2023-03-15

技术标签:

【中文标题】构建基于 Actor 的系统的设计模式/最佳实践【英文标题】：Design patterns/best practice for building Actor-based system 【发布时间】：2011-04-25 07:46:17 【问题描述】：

我正在努力寻找设计模式、最佳实践或良好的基本架构原则的任何体面链接，这些链接应该用于构建基于 Actor 的应用程序。我所知道的少数是：

博客文章、文章、WIKI、指南

OTP Design Principles User's Guide Patterns and Best Practices for Enterprise Integration（一般来说，可以应用于任何消息驱动的架构）系列posts by James Iry on dealing with state in design with actors Ittay Dror 的posts on design with Scala actors 系列 Concurrency patterns***上的文章 Scalable System Design Patterns（与演员没有直接关系，但很有用）了解 Actor 并发性，pt.1，pt.2，作者：Alex Miller

论文

Disseration on making reliable distributed systems 乔·阿姆斯特朗 Scalabale Component Abstractions Philipp Haller 和 Martin Odersky Event-based programming without inversion of control Martin Odersky 和 Matthias Zenger Actors with Multi-Headed Message Receive Patterns by Martin Sulzmann

书籍

Actors In Scala Philipp Haller 和 Frank Sommers Programming Erlang 乔·阿姆斯特朗（Joe Armstrong） Erlang and OTP in Action Martin Logan、Eric Merritt 和 Richard Carlsson

实现

Akka Framework（Scala 中 Actor 的替代实现，带有几个 Erlang 行为的端口和许多其他相关的 Actor 模式） Scalaz Actors（演员组成、策略和承诺）

演示文稿

Actor Thinking 戴尔舒马赫 1000 Year-old Design Patterns 乌尔夫·威格 Actor-based Programming Jamie Ridgway Школа Актерского Мастерства by Vasil Remeniuk

来自 highscalability.com 的示例

Simple queuing service (SQS) - 此服务提供互联网规模的队列服务来存储消息。分布式参与者将工作放入队列并从队列中取出工作。典型用途：集中式工作队列。您将作业放在队列中，不同的参与者可以弹出队列的工作并在获得 CPU 时间时处理它们。可扩展性的一部分。有任意数量的生产者和消费者。你不用担心。队列分布在多台机器和多个数据中心。

【问题讨论】：

Design patterns for Agent / Actor based concurrent design.的可能重复 Scala actors - worst practices?的可能重复上述问题中的链接 posts on design with Scala actors 不起作用。！我在Actor design pattern and real-world examples 中提供了更多额外资源和解释，我在Design Patterns with Actors 中进行了总结。 【参考方案1】：

Manning 正在编写“反应式设计模式”一书。

见：https://www.manning.com/books/reactive-design-patterns

【讨论】：

【参考方案2】：

几周前，我在 Scala 的 learnings of actor development 上发布了一篇博客。根据几年的范式经验，这是一篇关于最佳实践和应避免的事情的帖子。

【讨论】：

【参考方案3】：

这与previous question 相关，如果不是完全一样！

这不是一个简单的问题，因为并发的参与者模型允许构建许多不同类型的应用程序，从有状态的单 VM 应用程序（具有几个单独的参与者类）到由数千个参与者类实例组成的无状态集群。

但核心原则是相同的：

永远不要暴露演员的状态仅通过传递不可变消息进行通信

【讨论】：