Tomcat源码分析 （二）----- Tomcat整体架构及组件

LD is tigger forever，CG are not brothers forever， throw the pot and shine forever.
Modesty is not false, solid is not naive, treacherous but not deceitful, stay with good people, and stay away from poor people.
talk is cheap, show others the code and KPI， Keep progress，make a better result.
Survive during the day and develop at night。

目录

概 述

Tomcat启动流程分析
除了Bootstrap和catalina类，其他的Server,service等等之类的都只是一个接口，实现类均为StandardXXX类。

我们可以看到这个流程非常的清晰，同时注意到，Tomcat的启动非常的标准，除去Boostrap和Catalin，我们可以对照一下Server.xml的配置文件。Server,service等等这些组件都是一一对照，同时又有先后顺序。

基本的顺序是先init方法，然后再start方法。

加入调试信息()：注意是标准的启动，也就是从bin目录下的启动文件中启动Tomcat
分析Tomcat请求过程
解耦：网络协议与容器的解耦。
Connector链接器封装了底层的网络请求(Socket请求及相应处理),提供了统一的接口，使Container容器与具体的请求协议以及I/O方式解耦。
Connector将Socket输入转换成Request对象，交给Container容器进行处理，处理请求后，Container通过Connector提供的Response对象将结果写入输出流。
因为无论是Request对象还是Response对象都没有实现Servlet规范对应的接口，Container会将它们进一步分装成ServletRequest和ServletResponse.
问题来了，在Engine容器中，有四个级别的容器，他们的标准实现分别是StandardEngine、StandardHost、StandardContext、StandardWrapper。

组件的生命周期管理

各种组件如何统一管理

Tomcat的架构设计是清晰的、模块化、它拥有很多组件，加入在启动Tomcat时一个一个组件启动，很容易遗漏组件，同时还会对后面的动态组件拓展带来麻烦。如果采用我们传统的方式的话，组件在启动过程中如果发生异常，会很难管理，比如你的下一个组件调用了start方法，但是如果它的上级组件还没有start甚至还没有init的话，Tomcat的启动会非常难管理，因此，Tomcat的设计者提出一个解决方案：用Lifecycle管理启动，停止、关闭。

为什么LifecycleBase这么玩，其实很多架构源码都是这么玩的，包括JDK的容器源码都是这么玩的，一个类，有一个接口，同时抽象一个抽象骨架类，把通用的实现放在抽象骨架类中，这样设计就方便组件的管理，使用LifecycleBase骨架抽象类，在抽象方法中就可以进行统一的处理，具体的内容见下面。

具体实现类StandardXXX类调用initInternal方法实现具体的业务处理。

分析Tomcat请求过程
Tomcat诞生时，服务器资源很贵，所以一般一台服务器其实可以有多个域名映射，满了满足这种需求，比如，我的这台电脑，有一个localhost域名，同时在我的hosts文件中配置两个域名，一个www.a.com 一个localhost。
container从上一个组件connector手上接过解析好的内部request，根据request来进行一系列的逻辑操作，直到调用到请求的servlet，然后组装好response，返回给connecotr

先来看看container的分类吧：
Engine
Host
Context
Wrapper

它们各自的实现类分别是StandardEngine, StandardHost, StandardContext, and StandardWrapper，他们都在tomcat的org.apache.catalina.core包下。

Tomcat处理一个HTTP请求的过程
用户点击网页内容，请求被发送到本机端口8080，被在那里监听的Coyote HTTP/1.1 Connector获得。
Connector把该请求交给它所在的Service的Engine来处理，并等待Engine的回应。
Engine获得请求localhost/test/index.jsp，匹配所有的虚拟主机Host。
Engine匹配到名为localhost的Host（即使匹配不到也把请求交给该Host处理，因为该Host被定义为该Engine的默认主机），名为localhost的Host获得请求/test/index.jsp，匹配它所拥有的所有的Context。Host匹配到路径为/test的Context（如果匹配不到就把该请求交给路径名为“ ”的Context去处理）。

