作者： 一字马胡
在Java Web开发完成之后，需要部署到Servlet容器中去运行起来提供Http服务，而现在有很多可供选择的Servlet容器，比如Jetty、Tomcat等，所谓Servlet容器，即实现了Servlet规范的框架，它可以加载Servlet并且处理Servlet规范的请求。
在进行正题之前，我想先谈一谈怎么提供一个web服务，以及可供选择的方案有哪些等内容。首先，我们需要能接收到Http请求，并且将http请求解析出来，以及保存一些上下文信息（Context），包括client的信息，因为我们需要将处理好的请求结果发送回client，所以需要保存client的相关信息。解析好请求之后，就需要将请求正确的转发到合适的处理器中去，一般地，我们使用一个url来匹配一个handler，client的请求信息中会带着完成的url，我们需要将请求的url所对应的handler找到，然后将请求投递到该handler中去，然后该handler进行相应的处理，处理完成之后将结果返回给client，因为我们在解析client请求的时候已经保存了client的相关信息，所以可以往client的连接中写入响应结果，这样一个请求是处理完成了。
在匹配到合适的handler之后，我们需要将请求转交给该匹配到的handler来进行处理，这个时候，我们有两种选择，第一，将请求转交给handler之后不再管这个请求，对请求的相应要求handler来完成，第二，我们在将请求转交给匹配到的handler之后，需要一直阻塞当前线程直到handler处理完成请求，前一种模式成为异步处理模式，相对的后一种模式成为同步模式。他们之间的差别在于，异步模式下请求转发器可以快速的将请求转发到正确的handler，并且不阻塞转发线程，一个转发线程在转发一个请求到handler之后可以快速进行下一个请求的转发，而同步模式下，一个转发线程将继续去执行handler中的处理逻辑，这个生命周期就比较长了，当然，离开场景来比较两种模式的优劣是没有任何意义的，两种模式都有存在的价值，而且同步模式似乎大行其道。如果handler处理很慢的话，在异步模式下，多个请求将积压在handler线程任务队列中，并且有将请求丢弃的风险，而同步模式则不会存在这种情况，一个请求将会完整的得到执行并且进行响应。但是，考虑这样一种场景，一个web服务提供了非常多的接口，大部分的接口的相应时间都是非常快速的，但是有几个接口的响应时间特别慢，这个时候就可以使用异步模式，因为异步模式下，请求的执行是放在异步线程里面去做的，所以类似于请求投递的线程可以将更多的经历放在投递那些快速响应的请求上去，当然，如果大部分的接口的响应都很慢或者很快的时候，使用异步模式并没有太大的效果，并且异步模式下编程模型更为复杂，建议使用同步模式即可。如果不想使用异步模式，但是同一个服务中接口的响应时间并不均衡，那么可以使用接口分组的模式，将快速响应的接口和响应慢的接口分成两组，然后对响应慢的接口进行一步处理，对响应快速的接口进行同步处理，即可解决问题。
上面的这张图片展示了上面描述的处理一个请求的流程，大概描述如下：
（1）、客户端的请求到达Nginx服务器，然后将请求转发到相应的服务集群中去
（2）、类似于Jetty的servlet容器将接收到请求，然后对请求进行封装等操作，然后将请求投递到具体的handler中去执行，并且得到响应
（3）、具体的handler将执行具体的业务逻辑，并且返回响应
当然，类似于Jetty这样的Servlet容器其实只是一类解决方案，这类解决方案的特点就是规范，有一个全世界统一的Servlet规范，大家都按照这个规范来做，所以用起来很放心，很安全，但是，规范的东西未免需要考虑太多的东西，所以整体来说这一套规范是比较重的，就目前来说，在web开发上，除了走Servlet规范这条路之外，还有其他的一些“野路子”可以选择，比如Netty，Netty是一款异步高性能网络通信框架，它支持Http协议，所以可以用它来做web开发，这是没有问题的，你还可以使用Vert.x这样的异步web框架。
但是，使用Jetty、Tomcat等服务Servlet规范的web服务器是主流，实践证明，使用Jetty、Tomcat等Servlet已经可以承受互联网大流量下的服务压力，所以在技术成熟度上来讲，Jetty、Tomcat等已经较为成熟稳定，当然，对于类似于Netty等一些新兴的可用的web框架，也可以关注。
上文说到怎么处理一个请求，以及一些可行的技术方案等内容，下面的内容将着重谈一谈Jetty这款高性能、可插拔的、嵌入式的Servlet容器。
Jetty的一大优势是使用简单，它是一种嵌入式的Servlet容器，可以将它写到你的使用web项目中去，它只需要很少的配置就可以运行的非常好，你大概只需要配以Connector和Handler，然后就可以使用main方法来加载你的配置文件，然后访问Server的start方法即可启动起来，使用jetty来启动web项目大概需要这么几个步骤：
- （1）、编写Jetty服务器的配置文件，它是一个xml，你需要配置用于接收连接的Connector，以及用于处理连接的Handler，以及一些其他的信息，比如Worker线程池的配置等。
- （2）、使用org.eclipse.jetty.xml.XmlConfiguration加载这个xml文件，然后获取到Jetty的Server实例，并且调用其start方法启动Jetty。
- （3）、第二步完成之后，Jetty就会去解析web.xml，然后将所有配置好的Servlet加载进来，做好这些之后，就可以打开Connector来接收连接了，接收到连接之后会进行一系列的校验、封装等处理，然后将其投递到匹配的Servlet中去，在Servlet内部，一个请求将被在此根据url进行匹配，匹配到具体的handler中去执行请求，这部分就是Servlet内部的事情了。
- （4）、终于，一个请求达到了我们的业务逻辑层，如果我们使用Spring MVC来做web开发，那么我们的Controller就会收到这个请求，我们就可以使用Service来处理这个请求，并且返回处理结果。
这一连串的动态其实不难想象，我们也应该清晰的知道Jetty对我们来说到底意味着什么，它具体工作在什么环节，以及它负责什么工作，关于Jetty更为深入的内容将在后续的Jetty相关的文章中进行学习总结，本文点到为止，下面来谈一谈最后一个问题，Jetty和Tomcat的区别与联系。
关于Jetty和Tomcat的话题千篇一律，总结一下就是：
（1）、Jetty和Tomcat都是非常优秀的Servlet容器框架，并且他们都是高性能的web服务器，在性能方面相差无几。
（2）、Jetty的优势在于它架构简单，配置简单，使用起来也很简单，并且最要命的是它是嵌入式的，当然也可以像Tomcat一样使用。
（3）、Tomcat则复杂很多，复杂的同时代表它功能更加强大，而Jetty则功能比较单一，当然，不得不说Jetty的可扩展性非常好，你也可以实现一些扩展功能，但是使用Tomcat，你就不需要自己进行扩展了，所有你能想象到的企业级功能它都支持。
（4）、Tomcat适用于具备少数非常繁忙的连接的处理上，而Jetty则适合处理长时间连接的应用。
整体看来，应该看你具体的场景和需求，对于移动后台，强烈建议使用Jetty，而一些其他的场景下，你也可以考虑使用Tomcat，Tomcat看起来没什么Bug，但是Jetty貌似还是有一些隐藏的Bug，但是这些Bug发生的几率都是非常低的，是在极端情况下才会出现的，而在极端场景下出现的各种异常又是难易避免的，所以也可以忽略Jetty的这些问题，仅仅是它高性能、可扩展、使用简单、嵌入式等这些特性，我们就应该尝试使用它来解决我们的问题。
