Tomcat底层结构的简单总结

起因：在帮公司找几个实习生应届生，在校的刚出来，简历却非常丰富，Struts，Spring，Nginx都写着‘熟练’甚至有‘精通’，但是当问起Struts为什么要部署在tomcat，spring不用，不知道。为什么nginx能做反向代理，怎么代理，不知道。客户端发起的请求怎么找到服务端的Service，不知道。再问什么是Tomcat，就背出概念说是web服务器，再问它怎么工作的，又是一连串‘不知道’和‘这个我没去了解过，如果公司有要求我可以去学’…我问的真的没有一个刁难刁钻的问题，我不会叫他们写出责任链逐层调用过程，不会叫他们背诵Tomcat启动时候创建容器的步骤，更加没有变态到问他们Tomcat的某个方法，某行代码干什么用。那些是搞底层科研或者深层级大佬去搞的，我这种专写业务的小菜鸡其实更偏重于实用性。

Struts和Spring的项目，都靠Tomcat来启动服务提供服务，只不过Spring是内嵌了Tomcat，所以我们不需要再把它放到Tomcat的WebApps目录下再启动Tomcat运行那么麻烦。Nginx做的反向代理中，是针对多个启动了的本地服务做的代理，也就是作为Tomcat服务器的代理，其中那些端口号，域名，都是在Tomcat中配置指定的。而客户端发起的一个请求URL，也是通过Tomcat服务器帮我们找到对应的Service的。由此可见真的由头到尾都离不开这个大二上学期学到的Tomcat服务器。

什么是Tomcat？

tomcat是Apache和Sun公司合作的一个项目做出来的一款产品，它的作用就是Web服务器，最简单来说就是专门用来“接收请求，处理请求，返回响应”。它是Java写的一款产品，启动类是BootStrap.Class中的Main方法。

为什么也说是ServLet容器？

servlet是对应一个请求一个service方法处理的，一套系统会有很多很多servlet，如果不用tomcat，那么每个人都写每个人模块的servlet虚拟映射路径，一千个人有一千个哈姆雷特，就出现了甚至同一个模块下因为开发者不同而出现不同映射路径的Servlet，设计非常的不银杏，而且调用时候通过一一对应的硬编码，也非常的不雅观，而tomcat就是通过Catalina容器来管理这一堆的Servlet，当请求过来的时候，tomcat就通过逐层解析，帮我们找到最终对应的servlet调用。
所谓容器的概念，就是里面放着很多已经加载好的业务模块的Service，接受请求，找到对应的ServerLet调用service方法进行处理（如果对应的业务类还未加载，则通过init方法反射创建后再调用），返回结果。

Tomcat的底层结构：