Tomcat（或同等产品）对于简单服务的优势
我需要开发一个简单的 Java 服务，因为：
- 它仅通过 TCP 套接字进行通信，没有 HTTP。
- 它在专用服务器上运行（除了基本的 SSH 等之外没有其他服务）
我应该将其作为独立服务（可能在 Java Service Wrapper 之类的东西中）还是让它在 Tomcat 之类的容器中运行？两者有何好处和坏处？
I'll need to develop a Java service that is simple because:
- It only communicates via a TCP socket, no HTTP.
- It runs on a dedicated server (there are no other services except the basic SSH and such)
Should I make this a standalone service (maybe in something like Java Service Wrapper) or make it run in a container like Tomcat? What are the benefits and detriments of both?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
如果您不使用 HTTP，则必须为 Tomcat 构建自己的连接器。当我编写这些类型的应用程序时，我只是将它们编写为标准 Java 应用程序。在 Windows 计算机上，我使用服务包装器，使它们成为 Windows 启动过程的一部分。在非 Windows 机器上，您只需要添加启动脚本。
If you aren't working with HTTP, you will have to build your own connectors for Tomcat. When I've written these types of applications, I've just written them as standard Java applications. On Windows machines, I use a service wrapper that allows them to be part of the Windows startup process. On non-windows machines, you just need to add a start up script.
使用容器（无论哪个）会给你带来有关启动、停止、扩展、日志记录等的所有细节，否则你必须自己做这些，而且它总是比你想象的更难（至少当你达到生产时）。
尤其是可扩展性是您现在需要考虑的事情。以后要改变主意就会困难得多。
因此，如果有人已经编写了您需要的大部分内容，请使用它。
Using a container (regardless which) buys you that all the details about starting, stopping, scaling, logging etc, which you have to do yourself otherwise, and it is always harder than you think (at least when you reach production).
Especially the scalability is something you need to consider already now. Later it will be much harder to change your mind.
So, if somebody already wrote most of what you need, then use that.
在你的情况下，Tomcat 听起来对我来说不是一个好的选择。 AFAIK 它主要是为 Servlet 和 JSP 设计的，而您两者都没有。您也不需要在您的应用程序上部署多个应用程序。服务器等（因此没有从“.war”中受益）。
如果您需要依赖注入、连接池、日志记录、网络编程框架等，有很多好的解决方案，而且它们不需要 tomcat。
例如，就我而言，我选择了一个独立的应用程序。使用 Spring、Hibernate、Netty、Apache Commons DBCP、Log4j 等。这些可以轻松设置，这样您就有更多的自由。
如果您需要 HTTP 服务器，也许嵌入 Jetty 是另一种选择。通过此选项，您可以更好地控制应用程序。与使用 tomcat 容器相比，这可能会简化您的实现。
Tomcat doesn't sound like a good choice for me in your situation. AFAIK it's primarily made for Servlets and JSPs, and you have neither. You also don't need to deploy multiple applications on your app. server etc. (so no benefit from ".war").
If you need dependency injection, connection pooling, logging, network programming framework etc., there are a lot of good solutions out there and they don't need tomcat.
For example, in my case I went for a standalone app. that used Spring, Hibernate, Netty, Apache Commons DBCP, Log4j etc. These can be easily setup, and this way you have a lot more freedom.
Should you need a HTTP server, maybe embedding Jetty is another option. With this option too, you have more control over the app. and this can potentially simplify your implementation compared to using a tomcat container.
如果您不使用 HTTP，Tomcat 并不会真正给您带来太多好处。
但是，由于以下原因，我被迫将非 HTTP 服务器移至 Tomcat，
我们需要一些简单的网页来显示服务器的状态/统计信息，因此我需要一个 Web 服务器。 Java 6 附带了一个简单的 HTTP 服务器，但 Tomcat 更强大。
我们的操作工具仅适用于运行 Tomcat，独立应用程序在其监控系统中不会受到雷达影响。
我们使用 DBCP 进行数据库池，每个人似乎都更喜欢在 Tomcat 下使用它。
Tomcat 的内存占用（几 MB）对我们来说不是问题，因此自从迁移到 Tomcat 以来我们没有看到任何性能变化。
Tomcat doesn't really buy you much if you don't use HTTP.
However, I was forced to move a non-HTTP server to Tomcat for following reasons,
We need some simple web pages to display the status/stats of the server so I need a web server. Java 6 comes with a simple HTTP server but Tomcat is more robust.
Our operation tools are geared to run Tomcat only and standalone app just falls off radar in their monitoring system.
We use DBCP for database pooling and everyone seems more comfortable to use it under Tomcat.
The memory foot-print of Tomcat (a few MBs) is not an issue for us so we haven't seen any performance change since moved to Tomcat.
容器可以让您免于在启动、监控、日志记录、配置、部署等方面重新发明轮子。此外，它还使非开发人员更容易理解您的服务。
我不一定会选择 tomcat，请查看 glassfish 和 germonimo，因为它们更加模块化，您可以只拥有需要的部分，并排除 http 服务器。
不久前我们也面临过类似的决定，系统的某些部分最终是基于 jsw 的，而其他部分则是 .war 文件。 .war 选项的构建和配置更简单（当然更标准）。
A container can save you from reinventing the wheel in terms of startup, monitoring, logging, configuration, deployment, etc. Also it makes your service more understandable to non-developers.
I wouldn't necessarily go for tomcat, check out glassfish and germonimo as they are more modular, and you can have just the bits the need, and exclude the http server.
We faced a similar decision a while back, and some parts of the system ended up being jsw based, and the others as .war files. The .war option is simpler (well more standard for sure) to build and configure.