有一段时间，我一直在为微服务框架寻找快速而简单的解决方案 . 我对所有Lightbend产品和scala都很陌生，但由于它看起来非常有趣，我决定尝试一下 .
Few Questions:
1）我不明白为什么需要新的框架Lagom？
如果play已经可以给我相同的解决方案（作为微服务）那么为什么需要另一个框架呢？
2）通过游戏，我设法快速创建“Hello World”项目，并且部署非常简单直接（通过dist） .
我喜欢这样一个事实：我可以合并所有的ZIP，并通过脚本运行它 . 根据我的理解，在Lagom中我需要使用ConductR .
对于我目前的需求，它看起来像一个很大的开销 . 是否有一个简单的原因来部署它像在游戏中？
谢谢你们
1 回答
Lagom Build 在Play之上 . 虽然Play旨在成为通用（异步）Web框架，但Lagom更具体的目标是添加一些专注于将您的应用程序部署为微服务的工具/意见 .
Lagom提供的几个例子可以帮助您实现微服务式架构（Play不会）： -
Persistence
例如，它增加了一个基于CQRS持久性的API，它基于Play目前提供的持久性支持 - 这个（如果您不知道）是一种模式，可以帮助您通过解耦查询和命令来实现微服务架构 .
Container Orchestration
假设您有一个Play应用程序，它有25个不同的微服务 - 即使是一个相对较小的企业应用程序，这可能是一个保守的数字 - 您如何管理所有这些JVM的部署/编排？井容器风靡一时 . 你如何管理所有这些容器？ ConductR是一个可以消除这项任务的一些工具的工具，Lagom为您提供了ConductR的集成工具，使您可以更轻松地将它与您的Lagom项目一起使用 - 这是您无法通过Play自行获得的 .
I could still achieve this with Play
好的，您可以在Play项目中使用大量的SBT模块来帮助您实现相同的功能，但是您需要选择所需的工具，找出适用于您的项目的多个可用模块，配置和根据需要连接它们 - 这是Lagom的目标之一 - 将这些决策和配置任务从您身边移开，这样您就可以专注于编写应用程序逻辑 .
如果我的应用程序很小，也许只有5个服务，那么你可以非常令人信服地说你真的不需要Lagom（或任何其他微服务框架） . 但是，如果您的应用程序可能会增长，那么从长远来看，Play on it own将花费您更多时间 .
在设计微服务时，显然还有很多考虑因素，但是你得到了Play vs Lagom的主旨 .