我对于使用 Play 框架和 Akka 进行编程相当陌生，尽管我已经阅读它们有一段时间了。我现在正在默认/基本 Play 环境上启动一个概念验证应用程序。我的问题源于 Play 中的 Web 服务客户端 api (http://www.playframework.org/documentation/2.0.1/ScalaWS)。
该应用程序基本上需要以尽可能可扩展和高性能的方式协调对远程 SOAP Web 服务的调用。浏览器以 JSON 格式进行 ajax 调用，Play 应用程序需要将它们转换为 SOAP/XML，反之亦然。
如果我直接通过控制器使用播放 Web 服务客户端，这些调用可以是异步的，这比我们现在所做的（阻塞）要好得多。但是，我不清楚这在重负载下到底会如何表现。并发/线程管理将主要留给底层 Netty 服务器吗？我有什么办法可以调整吗？
另一种方法是使用控制器中的 Akka actor 系统，我可以在其中控制路由策略、池大小、容错等。如果我采用这种方法，那么使用 Play 的异步 WS 客户端是否仍然有意义？如果是这样，这种方法（组成期货？）会是推荐的模式吗？
另一个使 Akka 方法更具吸引力的因素是，该应用程序最终将承担其他几个职责，因此我们可以控制/调整该 ActorSystem 允许的资源，并降低整个应用程序被 SOAP 服务拖累的风险。
您详细介绍的两个选项都可以：
- 使用 WS 的 play API 异步处理请求/响应
- 使用 Akka 做同样的事情并在你的 actor 中同步管理你的 WS 调用
首先，解决方案没有正确或错误之分。
表演！ WS API 解决方案最容易实现和测试。社区中的许多人都依赖它（我就是这么做的）。
另一方面，即使 Akka 解决方案的设置难度更大（不是那么多），它也会在未来为您带来更多灵活性。你可以简单地使用异步播放！块 http://www.playframework.org/documentation/2.0/ScalaAsync并使用异步计算的承诺。还有play Promise 和 akka future 之间的隐式转换 http://www.playframework.org/documentation/2.0/ScalaAkka。最后，要监控你的演员，你可以看看类型安全控制台 http://resources.typesafe.com/docs/console/.
如果最重要的是性能，那么过早的优化通常会导致更多（且不必要的）复杂性。就我而言，我将从 API WS 开始，如果将来需要，我会转向 Akka 解决方案。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
