请教下各位jetty在什么场景下适合使用？
近期看到一个基于node的前后端分离方案，别人是这样做的：nodejs做前端渲染，然后通过REST接口调用后端java的业务逻辑(都是独立部署的服务器)。它这里java的业务逻辑是部署在jetty上。我想请教下各位，这种方案有什么好处吗？
我自己的理解是node和java之间采用的是长链接，而jetty在这方面相对tomcat有优势。不知道各位怎么看，大家都在什么场合会用jetty?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
感觉上面几位的回答都不太满意，这里说一下吧。
第一点，在对包大小有要求的时候。jetty的裁剪性做得更好，比如不想要某个模块，直接不要就可以了，但是很多服务器的可裁剪的最小内核就很大。
第二点，在想修改服务器源码的时候。jetty因为可以嵌入式的运行，所以你可以更好的控制服务器的执行流程。不过对个人的技术水平还是有一些要求的。
不知道你说的长连接是WebSocket还是Comet还是HTTP Keep-Alive。无论是Jetty还是Tomcat对这三者都是支持的。性能方面：
WebSocket、HTTP Keep-Alive都是业界标准，两者不会存在太大的性能差异；
Comet的话Jetty和Tomcat的API是不一样的，因为没有业界的统一标准，但是性能上个人觉得也不会有太大差异，因为二者都支持NIO。
至于二者的选择，可能更多还是个人习惯问题（比如我个人就是喜欢Jetty），或者公司的规范什么的。
jetty，tomcat都称之为应用服务器。但是jetty提供了两种方式启动。
一种是嵌入式，也就是通过自己编写代码启动一个jetty。
另一种部署式，也就是tomcat一样，将一个war包部署到jetty中。
因为有了嵌入式部署，所以灵活性更好，你的代码部署就不需要依赖运维在各个环境中部署一个tomcat。
简单的说了，多了一种方式，给了开发者更多的选择。
当然jetty出来比tomcat晚，所以在性能上，架构实现上比tomcat相对好一点。
至于你问题中提到的方案不过是用了一些新技术(nodejs)完全剥离了前后端，可能开发效率上更高。
开发的时候用，因为启动很快
有点跑题了?