PlayFramework 应用程序的最佳部署策略？

Posted 2023-04-14

【中文标题】PlayFramework 应用程序的最佳部署策略？

【英文标题】：Best deployment strategy for PlayFramework applications?

【发布时间】：2011-06-29 20:19:14

【问题描述】：

这个问题是面向服务器的。 我有一个托管服务器（一个相当小的，1,6Ghz atom，2Go，200 GO），有几个（4 或 5 个）播放应用程序等等。大多数这些应用程序的使用量都很小，比如说每天有一百个请求。

使用 Play 的嵌入式服务器部署这些应用程序是否更好！从而为每个应用程序使用 64mb 的内存？

或者部署一个Tomcat，所有的应用都在tomcat里面？所有应用程序共享更大的内存？

编辑：

我将添加一些关于我的情况的更多信息。 服务器还托管：

Apache2

上约有 10,15 个

PHP

网站 通过 Apache mod_dav_svn 的 SVN 服务器 用于

声纳

的tomcat

Jenkins

的独立安装（通过 Jetty）

我最初的计划是在 Tomcat 中部署所有这些东西。让应用程序、Sonar 和 Jenkins 在 Tomcat 和 Apache2 上运行以获取静态资源。 （图片、脚本）

评论

最后一点，我知道在生产环境中拥有 Sonar 和 Jenkins，持续集成系统并不是真正的最佳选择。但由于这些仅在夜间运行（自动构建），它们不会使系统过载。另外，我是一名学生，在经济上，额外的“CI/build”服务器超出了我的经济能力。

【参考方案1】：

最好的方法是使用附带的 Play 服务器，将 nginx 作为反向代理放在它前面来处理所有重定向/请求管理。

为什么是这个而不是Tomcat？您可以从比较性能的this article 开始。一个额外的论点是 Tomcat 加载了 Play 不需要也不需要使用的所有 Java EE 环境，消耗了您希望为您的应用程序免费使用的内存和资源（特别是如果您使用内存缓存）。

在 Nginx 作为反向代理时，this 应该提示为什么使用它而不是 Apache。

编辑（关于问题的编辑）：

根据您的情况，您可以优化您的资源。

首先用 Nginx 替换 Apache 2。 Nginx 可以很好地为 php 提供服务（如果您使用 Ubuntu，请参阅 this）。它将非常有效地为 Play 服务，并且可以用作 Java 服务器的代理。

然后，您可以将所有 Java 应用程序移至 Jetty，并摆脱 Tomcat。 Jetty 平均消耗资源较少，即使你的应用程序只在晚上运行，服务器仍然在线并囤积内存。越少越好。

SVN 呢？遗憾的是，您将需要 Apache 2 和 Nginx 作为 Apache 2 的反向代理。那为什么不保留 Apache 呢？论据将是用法。理论上，PHP 应用程序将比 SVN 服务器拥有更多的流量，这使得它们的资源消耗更加相关。使用 nginx，分配给 PHP 的 ram 和 cpu 将使您的机器响应速度更快。 Apache 只会在你使用 SVN 时才会起作用，这种情况不会那么频繁。

如果您不想将内容转移到 Nginx（我可以理解），那么只需将 Java 应用程序转移到 Jetty 并使用 Apache 2 作为 Play 的反向代理。但是使用 Play 嵌入式服务器，不要在 Tomcat 中加载应用程序。这样会更有效率。

【讨论】：

有趣。我知道 apache 被高估了反向代理，但没有看到任何基准确认它。我将添加有关我的情况的更多信息，这可能会改变您的答案。

【参考方案2】：

我正在运行的生产部署使用 Play 嵌入式服务器。它比 Tomcat 更简单，尤其是重新部署 - 我在 screen 下运行服务器，升级包括“Ctrl-C”、“Up-Arrow”、“Enter”，执行：

% git stash; git pull; git stash apply; play run

有了 2G 内存，我不会太担心每个进程的开销。摆脱 Tomcat 的复杂性当然是值得付出的代价。

（git stashing 允许我在生产环境中放置一些非 git 提交的配置 - 懒惰多于需要，不过 :-)）

【讨论】：

到目前为止，我确实在我的应用程序中使用过相同类型的命令。不过，我会添加一些“播放依赖项”。

确实如此。我的“生产”应用程序仍然是 1.1。

【参考方案3】：

我会为每个应用程序启动一个播放服务器。配置更容易，并且更容易拥有单独的日志文件。 此外，您可以单独重新启动每个应用程序而不会出现问题。在 tomcat 上重新部署通常会导致错误。

缺点：您必须配置像 lighttp 这样的反向代理才能获得像 mydomain.org/app1 和 mydomain.org/app2 这样的好网址

【讨论】：

即使使用 tomcat，也可以为每个应用程序创建一个日志文件。因此，这不是一个论点。但确实配置/重新部署更容易。取点。谢谢！

我只是说它更容易有单独的日志文件，特别是如果你有像 myDomain.org/myApp 和 myDomain.org/myApp_beta 这样的情况，所以同一个应用程序在不同的版本中。