有一段时间我一直在为微服务框架寻找一个快速简单的解决方案。我对所有 Lightbend 产品和 scala 都很陌生，但由于它看起来很有趣，我决定试一试。
几个问题：
1) 我不明白为什么需要新框架 Lagom ？
如果 play 已经可以给我同样的解决方案（作为微服务），那为什么还需要另一个框架呢？
2）通过玩，我设法非常快速地创建了一个“Hello World”项目，而且部署非常简单直接（通过 dist）。
我喜欢这样一个事实，即我可以将所有内容合并到一个 ZIP 中并通过脚本运行它。据我了解，在 Lagom 中，我需要使用 ConductR。
对于我目前的需求，它看起来像是一个很大的开销。是否有一个简单的原因来部署它，比如在 play 中？
谢谢你们
Lagom 建立在 Play 之上。Play 旨在成为一个通用（异步）Web 框架，而 Lagom 更具体的目标是添加一些工具/意见，专注于将您的应用程序部署为微服务。
Lagom 提供的几个示例可以帮助您实现微服务风格的架构（Play 没有）：-
持久性
例如，它添加的一件事是基于 Play 当前提供的持久性支持之上的基于CQRS的持久性的 API - 这（如果您不知道）是一种通过解耦查询和命令来帮助您实现微服务架构的模式。
容器编排
假设你有一个 Play 应用程序，它有 25 个不同的微服务——这对于一个相对较小的企业应用程序来说可能是一个保守的数字——你如何管理所有这些 JVM 的部署/编排？好吧，容器风靡一时。您如何管理所有这些容器？ConductR 是一个工具，它可以消除该任务的一些痛苦，Lagom 为您提供了 ConductR 的集成工具，使您可以更轻松地在您的 Lagom 项目中使用它——这是 Play 本身无法获得的。
我仍然可以通过 Play 实现这一目标
Ok, there are loads of SBT modules that you could use in your Play project to help you realise the same thing but then you need to choose what tools you need, figure out which of the many modules available are right for your project, configure and wire them as necessary - this is one of Lagom's goals - to take these decisions and configuration tasks away from you so you can focus on writing your application logic.
If my application was small, maybe just 5 services, then you could argue quite convincingly that you really don't need Lagom (or any other microservice framework for that matter). However, if your application is likely to grow, then Play on it's own will cost you more time in the long run.
There are obviously many more considerations when designing microservices but you get the jist of Play vs Lagom.