devise模式/build立基于Actor的系统的最佳实践
我正在努力寻找devise模式，最佳实践或良好基础build筑原则的任何体面的链接，这些原则应该用于构build基于Actor的应用程序。 我所知道的那几个是：
博客文章，文章，WIKI，指南
- OTPdevise原理用户指南
- 企业集成的模式和最佳实践 （一般来说，可以应用于任何消息驱动的体系结构）
- 詹姆斯·伊里（James Iry）在与演员合作处理状态的系列post
- 系列的devise与斯塔拉演员由Ittay Dror的职位
- 并发模式文章在维基百科
- 可扩展的系统devise模式 （与演员不直接相关，但相当有用）
- 理解actor并发性， p。1 ， p。2 ，Alex Miller
文件
- 关于由Joe Armstrong 制作可靠的分布式系统的解释
- Scalabale组件抽象由Philipp Haller和Martin Odersky提供
- 马丁·奥德斯基（Martin Odersky）和马蒂亚斯·曾格（Matthias Zenger） 的基于事件的编程，
- Martin Sulzmann的“多头消息接收模式”的演员
图书
- 斯卡拉的演员由菲利普·哈勒和弗兰克·索姆斯
- 编程由乔·阿姆斯特朗Erlang
- Erlang和OTP的Martin Logan，Eric Merritt和Richard Carlsson
实现
- Akka框架 （Scala中的angular色的替代实现，带有一些Erlang行为的端口以及许多其他的angular色扮演模式）
- 斯卡拉兹演员 （演员组成，战略和承诺）
演讲
- 演员由戴尔·舒马赫思考
- 由Ulf Wiger devise的1000年的devise模式
- 由杰米·李奇韦演员编程
- Vasil Remeniuk的ШколаАктерскогоМастерства
来自highscalability.com的例子
- 简单排队服务（SQS） – 这项服务提供了一个互联网规模排队服务来存储消息。 分布式的演员把工作放在队列上，把工作从队列中解放出来。 典型用途：集中工作队列。 将作业放在队列中，不同的actor可以popup队列的工作，并在获得CPU时间时处理它们。 部分可扩展性。 有任何数量的生产者和消费者。 你不用担心。 队列分布在多台机器和多个数据中心。
这与前面的问题有关 ，如果不完全一样的话！
这不是一个简单的问题，因为并发的actor模型允许构build多种不同types的应用程序，从一个有状态的单个VM应用程序（有几个独立的actor类）到一个包含数千个actor类的无状态集群。
但核心原则是一样的：
- 切勿暴露演员的状态
- 只通过传递不可变的消息进行沟通
几个星期前，我在Scala上发表了关于演员发展的博客。 基于几年的范式经验，这是一个最佳实践和应避免的事情。
Manning正在制作“反应式devise模式”一书。
请参阅： https : //www.manning.com/books/reactive-design-patterns
