基于演员的范式非常酷。它的有效扩展能力使其成为必须评估任何并发系统的范例。我已经阅读了一些关于它的内容，并且对核心意图有一个不错的想法：使用消息和多个“参与者”驱动昂贵的操作，以最大限度地减少由于请求/响应交互引起的等待，从而提高系统的吞吐量。然而，我还没有充分了解人们与演员一起使用的设计模式。我正在寻找基于演员的系统的设计模式。
演员设计模式的一个常见例子是一个系统，其中有一个主协调演员和一群童工演员。他们掌握将昂贵的操作映射到较小的块，将较小的块作为消息发送给一群工人，等待他们的响应，然后将它们全部归结为结果。在这种模式的一些复杂示例中，worker actor 通知 master 他们已准备好进行更多工作，并且 master 会按需路由给他们更多工作。这确保了工作的适当平衡，并且在工作规模变化很大时很有用。
我四处搜索有关更多基于演员的模式的文献，但除了上述示例外，还找不到任何示例。我还没有浏览 Akka Actors 项目示例，但任何指针都会非常有用。
我强烈推荐 Derek Wyatt 的“ Akka Concurrency ”一书——它专注于最新的 Akka 发行版 (2.1)，并介绍了使用 Akka 的几个最佳实践和许多设计模式（强调事件驱动设计）。然而，它确实假设了相当多的 Scala 知识。
Akka Summer of Blog系列的帖子也很有帮助（其中几篇也是由 Derek [和我写的一篇]）。
首先，熟悉http://en.wikipedia.org/wiki/Flow-based_programming和http://en.wikipedia.org/wiki/Dataflow_programming。Actor 模型是数据流编程的一个子集，Actor 模型的实现更加受限。
我只是对类似问题给出了更详细的答案，但我将在这里总结我发现的关于 Actor 模型的最有趣的资源。
设计模式：
反应性演员和 DDD：
Proto Actor（由 Akka 的一位创作者在 Alexey Zimarev 的帮助下进行的项目）。我发现这个项目比 Akka 更容易理解，Akka 非常复杂（我与他们没有从属关系，但考虑使用）：
然后在 Github actor-model主题上搜索可能会产生有趣的东西。
我在 QCon Video Actors or Not: Async Event Architectures中找到了更多书籍推荐：
值得一提的是这里有关企业集成模式 ( http://www.eaipatterns.com/ ) 的工作。完全有可能在他们的作品中从未提及“演员”这个词，但是从队列处理器到演员的翻译是微不足道的，就像将坡从英语翻译成法语一样。像您描述的负载平衡模式是您在那里学到的最少的东西。
我发现了更多关于基于事件的编程的文献。
http://www.amazon.com/Event-Based-Programming-Taking-Events-Limit/dp/1590596439/ref=pd_rhf_ee_s_cp_8
关于基于事件的交互模式的章节似乎很有希望