2.1 overall design
In order to enable the reader to gain a deeper understanding of concepts related components Tomcat, we will use a heuristic to explain the way to introduce the overall design Tomcat. How to design an application server from the start, and gradually improve, until we finally overall architecture Chu Tomcat.
2.1.1 Server
From the most basic function is concerned, we can be described as such an application server:
It receives another computer (client) requests sent data and analyzes, to complete the relevant business processes, and then the processing result as a response back to the requesting computer (the client).
Under normal circumstances, we have to implement this function by using the specified port Socket monitor server. According to the description, a simple design of the server shown in Figure 2-1. 
We start. Method to start the server, open the Socket links, listening server port, and is responsible for processing upon receiving a client request and return a response. While providing a stop () method to stop the server and the release of network resources.
If we design is not a server, just as a remote embedded in the application system request processing program, and our application traffic is low, then this might be a viable option.
However, we have designed is the application server.
2.1.2 Connector and Container
Soon we will find the request listening together with the extension request processing into poor, such as when we want to fit a variety of network protocols, but the request was treated the same. To know Tomcat since its birth, it has always supported integration with Apache, either by agreement or by AJP HTTP protocol. When the Web application deployed independently by Tomcat, we chose to use the HTTP protocol to provide client services; when cluster deployment through Apache, we use the AJP protocol links Wed server (Apache). When the application server (Tomcat) switches in both deployment architecture, you should ensure that Web applications do not need to make any changes.
So how do we solve this problem through an object-oriented approach? Natural idea is to separate the network protocol with the request from the conceptual Thus, we made the following improvements (see Figure 2-2). 
A Server can contain multiple Connector and Container. Wherein Socke Connector is responsible for opening and listen for client requests, returns the response data; Container responsible for specific request processing. Connector and Container each have their own start. And stop () method to load and release resources to maintain their own.
However, this design has obvious flaws. Since Server can contain multiple Connector and Container, you know how a request from a Connector Container by which to deal with it? Of course, we can maintain a complex mapping rules to solve this problem, but this is not necessary, you will find the following chapters Container design has been flexible enough and does not require a Connect. Storing a plurality of received Container. More rational manner shown in Figure 2-3. 
Server includes a plurality of Service (they are independent of each other, but share a JVM and system libraries), a Service is responsible for maintaining a more Connector and Container, such a request can only be made from the Connector to which it belongs Container Service maintenance treatment.
In Tomcat, Container is a more general concept. For those in Tomcat component named the same, we will Container® new name for the Engine, to represent the entire Servlet engine. Modified design shown in Figure 2-4.
Note should be noted that the description herein, Engine represents the entire Servlet engine, rather than a Servlet container. Servlet container that represents the entire Server. Processing engine is only responsible for the request and does not need to consider the request processing links, protocol, etc. 
2.1.3 Container design
On a design it has solved the decoupling network protocols and containers, but the application server is used to deploy and run Web applications, is a runtime environment, rather than a stand-alone business processing system. Therefore, we need to support the management of Web applications in Engine container, when the processing request is received Connector, Engine container able to find a suitable Web applications to deal with.
Then on the basis of the design of Figures 2-4 on a relatively simple implementation shown in Figure 2-5. 
We use the Context to represent a Web application and a Engine can contain multiple Context.
Note: Context also has a start () and stop. Method for loading resources at startup and release resources when you stop. In this way design, we will be loading and unloading process to break down each component of resources among the components fully decoupled, improve server scalability and maintainability. In the follow-up to explain the process, the majority of the new assembly will have the same approach, we will not repeat them.
This is not a reasonable solution it?
Imagine that we have a host, it took multiple domain names services, such as news.mycompany.com and article. Mycompany.com by the host processing, how can we achieve it? Of course, we can run multiple server instances on the host, but if we want to run a server instance of it? Because, as an application server, we should try to provide flexible deployment.
Since we want to offer more domain name services, then it can be regarded as a domain name for each virtual host that contains multiple Web applications in each virtual host. Because for client users, they do not understand the server using several hosts to provide services for them, just know what each domain name services, therefore, the application server for each domain as a virtual host from the abstract concept It is reasonable. According to the design idea to modify Figure 2-6 shows the 
concept we use a small table Host virtual host, -Host can contain multiple [ 'Context.
Note: Tomcat designs, Engine both include Host, and can include Context, which is determined by the specific Engine implementation, and Tomcat adopt a common concept to solve this problem, we will explain in detail in subsequent sections. The default implementation provided by Tomcat StandardEngine only contain Host.
If you read the Servlet specification, we will know in a Web application, Servlet may contain multiple instances to process requests from different links. Therefore, we need a concept to represent the Servlet component definition. In Tomcat, Servlet defined referred Wrapper, based on this modified design shown in Figure 2-7. 
Up to now, we have repeatedly mentioned the concept of "container." Although in the specific section, the container is not the same meaning, sometimes referred Engine, sometimes referred to as Context, but it represents a class of components, such components is to effect the processing request received from the client and returns the response data. While specific actions may be delegated to a sub-assembly is complete, but from the behavior definition, they are consistent. Based on this concept, we have again revised our design, shown in Figure 2-8.
We used to represent containers Container, Container can add and maintain the child container, Engine, Host, Context, Wrapper inherit from the Container. We combined the relationship between them to be dashed to indicate a weak dependence relationship therebetween, i.e., the relationship between them is the concept of parent-child container by Container embodied. But Service Engine is held by the interface (the interface for the Container, more versatile version prior to 8.5.6).
Note: Since the Tomcat Container may represent different conceptual level: Servlet engine, web hosting, Web applications and Servlet, then we can be different levels of container as an assembly process client requests and complex that specifically provided by our server degree decision. If we start Tomcat embedded way, and run a very simple request processing, Web applications do not have to support multi-scene, then we can only maintain a simplified version of the Service Engine before (8.5.6 can even directly by the Service maintain a Context) o of course, the default implementation uses a Tomcat 2-8 this most flexible way, but, we have to understand the theoretical model designed Tomcat scalability, which is a middleware product architecture design needed focus. 
In addition, Tomcat Container is also a very important function, namely background processing. In many cases, we need to perform some of Container asynchronous processing, and is performed regularly, such as once every 30 seconds to perform, Tomcat Web application file for change is through the scanning mechanism to achieve. Tomcat for background processing, defined backgroundProcess () method on Container, base and which is an abstract class (ContainerBase) while ensuring at the start of assembly, the asynchronous start background processing. Therefore, in most cases, the individual components of the container only needs to implement background Container of? Process. The method can be, do consider creating asynchronous thread.
2.1.4 Lifecycle
Before we go further refine the application server design, we want to reuse levels from the abstract and then look at the results of the current design, make the concept more clearly, to provide a common definition for unified management of application servers.
It is easy to find, all components are present start, stop, and other life-cycle approach, with the nature of life cycle management. Therefore, we can abstract the interface based on a life-cycle management, shown in Figure 2-9.
We Lifecycle abstract a common interface for all components have a life cycle management features, the interface defines the core method of life cycle management.
□ Init (): initialize components.
□ start (): Start component.
□ stop (): Stop components.
□ destroy (): the destruction of components. 
At the same time, the interface supports conversion between state and state assemblies to support the status change to add event listeners (LifecycleListener) for monitoring components. So, we can adopt a consistent mechanism to initialize, start, stop and destruction of individual components. Tomcat core components such as the default implementation inherit from LifecycleMBeanBase abstract class that not only is responsible for converting each state and event handling components, the component itself will be registered as a MBean, for dynamic maintenance through the Tomcat management tool.
In the state of FIG Tomcat Lifecycle interface shown in Figure 2-10.
First, each method may correspond to the life cycle converts the number of states to start (), for example, which is divided into before starting, starting, has started, automatic conversion conversion paths (all identified as auto between these three states It is automatically converted in the life cycle method, no additional method calls). 
Secondly, not every state will trigger life-cycle events, not all life cycle events exist in the corresponding state. Application life cycle state corresponding to the event is shown in Table 2-1. 
We can see the impact of each event component states and each state lifecycle approach triggered detail from Table 2-1. In addition, we also noted, Tomcat provides three default state is independent of the type of event, which is mainly used for background Container PERIODIC_EVENT timing processing, the event is triggered after each call. CONFIGURE_START_EVENT CONFIGURE_STOP_EVENT and will use mentioned in the following sections.
PS: learning is gradual, is discouraged, I believe in yourself, you can! !
get more learning materials: https://shimo.im/docs/TC9Jq63Tp6HvTXdg