簡單的微服務框架

Question

有一段時間我一直在尋找一個微服務框架的快速簡單的解決方案。我對所有Lightbend產品& scala都很陌生，但由於它的外觀非常有趣，我決定嘗試一下。

幾個問題：

1）我不明白爲什麼有必要爲新框架Lagom？

如果play已經可以給我提供相同的解決方案（作爲微服務），那麼爲什麼還需要另一個框架呢？

2）隨着播放，我設法非常快地創建一個「Hello World」項目，並且部署非常簡單直接（通過dist）。

我喜歡這個事實，我可以合併所有在一個ZIP並通過腳本運行它。從我理解的Lagom中我需要使用ConductR。

對於我目前的需求看起來像一個很大的開銷。是否有一個簡單的原因來部署它，就像在遊戲中一樣？

謝謝大家

Answer 1

Lagom建立在Play之上。儘管Play旨在成爲通用（異步）Web框架，但Lagom更具體的目標是添加一些專注於將應用部署爲微服務的工具/意見。

一對夫婦的例子是Lagom提供幫助您實現微服務式建築（即玩不）： -

持久

之一，它增加了，例如，是一個API的事情CQRS在持續性支持之上的基於持久性Play目前提供 - 這（如果您不知道）是一種模式，它可以通過解耦查詢和命令來實現微服務體系結構。

集裝箱業務流程

假設你有一個具有25個不同的微服務一個Play應用程序 - 這可能是一個保守的數字爲說，甚至一個相對較小的企業應用程序 - 你如何管理部署所有的/編排那些JVM的？好的容器都很風靡。你如何管理所有這些容器？ ConductR是一種工具，可以避免這一任務帶來的一些麻煩，而且，Lagom爲您提供了用於ConductR的集成工具，使您可以更輕鬆地將其用於您的Lagom項目 - 這是您自己無法使用Play獲得的。

我仍然可以使用播放達到這個

好的，也有SBT模塊的負荷，你可以在你的遊戲項目中使用，以幫助您實現同樣的事情，但你需要選擇你所需要的工具，找出可用的許多模塊中的哪些適合您的項目，根據需要配置並連接它們 - 這是Lagom的目標之一 - 將這些決策和配置任務從您身邊移開，以便您可以專注於編寫應用程序邏輯。

如果我的應用程序很小，也許只有5個服務，那麼你可以非常令人信服地說，你真的不需要Lagom（或任何其他微服務框架）。但是，如果您的應用程序可能會增長，那麼從長遠角度來看，Play自身會花費更多時間。

當設計微服務時，顯然還有更多的考慮因素，但你得到Play vs Lagom的jist。