参与者如何在复杂的后端服务中使用，这些服务包括接收初始请求、进行一些处理、然后向其他服务发送一些请求/待办事项、等待其中一些服务的响应，并决定如何继续基于响应，等等，直到我们计算出最终结果？
尝试使用参与者来实现此类服务提出了一个问题——该工作流的哪些部分应该由参与者实现，哪些部分不应该？
Actor 实例在他们尝试完成的任务完成之前不会释放他们正在使用的线程（除非我们将它委托给 Future），所以在我看来，它就像将整个工作流程编写为越来越小的 Actor 的层次结构， N 层子节点，一方面是基于 Actor 概念的理想设计，但另一方面它会保持 N-1 个线程（每个初始请求） - 不断锁定，只在底部等待一个层次结构中的演员来完成。具体来说，层次结构中最顶层的参与者大部分时间都是空闲的。
这种分层设计也匹配错误内核模式。
但这听起来对并发性非常不利。
即使你试图保持这种演员的层次结构，但在未来包装对每个演员的调用（通过询问子演员，而不是告诉），所以锁定会更短（尽管它仍然存在） - 仍然有效有这么多的 Futures 使得不可能与有状态的参与者合作，或者无法以自己不同步的方式修改系统状态的参与者（即不简单地修改数据库，至少对于简单的请求来说，这是通过数据库自动完成的事务 - 而是修改应用程序中的一些全局变量）。
那么演员应该只在工作流的较低级别使用吗？
或者应该以更连续的方式重写主要是分层的（并且大多数是）的工作流，因此它不需要这么多级别的子角色（但这将非常困难和不自然，并且似乎也提供了实现框架对设计影响很大）。
这意味着您认识到参与者是非常有限的，并且容错应该主要由传统的异常处理来处理，并且无论如何，拥有容错应用程序的愿望不应该对设计产生太大影响应用。既然如此，何必找演员呢？使用一个需要阅读每个参与者的实现以理解复杂的意大利面条状消息结的工作流程的框架，比使用基于层次结构的框架要容易得多查看方法签名，而不必查看它们的实现。
如果只有一小部分应用程序由参与者实现，参与者的许多好处，例如易于扩展，似乎不太相关或不实用。