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