Преимущества Tomcat (или эквивалент) для простого обслуживания

Question

Мне нужно разработать простой Java-сервис, потому что:

• Он связывается только через сокет TCP, без HTTP.
• Он работает на выделенном сервере (других служб, кроме основного SSH и т. Д.) Нет *

Должен ли я сделать это автономным сервисом (возможно, в чем-то вроде Java Service Wrapper) или заставить его работать в контейнере, таком как Tomcat? Каковы преимущества и недостатки обоих?

Answer 1

Использование контейнера (независимо от того, какой именно) дает вам все подробности о запуске, остановке, масштабировании, ведении журнала и т. Д., Которые вы должны сделать самостоятельно, и это всегда сложнее, чем вы думаете (по крайней мере, когда вы достигаете производства) .

Особенно масштабируемость - это то, что вы должны учитывать уже сейчас. Позже будет намного сложнее передумать.

Итак, если кто-то уже написал большую часть того, что вам нужно, используйте это.

Answer 2

Если вы не работаете с HTTP, вам придется создавать собственные коннекторы для Tomcat. Когда я писал эти типы приложений, я просто писал их как стандартные приложения Java. На компьютерах с Windows я использую служебную оболочку, которая позволяет им быть частью процесса запуска Windows. На компьютерах, отличных от Windows, вам просто нужно добавить скрипт запуска.

Answer 3

Tomcat не выглядит для меня хорошим выбором в вашей ситуации.AFAIK это в первую очередь сделано для сервлетов и JSP, а у вас нет ни того, ни другого.Вам также не нужно развертывать несколько приложений в вашем приложении.сервер и т. д. (так что нет никакой выгоды от ".war").

Если вам нужно внедрение зависимостей, пул соединений, ведение журнала, инфраструктура сетевого программирования и т. Д., Есть много хороших решений, и им не нужен tomcat.

Например, в моем случае я выбрал отдельное приложение.которые использовали Spring, Hibernate, Netty, Apache Commons DBCP, Log4j и т. д. Их можно легко настроить, и таким образом у вас будет гораздо больше свободы.

Если вам нужен HTTP-сервер, возможно, встраивание Jetty является еще одним вариантом.С помощью этой опции у вас больше контроля над приложением.и это может потенциально упростить вашу реализацию по сравнению с использованием контейнера Tomcat.

Answer 4

Tomcat на самом деле мало что покупает, если вы не используете HTTP.

Однако я был вынужден переместить не-HTTP-сервер на Tomcat по следующим причинам,

1. Нам нужны несколько простых веб-страниц для отображения статуса / статистики сервера, поэтому мне нужен веб-сервер. Java 6 поставляется с простым HTTP-сервером, но Tomcat более надежен.

2. Наши операционные инструменты предназначены только для запуска Tomcat, а автономное приложение просто отваливается от радаров в их системе мониторинга.

3. Мы используем DBCP для пула баз данных, и всем кажется более удобным использовать его под Tomcat.

Объем памяти Tomcat (несколько мегабайт) не является для нас проблемой, поэтому с момента перехода на Tomcat мы не увидели никаких изменений в производительности.

Answer 5

Контейнер может спасти вас от повторного изобретения колеса с точки зрения запуска, мониторинга, регистрации, конфигурации, развертывания и т. Д. Кроме того, он делает ваш сервис более понятным для не разработчиков.

Я бы не стал ходить на tomcat, проверять Glassfish и Germonimo, так как они более модульные, и вы можете получить только нужные кусочки и исключить http-сервер.

Некоторое время назад мы столкнулись с подобным решением, и некоторые части системы оказались на основе jsw, а другие в виде файлов .war. Опция .war проще (наверняка более стандартна) для сборки и настройки.