从Servlet到Tomcat再到Jetty

咱们直到Servlet是处理每一个HTTP请求的最小单元，而这些Servlet又被web容器所管理，不一样的web容器有不一样的特性和应用特色，好比常见的web 容器Tomcat和Jetty。

（另外咱们还知道一些高性能web框架好比netty，和tomcat的区别是什么呢？

• tomcat是基于HTTP协议的web容器，经常使用来作前端请求的服务器，也支持NIO模式；
• 而netty是一个网络框架，能够基于HTTP/TCP/UTP，也能够自定义协议，自主开发不一样的web服务器，以知足不一样的场景需求；）

 

本文旨在探究web容器组织管理servlet的机制，和web容器怎么去处理不一样的线程请求。

 

 

 

从Tomcat启动流程提及

Tomcat的系统结构：

 

 

 

 

 

 

Tomcat是一系列层级容器组成的web容器，其中最顶层的容器是Server，表明着整个服务器，从上图中能够看出，一个Server能够包含至少一个Service，用于具体提供服务；

 

Service容器包含的来个主要组件是Connetctor和Container；这是Tomcat最重要的两个组件：

 

1. Connector用于处理连接相关的事情，并提供Socket与Request和Response相关的转化;
2. Container用于封装和管理Servlet，以及具体处理Request请求；

 

这种设计模式是网络I/O常见的设计，为了可以并发处理大量链接，通常会采起一个线程方式监听客户端请求；另外一个线程采用NIO的形式select已经接收到数据的channel信道，处理请求，这样的形式；

Tomcat7提供了三种Connector：Java Blocking Connector，Java Nio Blocking Connector，APR/native Connector。

• Java Blocking Connector是Tomcat7默认的网络链接处理方式，其处理模型为一个或多个线程(Acceptor)接收TCP链接，每一个链接的请求都会交由单独的线程(Worker)处理。
• Java Nio Blocking Connector是Tomcat8默认的处理方式。为了不链接过多（尤为是keepalive的链接会阻塞worker线程）形成的线程资源浪费，它在接收网络链接的线程(Acceptor)和请求处理线程(Worker)之间增长了Poller事件队列，每当有IO就绪事件都会放入Poller队列，Poller线程会不断消费队列里的事件，交由Worker线程处理。
• APR/native Connector，APR即Apache Portable Runtime Libraries，使用了native代码来优化网络请求的处理。

 

在容器等级中的最底层就是Context容器，负责直接管理Servlet，一个Context对应一个Web工程；

 

 Tomcat的启动逻辑是基于观察者设计的，先来看看启动的时序图：

 

 

 

容器的配置属性由web.xml制定；

 

 

Tomcat处理一次http请求的时序图：

 

 

 

 

有了一个总体的了解后，让咱们再来看看Tomcat是如何分发请求，以及处理多用户同时请求和管理多级容器的；

 

 

Tomcat是如何分发请求

 

 Tomcat中使用Connector处理多线程的链接请求：

 先看看Connector的主要类图：其中处理Socket的是HttpProcessor

 

 容器的整体设计： Container是容器的父接口，全部子容器都必须实现这个接口，其中用到的设计模式是责任链模式

Engine -> Host -> Context -> Wrapper 这四个容器是个分别包含的父子关系（参见上几个图）

四个容器的关系类图：

 

 

来看看Jetty 

 

Jetty相较于Tomcat更加轻便，虽然架构更加简单，可是看起来可并不轻松。Spring是设计初衷是用来管理应用中的实例Bean，于是是基于Bean的架构；Jetty则更倾向于流程和组件的管理，采用了基于handler的架构。handler的嵌套和链式结构，LifeCycle和doStart、doHandler模式无不印证了这点

 

Jetty基础架构： 

 

 

 

 

 Jetty与Tomcat的区别

 

Jetty 的架构从前面的分析可知，它的全部组件都是基于 Handler 来实现，固然它也支持 JMX。可是主要的功能扩展均可以用 Handler 来实现。能够说 Jetty 是面向 Handler 的架构，就像 Spring 是面向 Bean 的架构，iBATIS 是面向 statement 同样，而 Tomcat 是以多级容器构建起来的，它们的架构设计必然都有一个“元神”，全部以这个“元神“构建的其它组件都是肉身。

从设计模板角度来看 Handler 的设计实际上就是一个责任链模式，接口类 HandlerCollection 能够帮助开发者构建一个链，而另外一个接口类 ScopeHandler 能够帮助你控制这个链的访问顺序。另一个用到的设计模板就是观察者模式，用这个设计模式控制了整个 Jetty 的生命周期，只要继承了 LifeCycle 接口，你的对象就能够交给 Jetty 来统一管理了。因此扩展 Jetty 很是简单，也很容易让人理解，总体架构上的简单也带来了无比的好处，Jetty 能够很容易被扩展和裁剪。

相比之下，Tomcat 要臃肿不少，Tomcat 的总体设计上很复杂，前面说了 Tomcat 的核心是它的容器的设计，从 Server 到 Service 再到 engine 等 container 容器。做为一个应用服务器这样设计无口厚非，容器的分层设计也是为了更好的扩展，这是这种扩展的方式是将应用服务器的内部结构暴露给外部使用者，使得若是想扩展 Tomcat，开发人员必需要首先了解 Tomcat 的总体设计结构，而后才能知道如何按照它的规范来作扩展。这样无形就增长了对 Tomcat 的学习成本。不只仅是容器，实际上 Tomcat 也有基于责任链的设计方式，像串联 Pipeline 的 Vavle 设计也是与 Jetty 的 Handler 相似的方式。要本身实现一个 Vavle 与写一个 Handler 的难度不相上下。表面上看，Tomcat 的功能要比 Jetty 强大，由于 Tomcat 已经帮你作了不少工做了，而 Jetty 只告诉，你能怎么作，如何作，有你去实现。

单纯比较 Tomcat 与 Jetty 的性能意义不是很大，只能说在某种使用场景下，它表现的各有差别。由于它们面向的使用场景不尽相同。从架构上来看 Tomcat 在处理少数很是繁忙的链接上更有优点，也就是说链接的生命周期若是短的话，Tomcat 的整体性能更高。

而 Jetty 恰好相反，Jetty 能够同时处理大量链接并且能够长时间保持这些链接。例如像一些 web 聊天应用很是适合用 Jetty 作服务器，像淘宝的 web 旺旺就是用 Jetty 做为 Servlet 引擎。

另外因为 Jetty 的架构很是简单，做为服务器它能够按需加载组件，这样不须要的组件能够去掉，这样无形能够减小服务器自己的内存开销，处理一次请求也是能够减小产生的临时对象，这样性能也会提升。另外 Jetty 默认使用的是 NIO 技术在处理 I/O 请求上更占优点，Tomcat 默认使用的是 BIO，在处理静态资源时，Tomcat 的性能不如 Jetty。