哪种 Java 容器可用于 EC2 上的长时间运行进程？

Question

我是一名长期的客户端 (Swing) 开发人员，很长一段时间以来，我几乎都是自己在同一份工作中进行操作。在真空中在家工作，我几乎完全与社区隔绝。我最近在一家初创公司担任服务器端 Java 人员，我正在学习很多东西，但我是唯一的 Java 人员，并且几乎又要靠我自己了。以前从未做过服务器端 Java，很多东西都是全新的，我觉得我不知道正常的最佳实践是什么，或者我对哪些工具用于哪些工作没有直观的感觉.我一直在阅读和阅读各种互联网资源（太棒了！）试图增加我的知识，但有些东西似乎很难搜索，因为它们没有任何明显的关键字。希望你们中的一些大师可以为我指明正确的方向。

我负责实现我们的后端 REST 服务，该服务目前支持我们的网站和 iPhone 应用程序。我们正在做一个社交媒体网站，最终有许多不同的客户。目前，该服务的唯一客户是我们自己的网站和我们自己的 iPhone 应用程序。我在 Amazon 的 EC2 平台上使用 Jersey、Spring、Tomcat 和 RDS（Amazon 的 MySQL）。我们的媒体存储是通过 S3。我很快就掌握了所有这些东西，到目前为止一切都很好——网站和 iPhone 应用程序都运行良好。凉爽的。

我们的下一步是添加一些长时间运行的服务器端处理。这种处理基本上是 CPU 密集型的东西，在完成之前不涉及任何通信。我试图弄清楚处理这个问题的最佳方法是什么。我正在考虑使用 Amazon 的 SQS 对作业进行排队，以响应应该触发它们的 REST 事件，但我不知道应该如何处理出列和处理。我知道我需要一些线程从 SQS 队列中取出作业并处理它们，然后告诉 REST 服务作业已完成。但是这些线程在哪里？

1. 在另一个启动小型线程池的 EC2 实例上的普通“java -jar jobconsumer.jar”进程中。也许使用 Spring 连接这部分并开始运行？

2. 在另一个 EC2 实例上部署在像 Tomcat 这样的容器中的 web 应用程序中？我真的不知道我会从中得到什么好处，但不知何故在这样的容器中运行似乎更稳定？这种容器是否真的支持长时间运行的处理循环，还是只是擅长响应 HTTP 事件？

现在我把它写成这样，我真的不明白我为什么要使用容器。这似乎过于复杂了。然而，Java 社区似乎如此专注于这些类型的容器化、“托管”环境，以至于不使用容器似乎有些错误。我觉得也许我不明白这些容器的一些主要好处是什么？我的意思是，除了面向 Web 的 Servlet 和 JSP 规范的明显好处之外。这些规范的任何功能都可以帮助我解决这样的问题吗？

Answer 1

对于常规的 Java Web 应用程序，您几乎肯定希望使用 Tomcat 等 Servlet 容器之一 - 它负责为您接受连接、解析和序列化 HTTP 消息、JSP、SSL、身份验证等。

对于非 Web 应用，使用 Tomcat（或类似应用）的论据较弱，但仍有一些理由值得考虑：

• 直接添加用于查询和管理应用程序的 JSP 或将来添加 Web API
• 轻松分发版本（一个 .war 与一团糟的 jar 和配置文件）
• 热部署（虽然我还没有看到有人将它用于任何严重的事情）

就长时间运行的处理循环而言，Servlet 容器除了在应用启动时通知您的 ServletContextListener 之外并不能帮助您，因此您可以启动任何长时间运行的任务。

值得注意的是，如果您已经在使用 Spring，使用 ContextLoaderListener 从独立应用程序切换到容器相对容易，因此如果您稍后决定需要网络的东西。

Answer 2

我们最近遇到了一个类似的问题，因为我们在 EC2 上托管了一个大型分布式服务。

简而言之，我们非常对 Jetty 7 作为容器感到满意。我们将它用于面向用户的 www、public-api 和 internal-backend-api 服务。在某些情况下，我们将它用于非 api 服务，例如工作队列，只是为了公开一些状态和健康信息以供我们监控。

Jetty（任何版本）的优点在于它可以用大约 5 行代码进行配置，外部配置文件为零等。它不是专门的容器，而是可以嵌入的 http 服务器。

我们使用 Guice 进行依赖注入，这也有利于无配置文件的实现。

无需担心长期存在的 Java 进程 - 您基本上可以在 main 方法中启动您的服务器/线程/线程池，并且在您想要明确关闭之前不要调用 System.exit。