基于Akka，Play为高度可扩展的应用程序提供可预测的最小资源消耗（CPU，内存，线程）。
我想确切知道Akka在Play中的使用方式和位置，以及将Play构建在Akka之上的后果是什么。
答案 0 :(得分：90)
在 Play 2.0 中，Play委派所有请求通过演员。它在很大程度上取决于Akka未来的API和其他部分。
在 Play 2.1 中，随着Akka未来的API转移到Scala 2.10，Play开始依赖于Akka。它从Akka获得了它的所有执行上下文，并提供了与Akka的集成，但这与它的范围有关。
在 Play 2.3 中，我们正在添加新功能以帮助Akka集成，尤其是围绕WebSockets。
在播放2.4 中，播放将被移植到新的akka-http（以前称为“喷雾”），此时，Play将像Akka一样建立起来。
后果是什么？ Akka为编程提供了一种范例，使并发处理变得简单。它还为分布式编程提供了很好的抽象 - 分布式编程最难的事情就是适当地处理失败（一直发生）。大多数工具试图通过试图隐藏你的失败来解决这个问题，但遗憾的是隐藏某些东西并不会让它消失，实际上真的让事情变得更难，因为当你试图解决特定类型的失败时，他们是远离你的人会妨碍你。 Akka推动了你的失败，所以当你进行编码时，你不得不考虑你的应用程序如何响应失败。因此，您必须以容忍故障的方式设计/编写应用程序。它还为您提供了以分层方式处理它们的工具，允许您指定要处理何种级别的故障，以及如何响应故障（死亡，重试n次等）
那么这对Play有何帮助？更好的问题是它如何帮助Play用户？ Akka帮助我实现Play本身，但是没有Akka可以实现它（实际上Netty现在完成了大部分繁重的工作，在Play 2.4中会有所改变）。重要的是，Play与Akka无缝集成，可以轻松处理与演员的HTTP请求，处理故障等，这有助于Play用户，因为它允许他们以可扩展和弹性的方式设计他们的应用程序。 / p>
更新：以上是3年前写的，从那以后发生了很多变化。 Play 2.4确实为akka-http提供了实验支持，但Play默认仍使用Netty。
在 Play 2.5 中，我们弃用了iteratees API并切换到了Akka流。这意味着现在所有异步IO都通过Akka流。很快（不确定是否会是Play 2.6或更高版本），Play会轻拂开关，使akka-http成为服务器的默认后备实现（虽然还不是WS客户端）。
更新2： 播放2.6 现在使akka-http成为其HTTP服务器的默认后端实现（Netty仍然可用作选项）。 / p>