参考：Tomcat架构解析
单工程架构则已经远远不能满足现有业务需求了。 所以在这种情况下，淘宝在13年开启了插件化架构的重构，后来在14年迎来了手机淘宝有史以来最大规模的重构，将项目重构为组件化架构。
在tomcat中各种容器也就是着各种组件的形式进行设计。 所有的组件均存在启动、定制等生命周期方法，拥有生命周期管理的特性，然后根据组件的这一特点抽象一个Lifecycle通用接口，
init（）：初始化组件。 start（）：启动组件。 stop（）：停止组件。 destory（）：销毁组件。
首先，每个生命周期方法可能对应数个状态的转换，以start（）为例，即分为启动前、启动中、已启动，这3哥状态之间自动转换（所有标识为aoto的转换路径都是在生命周期方法中自动转换的，不再需要额外的方法调用）。
其次，并不是每个状态都会触发生命周期事件，也不是所有生命周期事件均存在对应状态。状态与生命周期事件的对应如下
各个组件的细分，已经可以满足web应用的支持，确保了整体架构的可伸缩性和可扩展性。 但Tomcat希望进一步提高每个组件的灵活性，使其易于扩展。 tomcat定义了Pipeline（管道）和Valve（阀）两个接口。 前者用于构造职责链，后者代表职责链上的每个处理器。 类似角色扮演，客户端的请求就像流经管道的水一般，经过每个阀进行处理。 Pipeline中维护一个基础的Valve，它始终位于Pipeline的末端（最后执行），封装了具体的请求处理的输出响应的过程。然后通过addValve（）方法，我们可以为Pipeline添加其他的Valve。后添加的Valve位于基础Valve之前，并按照添加顺序执行。Pipeline通过获得首个Valve来启动整个链条的执行。 每个层级的容器（Engine、HostContext、Wrapper）均有对应的基础Valve实现，同时维护了一个Pipeline实例。也就是说，我们可以在任何层级的容器上针对请求处理进行扩展。 Tomcat每个层级的容器均通过Pipeline和Valve进行请求处理，那么，我们很容易将一些通用的Valve实现根据需要添加到任何层级的容器上。
