在Play 2.0中,Play将所有请求委托给一个actor来处理。它严重依赖于Akka的future API和其他部分。在Play 2.1中,随着Akka的future API移动到Scala 2.10,Play开始不直接依赖于Akka。它从Akka获取所有的执行上下文,并提供与Akka的集成,但仅限于此。在Play 2.3中,我们正在添加新功能以帮助Akka集成,特别是在WebSockets方面。在Play 2.4中,Play将被移植到新的akka-http(以前称为spray),到那时,Play就像你所能得到的那样建立在Akka之上。这会带来什么后果呢?Akka提供了一种编程范式,使并发处理变得简单易懂。它还提供了优秀的抽象,用于分布式编程——分布式编程中最困难的事情就是适当地处理失败(这种情况经常发生)。大多数工具尝试通过试图将故障隐藏起来来解决这个问题,但不幸的是,隐藏某些东西并不能使它消失,而实际上会使事情变得更加困难,因为当您试图解决特定类型的故障时,它们被隐藏起来事实上会妨碍你。 Akka将故障推到您的面前,这样在编码时,您就被迫考虑应用程序如何响应故障。因此,您被迫以一种容忍故障的方式设计/编写应用程序。它还为您提供了处理故障的工具,使您可以以分层的方式指定要处理何种类型的故障以及如何响应故障(停机,重试n次等)。那么这对Play有何帮助?更好的问题是它如何帮助Play用户?Akka帮助我实现了Play本身,但是可以在没有Akka的情况下实现它(实际上Netty现在完成了大部分的重活,但这将在Play 2.4中改变)。重要的是,Play与Akka无缝集成,使得用actor处理HTTP请求、处理故障等变得容易,这有助于Play用户因为它允许他们以可扩展和具有韧性的方式设计应用程序。更新:以上内容是3年前写的,自那以来发生了很多变化。在Play 2.5中,我们废弃了迭代器API,并转向使用Akka Stream。这意味着现在所有异步IO都通过Akka流进行。很快(不确定是否为Play 2.6或更晚版本),Play将切换到使akka-http成为服务器的默认后备实现(尽管WS客户端尚未实现)。更新2:Play 2.6现在将akka-http作为其HTTP服务器的默认后端实现(Netty仍然可供选择)。