Eine kurze Diskussion über das Design des Tomcat-Mehrschichtcontainers

Der Container von Tomcat wird zum Laden des Servlets verwendet. Wie ist also der Servlet-Container von Tomcat konzipiert?

Containerhierarchie

Tomcat hat vier Container entwickelt: Engine, Host, Context und Wrapper

Durch diese Schichtung macht Tomcat den Servlet-Container sehr flexibel.

• Der Kontext stellt eine Webanwendung dar
• Wrapper stellt ein Servlet dar. In einer Webanwendung können mehrere Servlets vorhanden sein.
• Host stellt einen virtuellen Host oder eine Site dar. Sie können mehrere virtuelle Hostadressen für Tomcat konfigurieren und mehrere Webanwendungen können unter einem virtuellen Host bereitgestellt werden.
• Engine stellt die Engine dar, die zur Verwaltung mehrerer virtueller Sites verwendet wird. Ein Dienst kann höchstens eine Engine haben.
  

Beachten Sie die Konfigurationsdatei server.xml von Tomcat. Tomcat verwendet ein komponentenbasiertes Design, wobei die äußerste Schicht der Server ist

Diese Container haben eine Eltern-Kind-Beziehung und bilden eine Baumstruktur. Tomcat verwendet einen zusammengesetzten Modus, um diese Container zu verwalten.

Alle Containerkomponenten implementieren die Containerschnittstelle, sodass der Composite-Modus es Benutzern ermöglicht,

Der Wrapper auf unterster Ebene eines einzelnen Containerobjekts

Kontext, Host oder Engine für das zusammengesetzte Containerobjekt
Die Verwendung von ist konsistent.

Container-Schnittstellendefinition:

öffentliche Schnittstelle Container erweitert Lebenszyklus {
    öffentliche void setName(String name);
    öffentlicher Container getParent();
    öffentliche void setParent(Container Container);
    öffentliche void addChild(Container-Unterelement);
    öffentliche void removeChild(Container-Unterelement);
    öffentlicher Container findChild(Stringname);
}

Der Prozess der Anforderung zur Lokalisierung des Servlets

Wie ermittelt Tomcat bei so vielen Containerebenen, welches Servlet in welchem ​​Wrapper-Container die Anforderung verarbeitet?
Tomcat verwendet die Mapper-Komponente, um diese Aufgabe auszuführen.

Mapper lokalisiert die vom Benutzer angeforderte URL zu einem Servlet

So funktioniert es

Die Mapper-Komponente speichert die Konfigurationsinformationen der Webanwendung: die Zuordnungsbeziehung zwischen der Containerkomponente und dem Zugriffspfad, wie z. B.

• Im Host-Container konfigurierter Domänenname
• Web-Anwendungspfad im Context-Container
• Pfad der Servlet-Zuordnung im Wrapper-Container

Diese Konfigurationsinformationen stellen eine mehrstufige Karte dar.

Wenn eine Anforderung eingeht, kann die Mapper-Komponente ein Servlet lokalisieren, indem sie den Domänennamen und den Pfad in der Anforderungs-URL analysiert und dann in der gespeicherten Map sucht.
Eine Anforderungs-URL findet letztendlich nur einen Wrapper-Container, also ein Servlet.

Wenn es ein Online-Shopping-System gibt,

• Backend-Verwaltungssystem für B-Seiten-Manager
• Online-Shopping-System für C-End-Benutzer

Die beiden Systeme laufen auf demselben Tomcat. Um ihre Zugriffsdomänennamen zu isolieren, werden zwei virtuelle Domänennamen konfiguriert:

verwalten.shopping.com
Administratoren greifen über diesen Domänennamen auf Tomcat zu, um Benutzer und Produkte zu verwalten. Benutzerverwaltung und Produktverwaltung sind zwei separate Webanwendungen.

benutzer.shopping.com
C-End-Benutzer verwenden diesen Domänennamen, um nach Produkten zu suchen und Bestellungen aufzugeben. Die Suchfunktion und die Bestellverwaltung sind ebenfalls zwei unabhängige Webanwendungen.

Bei dieser Bereitstellung erstellt Tomcat eine Servicekomponente und eine Engine-Containerkomponente, zwei Host-Untercontainer unter dem Engine-Container und zwei Context-Untercontainer unter jedem Host-Container. Da eine Webanwendung normalerweise über mehrere Servlets verfügt, erstellt Tomcat in jedem Kontextcontainer auch mehrere Wrapper-Untercontainer. Jeder Container hat einen entsprechenden Zugriffspfad

Wie findet Tomcat eine URL zu einem Servlet?

Wählen Sie zunächst Service und Engine entsprechend dem Protokoll und der Portnummer aus.
Jeder Connector von Tomcat überwacht einen anderen Port. Beispielsweise überwacht der Standard-HTTP-Connector von Tomcat Port 8080 und der Standard-AJP-Connector Port 8009. Diese URL greift auf Port 8080 zu, sodass sie vom HTTP-Connector empfangen wird. Da ein Connector zu einer Servicekomponente gehört, wird die Servicekomponente bestimmt. Zusätzlich zu mehreren Konnektoren verfügt eine Servicekomponente auch über einen Engine-Container, sodass mit der Bestimmung des Service auch die Engine bestimmt wird.

