Какой тип Java-контейнера для долго выполняющихся процессов в EC2?

Question

Я давний клиент-разработчик (Swing), и я довольно долго работал в одной и той же работе.Работая из дома в вакууме, я был почти полностью изолирован от общества.Недавно я занял должность стартапа на стороне сервера Java для стартапа, и я изучаю массу вещей, но я единственный человек на Java и снова в значительной степени сам по себе.Никогда ранее не занимавшийся серверной Java, большая часть этого материала является совершенно новой, и я чувствую, что понятия не имею, что такое обычные лучшие практики, или у меня нет интуитивного представления о том, какие инструменты использовать для каких задач,Я продолжаю читать и читать различные интернет-источники (ТАК круто!), Пытаясь обобщить свои знания, но некоторые вещи, кажется, трудно найти, потому что у них нет очевидных ключевых слов.Надеюсь, некоторые из вас, гуру, могут указать мне правильное направление.

Я отвечаю за реализацию нашей службы REST бэкэнда, которая на данный момент поддерживает наш веб-сайт и приложение для iPhone.Мы делаем сайт в социальных сетях, в конце концов, со многими разными клиентамиВ настоящее время единственными клиентами сервиса являются наш собственный веб-сайт и собственное приложение для iPhone.Я использую Jersey, Spring, Tomcat и RDS (MySQL от Amazon) на платформе Amazon EC2.Наше хранилище мультимедиа через S3.Я довольно быстро и хорошо все это понял - все отлично работает с веб-сайтом и приложением для iPhone.Здорово.

Наш следующий шаг - добавление длительной обработки на стороне сервера.Эта обработка, в основном, требует много ресурсов процессора и не требует никакой коммуникации, пока не будет завершена.Я пытаюсь выяснить, как лучше всего справиться с этим.Я подумываю об использовании SQS Amazon для постановки в очередь заданий в ответ на события REST, которые должны их вызвать, но я не могу понять, как мне следует справляться с обработкой очереди и обработкой.Я знаю, что где-то нужны потоки, которые отбирают задания из очереди SQS и обрабатывают их, а затем сообщают службе REST, что работа выполнена.Но где эти потоки живут?

1. В простом процессе "java -jar jobconsumer.jar" в другом экземпляре EC2, который запускает небольшой пул потоков.Может быть, использовать Spring, чтобы подключить этот кусок и запустить его?

2. В веб-приложении, развернутом в контейнере, таком как Tomcat, на другом экземпляре EC2?Я не знаю, какие преимущества я бы получил от этого, но как-то работать в таком контейнере кажется более стабильным?Контейнер такого типа действительно поддерживает длительные циклы обработки или он просто хорошо реагирует на события HTTP?

Теперь, когда я так записываю, я недействительно понимаю, почему я хотел бы использовать контейнер.Это кажется чрезмерным осложнением.Однако сообщество Java кажется настолько сосредоточенным на этих типах контейнерных, «управляемых» сред, что не использовать контейнер кажется каким-то неправильным.Я чувствую, что, может быть, я не понимаю, каковы некоторые из основных преимуществ этих контейнеров?Я имею в виду, помимо очевидных преимуществ веб-ориентированных спецификаций Servlet и JSP.Поможет ли мне какая-нибудь функциональность этих спецификаций с чем-то вроде этого?

Answer 1

Для обычного веб-приложения на Java вы почти наверняка захотите использовать один из контейнеров сервлетов, например Tomcat - он позаботится о принятии соединений, разборе и сериализации сообщений HTTP, JSP, SSL, аутентификации и т. Д.

Для не веб-приложений аргумент для использования Tomcat (или аналогичного) слабее, но есть несколько причин, по-прежнему учитывать его:

• , чтобы просто добавить JSP для запросови управление приложением или добавление веб-API в будущем
• легкое распространение выпусков (один .war против нечестивой путаницы jar-файлов и файлов конфигурации)
• горячее развертывание (хотя я покачтобы увидеть, как кто-то использует это для чего-то серьезного)

С точки зрения длительных циклов обработки контейнеры сервлетов не помогут вам, кроме уведомления вашего ServletContextListener при запуске приложения, так что вы можете запустить любойдолгосрочные задачи.

Стоит отметить, что если вы уже используете Spring, относительно легко переключиться с автономного приложения.p к контейнеру, используя ContextLoaderListener , поэтому это не должно быть проблемой, если позже вы решите, что вам нужен веб-материал.

Answer 2

Недавно мы столкнулись с аналогичным вопросом, поскольку мы размещаем крупный распределенный сервис на EC2.

Короче говоря, мы очень довольны Jetty 7 в качестве контейнера.Мы используем его для наших сервисов с обращением к пользователю www, public-api и internal-backend-api.В некоторых случаях мы используем его для не-API-сервисов, таких как очередь задач, просто чтобы предоставить немного информации о состоянии и работоспособности для нашего мониторинга.

Самое замечательное в Jetty (любой версии) в том, что оно может бытьсконфигурированный в ~ 5 строк кода, с нулевыми внешними конфигурационными файлами и т. д. Это не контейнер специально, а http-сервер, который вы можете встроить.

Мы используем Guice для внедрения зависимостей, что также благоприятствует config-file-меньше реализаций.

Длительным Java-процессам не о чем беспокоиться - вы в основном вызываете свои серверы / потоки / пулы потоков в своем основном методе и не вызываете System.exit, пока не захотите явно завершить работу.