假设我需要将一些子流程委托给子参与者。我可以在初始化参与者期间创建子参与者(在AKKA.NET中称为PreStart)。如果我需要多个子角色并行运行，我可以使用AKKA路由器。我认为这是推荐的方法。
但是，我也可以在Receive-method中创建子actor，并让对IActorRef实例的引用具有Receive-method的局部作用域。这种方法有意义吗?与上面描述的情况相比，它有什么优势吗?
在消息处理程序中创建子actor是非常有意义的，特别是当您不能先验地创建它们时，因为您可以根据传入的数据动态地创建它们。
一个典型的例子是Child Per Entity模式，您为每个实体id创建一个参与者。因此，如果您收到一条带有您以前没有收到过的新id的消息，您将需要启动一个新的子演员。你可以看到网络爬虫样本是如何做到这一点的。虽然第一个诱惑是维护一个id到child actor的字典，但事实证明这甚至是不必要的。正如web爬虫示例所做的那样，您可以检查actor的Children以确定它是否已经有该子节点。
当你动态地创建子actor时，你可能想给它们一个ReceiveTimeout，以确保它们不会因为永远存在而泄漏内存。
是。例如，如果接收到的每条消息都启动了某个有状态流程，那么您将创建子参与者来处理该流程。这些子参与者可能需要响应来自其他参与者的其他消息。然后可能会有最后一条消息告诉流程结束。你可以将IActorRef作为消息的一部分传递，这样局部作用域的概念就不一定适用了。
动态创建演员的另一个例子是这里描述的Extra和Cameo模式和源代码
Cameo模式的基本思想是在实际工作人员(Cameos)面前使用响应式外观。它与Router不同，因为Facade不在响应路径上，它将所有相关上下文交给Cameo，并让它完成作业并将结果直接传达给(原始作业的)发送者。
额外的模式是相同的，但匿名演员。Cameo actor更好，因为它提供了更好的日志(具有可读的actor名称)，并且代码结构更好。此外，关闭facade actor的状态也更加困难。
底线:为每个请求创建参与者允许您更好地隔离工作单元，保持"入口点"参与者不那么繁忙，并提供更好的范围日志(这对于理解分布式系统行为非常重要)。