Wählen Sie den Host basierend auf dem Domänennamen aus.
Die Mapper-Komponente sucht über den Domänennamen in der URL (z. B. user.shopping.com) nach dem entsprechenden Host-Container, sodass der Mapper den Host2-Container findet.

Suchen Sie die Kontextkomponente anhand des URL-Pfads
Nachdem der Host ermittelt wurde, gleicht der Mapper den Pfad der entsprechenden Webanwendung anhand des URL-Pfades ab. Wird im Beispiel beispielsweise auf /order zugegriffen, so wird der Kontextcontainer Context4 gefunden.

Suchen Sie schließlich den Wrapper (Servlet) basierend auf dem URL-Pfad
Nachdem der Kontext bestimmt wurde, findet der Mapper den spezifischen Wrapper und das Servlet gemäß dem in web.xml konfigurierten Servlet-Mapping-Pfad.

Servlets sind nicht die einzigen, die Anfragen verarbeiten. Übergeordnete und untergeordnete Container im Suchpfad verarbeiten ebenfalls die Anfragen:

• Der Adapter im Connector ruft die Service-Methode des Containers auf, um das Servlet auszuführen.
• Der erste Container, der die Anforderung empfängt, ist der Engine-Container. Nach der Verarbeitung der Anforderung übergibt der Engine-Container die Anforderung zur weiteren Verarbeitung an seinen untergeordneten Container Host usw.
• Schließlich wird die Anforderung an den Wrapper-Container übergeben und der Wrapper ruft das letzte Servlet auf, um sie zu verarbeiten.

Dieser Aufrufprozess verwendet die Pipeline-Valve-Pipeline und das Verantwortungskettenmodell. Während eines Anforderungsverarbeitungsprozesses verarbeiten viele Handler die Anforderung nacheinander. Jeder Handler ist für seine eigene Verarbeitung verantwortlich. Nach der Verarbeitung wird der nächste Handler aufgerufen, um die Verarbeitung fortzusetzen.

Valve stellt einen Verarbeitungspunkt dar, beispielsweise für die Berechtigungsauthentifizierung und Protokollierung.

öffentliche Schnittstelle Valve {
  öffentliches Valve getNext();
  öffentliche void setNext(Ventil Ventil);
  public void invoke (Anfrage Anfrage, Antwort Antwort)
}

Da Valve ein Verarbeitungspunkt ist, wird die Invoke-Methode zum Verarbeiten der Anforderung verwendet.
Pipeline-Schnittstelle:

öffentliche Schnittstelle Pipeline erweitert Contained {
  öffentliche void addValve(Ventil Ventil);
  öffentliches Valve getBasic();
  öffentliche void setBasic(Ventil Ventil);
  öffentliches Valve getFirst();
}

Daher wird in der Pipeline eine verknüpfte Ventilliste verwaltet und das Ventil kann in die Pipeline eingefügt werden.
In der Pipeline gibt es keine Aufrufmethode, da die gesamte Aufrufkette durch den Aufruf von getNext.invoke ausgelöst wird, um das nächste Ventil aufzurufen, nachdem das Ventil seine eigene Verarbeitung abgeschlossen hat.

Jeder Container hat ein Pipeline-Objekt. Sobald das erste Ventil der Pipeline ausgelöst wird, werden alle Ventile in der Pipeline dieses Containers aufgerufen. Aber wie kann man Pipelines verschiedener Container verketten?
Beispielsweise muss die Pipeline in der Engine die Pipeline im Container-Host auf niedrigerer Ebene aufrufen.
Pipeline hat eine getBasic-Methode. Dieses BasicValve steht am Ende der Valve-Kette und ist für den Aufruf des ersten Valves in der Pipeline des unteren Containers zuständig.

Der gesamte Aufrufvorgang wird durch den Adapter im Connector ausgelöst, der das erste Ventil der Engine aufruft:

Verpackung

Das letzte Ventil des Containers erstellt eine Filterkette und ruft die Methode doFilter auf, die schließlich zur Servicemethode des Servlets aufgerufen wird.

Was ist der Unterschied zwischen Ventil und Filter?

• Valve ist der private Mechanismus von Tomcat und eng mit Tomcat gekoppelt. Servlet API ist ein öffentlicher Standard und alle Webcontainer, einschließlich Jetty, unterstützen Filter
• Valve arbeitet auf der Ebene des Webcontainers und fängt alle Anwendungsanforderungen ab. Servlet-Filter arbeiten auf Anwendungsebene und fangen nur alle Anfragen für eine bestimmte Webanwendung ab. Wenn Sie ein Interceptor für den gesamten Web-Container sein möchten, müssen Sie Valve verwenden.

Dies ist das Ende dieses Artikels über das Design des Tomcat-Mehrschichtcontainers. Weitere relevante Inhalte zum Tomcat-Mehrschichtcontainer finden Sie in früheren Artikeln auf 123WORDPRESS.COM oder in den folgenden verwandten Artikeln. Ich hoffe, dass jeder 123WORDPRESS.COM in Zukunft unterstützen wird!