Actor是封装状态和行为的对象,他们唯一的通讯方式是交换消息——把消息存放在接收方的邮箱里。从某种意义上来说,actor是面向对象最严格的形式,不过最好把它们比作人:在使用actor来对解决方案建模时,把actor想象成一群人,把子任务分配给他们,将他们的功能整理成一个有组织的结构,考虑如何将失败逐级上传(好在我们并不需要真正跟人打交道,这样我们就不需要关心他们的情绪状态和道德问题)。这个结果就可以作为软件实现的思维框架。
注意
一个Actor系统是一个很重的结构,它会分配一到N个线程,所以对每一个逻辑应用创建一个就够了。
象一个经济组织一样,actor自然形成树形结构。程序中负责某一功能的actor,可能需要把它的任务分拆成更小的、更易管理的部分。为此它启动子actor并监督它们。虽然后面章节会解释监督机制的细节,我们会集中在这一节里介绍其中的根本思想,唯一需要了解的前提是每个actor有且仅有一个监管者,就是创建它的那个actor。
Actor系统的精髓在于任务被拆开、委托,直到任务小到可以被完整地处理。这样做不仅清晰地划分出了任务本身的结构,而且最终的actor也能按照它们“应该处理什么类型的消息”,“如何处理正常流程”以及“如何应对失败流程”来进行推理。如果一个actor对某种状况无法进行处理,它会发送相应的失败消息给它的监管者请求帮助。这样的递归结构使得失败能够在正确的层次得到处理。
可以将这种思想与分层的设计方法进行比较。分层的设计方法最终很容易形成防护性编程,以防止任何失败被泄露出来;相比之下把问题交由正确的人处理会是比将所有的事情“藏在深处”更好的解决方案。
现在,设计这种系统的难度在于如何决定谁应该监管什么。这当然没有唯一的最佳方案,但是有一些指导原则可能会有帮助:
当然以上的规则都会有例外,但无论是遵循这些规则还是打破它们,都需要有足够的理由。
actor系统是多个协作actor的组,它天生就是管理调度服务、配置、日志等共享设施的单元。使用不同配置的多个actor系统可以在同一个jvm中共存,Akka自身没有全局共享的状态。将这与actor系统之间的透明通讯(在同一节点上或者跨网络连接的多个节点)结合,可以看到actor系统本身可以被作为功能层次中的构建单元。
在某些情况下,阻塞操作是不可避免的,即必须不定期地休眠一个线程,等待外部事件唤醒。例如传统的关系型数据库的驱动程序或消息传递API,而深层的原因通常是出现幕后的(网络)I/O。面对这一点,你可能受到诱惑,只是将阻塞调用包装在 Future
中来替之工作,但这个策略太简单了:当应用的负载增加,你很可能会发现性能瓶颈,或者出现内存或线程耗尽的情况。
对“阻塞问题”的充分解决方案的清单是不会穷尽的,但肯定会有下面的建议:
Future
内进行阻塞调用,确保任意时间点内这种调用的数量都在一个上限内(无限制提交这类任务会耗尽你的内存或线程)。Future
内进行阻塞调用,使用一个线程池,该线程池的线程数上限对应用程序运行的硬件是合适的。第一个建议对本质上是单线程的资源特别适合,如传统数据库句柄一次只能执行一个未完成的查询,并使用内部同步保证这一点。一个常见的模式是对N个actor创建一个router,每个actor包装一个数据库连接,并处理发送给这个router的查询。数目N
必须被调整为最大吞吐量,这个数字取决于什么数据库管理系统部署在什么硬件上。
注意
配置线程池的任务最好代理给Akka来做,只要在
application.conf
中配置,并由ActorSystem
[Java, Scala] 实例化即可。
一个actor系统管理它所配置使用的资源,运行它所包含的actor。 在一个系统中可能有上百万个actor,不用担心,内存一定是够用的,因为每个actor实例仅占差不多300个字节。自然地,一个大系统中消息处理的具体顺序是不受应用开发者控制的,但这并不是有意为之。放松些,让Akka去做幕后的繁重事务吧。