Akka系统《sixteen》译

Actor是一个封装状态(state)和行为(behavior)的对象，它们只通过交换消息通信(放入收件人邮箱的邮件)。从某种意义上说，Actor是最严格的面向对象编程形式，但它更适合将他们视为人：在与Actor建模解决方案时，设想一群人并为他们分配子任务，将他们的功能安排到一个组织结构，并思考如何处理失败。

ActorSystem是一个重量级结构，它将分配1 ... N个线程，因此每个逻辑程序创建一个。

层次结构

就像在经济组织中一样，Actor自然形成等级制度。程序中某个功能的一个Actor可能希望将其任务分解为更小，更易于管理的部分。为此目的，它启动它监督的子Actor。

虽然解释了监督的细节，但我们将集中讨论一些基本概念。唯一的先决条件是要知道每个Actor都有一个主管，即创建它的Actor。

Actor系统的典型特征是任务被分割和委派，直到它们变得足够小以便一体化处理。在这样做的过程中，不仅任务本身结构清晰，而且可以根据他们应该处理哪些消息，他们应该如何正常反应以及如何处理失败。如果一个Actor没有处理某种情况的手段，它会向其主管发送相应的失败消息，寻求帮助，递归结构允许在高的级别处理失败。

相比之下，分层软件设计很容易转化为防御性编程，目的是不泄漏任何故障。如果问题传达给合适的人，可以找到一个更好的解决方案，而不是试图保持一切“在地毯下”。

现在，设计这样一个系统的困难在于如何决定谁应该监督什么。没有单一的最佳解决方案，但有一些指南可能会有所帮助：

• 如果一个Actor管理另一个Actor正在做的工作，例如通过传递子任务，父级别应该监督子级别。原因是父级别知道预期会出现哪种故障以及如何处理故障。
• 如果一个Actor携带非常重要的数据（其状态不能丢失），该Actor应该向其监督的子Actor提供任何可能危险的子任务时，并在适当时处理这些子的失败。根据请求的性质，最好为每个请求创建一个新子项，这样可以简化收集回复的状态管理。这被称为Erlang的“Error Kernel Pattern”。
• 如果一个Acot依赖另一个Actor履行其职责，它应该观察其他Actor的活动并在收到终止通知时采取行动。这与监督不同，因为观看方对主管策略没有影响。

这些规则总是有例外，但无论你是遵守规则还是违反规则，都应该有理由。

配置容器

Actor系统作为互相协作Actor集合，Actpr管理共享设施（如调度服务，配置，日志记录等）的自然单元。具有不同配置的几个actor系统可以在同一JVM中共存而没有问题，没有全局共享状态在Akka本身。将此与Actor系统之间的透明通信（在一个节点内或通过网络连接）相结合，以查看Actor系统本身可以用作功能层次结构中的构建块。

Actor Best Practices

1. Actos应该像好伙伴一样：高效地完成工作而不必费心地打扰其他人，避免占用资源。转换为编程这意味着以事件驱动的方式处理事件并生成响应（或更多请求）。参与者不应该阻止（即在占用线程时被动地等待）， 可能是锁，网络套接字等 ，除非它是不可避免的;在后一种情况下见下文。
2. 不要在Actor之间传递可变对象。为了确保，更喜欢不可变的消息。如果通过将其可变状态暴露给外部来破坏actor的封装，那么您将回到正常的Java并发领域，并具有所有缺点。
3. 使Actor成为行为和状态的容器，这意味着不要经常在消息中发送行为（使用Scala闭包可能很诱人）。其中一个风险是意外地在Actor之间共享可变状态，并且这种对Actor模型的违反不幸地破坏了使Actor在编程中进行编程的所有属性。
4. 顶级Actor是你的Error Kernel的最内层部分，因此请谨慎创建它们并且更应用真正的分层系统。这有利于故障处理（既考虑配置的粒度和性能），也减少了监护人的压力，如果过度使用，这是一个单一的争用点。

你不应该关心的是什么

actor系统管理她所配置的资源，以便运行它包含的actor。在一个这样的系统中可能有数百万的Actor，当然，应用程序作者无法控制在大型系统中处理消息的确切顺序，这也不是可以预期的。退后一步，放松，让Akka在引擎盖下进行繁重的操作。

停止ActorSystem

当您知道应用程序的所有内容都已完成时，您可以调用ActorSystem的terminate方法。这将阻止监护Actor，又会递归地停止其所有的子Actor 。

如果要在终止ActorSystem时执行某些操作，请查看CoordinatedShutdown。

下节再续！

原文：https://doc.akka.io/docs/akka/2.5/guide/tutorial_5.html