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