问在哪里和如何在实践中使用演员

EN

如何在复杂的后端服务中使用actors，这些服务由接收初始请求、进行一些处理、然后向其他服务发送一些请求/要做的事情、等待其中一些服务的响应以及决定如何基于响应继续等组成，直到我们计算出最终结果为止？

试图使用参与者来实现这样的服务引发了一个问题--这个工作流的哪些部分应该由参与者实现，哪些部分不应该实现？

参与者实例不会释放他们正在使用的线程，直到他们试图完成的任务完成(除非我们将它委托给一个未来)，所以在我看来，它看起来就像将整个工作流写成一个层次结构，一个包含N层子层的较小的参与者组成的层次结构，一方面是基于参与者概念的理想设计，另一方面它将保持N-1线程(每个初始请求)--总是锁着什么也不做，只是等待层次结构中的底层参与者来完成。具体来说，层次结构中最顶层的参与者大部分时间都是空闲的。

这种分层设计还与error kernel模式相匹配。

但对于并发性来说，这听起来很糟糕。

即使你试图保持这种行为者的等级，但把对每个参与者的调用封装在未来(通过询问子参与者，而不是告诉)，锁也就会短得多(尽管它仍然存在)--仍然与这么多具有状态的参与者一起工作，或者那些以自己不同步的方式修改系统状态的行为者(即不只是简单地修改数据库，至少简单的请求是通过数据库事务自动完成--而是修改应用程序中的某个全局变量)。

那么，应该只在工作流的较低级别使用参与者吗？

或者应该以更连续的方式重写一个主要是分层的(而且大多数是这样的)工作流，这样它就不需要那么多级别的子角色(但这是非常困难和不自然的，似乎给了实现框架太多的影响)。

这意味着您将认识到参与者是非常有限的，而容错应该主要由传统的异常处理来处理，而且无论如何，拥有一个容错应用程序的愿望不应该对应用程序的设计产生太大的影响。既然如此，为什么要找演员麻烦呢？使用一个需要阅读每个行为者的实现的框架，以便理解复杂的类似意大利面的消息结的工作流程，要比使用基于层次结构的框架容易得多，这些框架可以通过查看方法签名在任何程度上显示出来，而不一定要查看它们的实现。

如果只有一小部分应用程序是由参与者实现的，那么参与者的许多好处，例如容易扩展，似乎不那么相关或不实用。