从 Tomcat 和 Jetty 中总结组件化设计规范

如果大家觉得文章有错误内容，欢迎留言或者私信讨论~

  在当今互联网时代人们获取信息的途径非常多，但为什么总有人的理解会更加深刻一些呢？我认为是他们养成了思考和总结的好习惯，这种好习惯能够帮助我们看到现象背后的本质。

  所以我们今天的任务就是总结 Tomcat 和 Jetty 组件设计的规范，以便我们以后在做系统或者框架设计的时候可以从中获取启发。

组件化以及配置

  Tomcat 和 Jetty 的整体架构都是基于组件构成的，你可以通过 xml 文件或者代码的方法配置这些组件，比如我们可以在 server.xml 配置 Tomcat 的连接器以及容器组件。就是说，Tomcat 和 Jetty 提供了积木，让玩家能够自定义积木的搭建。

  那么 Web 如何实现这种组件化设计呢？我认为有两点：

• 第一个是面向接口编程。 我们需要对系统的功能按照“高内聚，低耦合”的原则进行拆分，每个组件都有相应的接口，组件之间通过接口同学，这样就可以方便地替换组件了。比如我们可以选择不同连接器类型，只要这些连接器组件实现同一个接口就行。

• 第二个是**提供一个载体把组件组装到一起。**组件的工作无非就是处理请求，因此容器通过责任链模式把请求依次交给组件去处理。对于用户来说，我们只要告诉容器由哪些组件来处理请求。把组件组织起来需要一个“管理者”，这就是为什么 Tomcat 和 Jetty 都有一个 Server 的概念，Server 就是组件的载体，Server 里包含了连接器组件和容器组件；容器还需要把请求交给各个子容器组件去处理，Tomcat 和 Jetty 都是责任链模式来实现的。

  用户通过配置来组装组件，跟 Spring 中 Bean 的依赖注入相似。Spring 也可以通过配置的方式组装 Bean，Bean 与 Bean 之间的关系由用户来决定。但是这与 Web 容器也有不同，Web 容器中组件与组件的关系是固定，比如 Tomcat 中的 Engine 组件下由 Host 组件，Host 组件下有 Context 组件。

组件的创建

  由于组件时可以配置的，所以容器在启动前也不知道需要创建哪些组件。也就是说组件的创建不是通过硬编码创建的，而是通过动态反射实现的（这点也同 spring 相似）。无论是哪种实现方式，Web 容器需要把组件类加载到 JVM 中，这就涉及到类加载的问题，事实上，Tomcat 甚至还实现了自己的类加载器。

组件的生命周期管理

  这是我们之前提到的 Tomcat 的一键启停的关键。Tomcat 和 Jetty 都采用了类似的办法来管理组件的生命周期，主要有两个要点：

• Tomcat 和 Jetty 都是通过父组件创建子组件的创建、启停和销毁。父组件负责子组件的创建、启停和销毁。这样只要启动最上层的组件，整个 Web 容器就会被启动起来，也就是实现了一键启停。
• Toncat 和 Jetty 都定义了组件的生命周期，并且把状态的转变定义成了事件，一个组件的状态变化会触发子组件的变化，比如 Host 容器的启动事件里会触发 Web 应用的扫描和加载，最终会在 Host 容器下创建相应的 Context 容器，而 Context 组件的启动事件又会触发 Servlet 的扫描，进而创建 Wrapper 组件。那么如何实现这种联动呢？当然就是通过观察者模式。

  Spring 也采用了类似的设计，Spring 给 Bean 的生命周期状态提供了很多“拓展点”。这些扩展点被定义成一个个接口，只要你的 Bean 实现了这些接口，Spring 就会负责调用这些接口，这样做的目的就是，当 Bean 的创建、初始化和销毁这些控制权交给 Spring 后，Spring 让你有机会在 Bean 的整个生命周期中执行你的逻辑。如下图：

组件的骨架抽象类和模板模式

  Tomcat 和 Jetty 都大量采用了骨架抽象类和模板模式。这些抽象骨架类实现了一些通用逻辑，并且会定义一些抽象方法，这些抽象方法由子类实现，抽象骨架类调用抽象方法来实现骨架逻辑。比如比如说 Tomcat 中 ProtocolHandler 接口，ProtocolHandler 有抽象基类 AbstractProtocol，它实现了协议处理层的骨架和通用逻辑。

  而这类设计，不仅仅是 Spring，JDK 中都到处有这样的设计，比如 Java 集合中的 AbstractSet、AbstractMap 等。 值得一提的是，从 Java 8 开始允许接口有 default 方法，这样我们可以把抽象骨架类的通用逻辑放到接口中去。