Shulou(Shulou.com)05/31 Report--

This article mainly explains "what is the principle of Tomcat architecture design". The content of the explanation is simple and clear, and it is easy to learn and understand. Please follow the editor's train of thought to study and learn "what is the principle of Tomcat architecture design".

2.1.1 server

In terms of the most basic functions, the server can simply be regarded as an application (here there is no subdivision of the container server, application server, etc.). It only needs to be able to accept the client's request and parse, and complete the relevant business processing. finally, the processing result is returned to the client as a response.

In general, this function can be achieved by specifying a port on the socket listening server, which can be designed as follows:

We start the server through the start () method, open the socket link, listen on the server port, accept the client's request and return the response. The stop method () is also provided to stop the server and release network resources.

If we do not design a server, but only as a remote request processing scheme embedded in the application system and the QPS requirements are not high, this may be a good solution! However, we are designing an application server

2.1.2 connector and container

In practice, it is quickly found that the scalability of putting request and processing together is very poor, for example, for adapting to multiple network protocols, but the request processing logic is the same. Because tomcat always supports integration with apache, whether it's AJP or HTTP. For example, when web applications are deployed to tomcat separately, HTTP protocol is used; when apache is deployed in a cluster, AJP protocol is used to connect. When switching between the two architectures, the application server tomcat should ensure that the web application does not need to make any changes.

Therefore, it is natural to think of a conceptual separation of network protocols from request processing, as shown in the following figure:

A server can include multiple connector and container. Connector is responsible for opening socket and listening for client requests and returning response data; container is responsible for specific request processing; each has its own start () and stop () methods to load and release resources maintained by itself.

Again, the design still has a drawback, which is how to know which container handles requests from a connector? A more reasonable design should be as follows:

You may have thought that you could solve this problem by maintaining a complex mapping rule, but the fact is that you can do it many times, because the above design is flexible enough! As shown in figure 2-3, a server contains multiple service, and a service is responsible for multiple connector and a container, so that requests from the container can only be processed by the container maintained by the service to which it belongs. Multiple service are independent of each other, but share a JVM and system class library.

In the tomcat specification, it is more common to name the container component engine, which is used to represent the entire servlet engine, but it is important to remember that it is not a servlet container and server represents a servlet container. The engine is only responsible for processing the request, regardless of the processing of the requested link, protocol, return, and so on.

2.1.3 container Design

The previous section solved the decoupling of the protocol and the container, but we designed an application server to deploy and run web applications, which is a running environment, not a specific business processing system. Therefore, we need to support web management applications in the engine container. When receiving a processing request from connector, engine can find a suitable web application to process.

We use context to represent a web application, and an engine can contain multiple context.

At this time, the design has become more and more perfect! But at this time, there is an actual scenario, the online host is responsible for the service of multiple domain names, how should we deal with it? Run multiple application server instances on this host? Sure! But what if only one instance is run?

We can treat each domain name as a virtual host, and each virtual host contains multiple web applications. Client users do not care about these, so the figure is as follows:

A host host can contain multiple context applications.

By reading the servlet specification, we can see that in a web application, multiple servlet instances are included to handle different request links, so another component is required, which is called wrapper in tomcat, so the modified design is as follows:

Up to now, we have mentioned the concept of "container" many times, sometimes referring to engine, sometimes referring to context, but in fact it represents a class of components whose function is to accept requests and return response data. Although the specific operation may be delegated to the child component, it is consistent in terms of behavior definition. Based on this concept, we can modify the design drawing again, as follows:

We use container to represent containers, which can add and maintain child containers, so engine, host, context, and wrapper all inherit container. Service is a combination of engine (before tomcat8.5.6 is a combination of container).

Keep in mind that whether the framework design needs to be so complex depends on the requirements, such as only embedded startup tomcat, do not have to support multi-web applications, then you can only maintain a simplified version of engine in service.

Add:

Tomcat container also has a very important function, that is, background processing, which is used to achieve periodic asynchronous processing, such as scanning for file changes, etc. The implementation principle is that the backgroundProcess () method is defined in container, and its basic abstract class containerbase ensures that background processing is started asynchronously when the component is started. Therefore, in the vast majority of cases, each container component only needs to override this method without having to worry about creating asynchronous threads.

Thank you for your reading, the above is the content of "what is the principle of Tomcat architecture design". After the study of this article, I believe you have a deeper understanding of what the principle of Tomcat architecture design is, and the specific use needs to be verified in practice. Here is, the editor will push for you more related knowledge points of the article, welcome to follow!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.