path=“/test”的Context获得请求/index.jsp，在它的mapping table中寻找出对应的Servlet。Context匹配到URL PATTERN为*.jsp的Servlet,对应于JspServlet类。

构造HttpServletRequest对象和HttpServletResponse对象，作为参数调用JspServlet的doGet（）或doPost（）.执行业务逻辑、数据存储等程序。
Context把执行完之后的HttpServletResponse对象返回给Host。

Host把HttpServletResponse对象返回给Engine。
Engine把HttpServletResponse对象返回Connector。
Connector把HttpServletResponse对象返回给客户Browser。

管道模式
管道是就像一条管道把多个对象连接起来，整体看起来就像若干个阀门嵌套在管道中，而处理逻辑放在阀门上。

它的结构和实现是非常值得我们学习和借鉴的。
首先要了解的是每一种container都有一个自己的StandardValve

上面四个container对应的四个是：

StandardEngineValve
StandardHostValve

StandardContextValve

StandardWrapperValve

手写管道模式实现

我们了解到了，在管道中连接一个或者多个阀门，每一个阀门负责一部分逻辑处理，数据按照规定的顺序往下流。此种模式分解了逻辑处理任务，可方便对某个任务单元进行安装、拆卸，提高流程的可拓展性，可重用性，机动性，灵活性。

在CoyoteAdapter的service方法里，由下面这一句就进入Container的。
connector.getContainer().getPipeline().getFirst().invoke(request, response);
是的，这就是进入container迷宫的大门，欢迎来到Container。

来自org.apache.catalina.core.StandardEngineValve的invoke方法：
其他的类似StandardHostValve、StandardContextValve、StandardWrapperValve

管道机制给我们带来了更好的拓展性，例如，你要添加一个额外的逻辑处理阀门是很容易的。
自定义个阀门PrintIPValve，只要继承ValveBase并重写invoke方法即可。注意在invoke方法中一定要执行调用下一个阀门的操作，否则会出现异常。
public class PrintIPValve extends ValveBase{

@Override

public void invoke(Request request, Response response) throws IOException, ServletException {

    System.out.println("------自定义阀门PrintIPValve:"+request.getRemoteAddr());

    getNext().invoke(request,response);

}

}

配置Tomcat的核心配置文件server.xml,这里把阀门配置到Engine容器下，作用范围就是整个引擎，也可以根据作用范围配置在Host或者是Context下。

源码中是直接可以有效果，但是如果是运行版本，则可以将这个类导出成一个Jar包放入Tomcat/lib目录下，也可以直接将.class文件打包进catalina.jar包中。

Tomcat中提供常用的阀门

AccessLogValve，请求访问日志阀门，通过此阀门可以记录所有客户端的访问日志，包括远程主机IP，远程主机名，请求方法，请求协议，会话ID，请求时间，处理时长，数据包大小等。它提供任意参数化的配置，可以通过任意组合来定制访问日志的格式。

JDBCAccessLogValve，同样是记录访问日志的阀门，但是它有助于将访问日志通过JDBC持久化到数据库中。

ErrorReportValve，这是一个讲错误以HTML格式输出的阀门
PersistentValve，这是对每一个请求的会话实现持久化的阀门

RemoteAddrValve，访问控制阀门。可以通过配置决定哪些IP可以访问WEB应用
RemoteHostValve，访问控制阀门，通过配置觉得哪些主机名可以访问WEB应用
RemoteIpValve，针对代理或者负载均衡处理的一个阀门，一般经过代理或者负载均衡转发的请求都将自己的IP添加到请求头”X-Forwarded-For”中，此时，通过阀门可以获取访问者真实的IP。
SemaphoreValve，这个是一个控制容器并发访问的阀门，可以作用在不同容器上。

小结

参考资料和推荐阅读

1.链接: 参考资料.