[Tomcat] Tomcat 관련 디자인 패턴 분석

파사드 모드

파사드 패턴은 Tomcat의 여러 곳에서 사용됩니다. 이 디자인 패턴은 요청 및 응답 객체 캡슐화, 표준 래퍼에서 ServletConfig 캡슐화, ApplicationContext에서 ServletContext 캡슐화 등에 사용됩니다.

외관 디자인 패턴의 원리

이 디자인 패턴은 여러 경우에 사용되었는데, 이 디자인 패턴의 역할은 정확히 무엇인가요? 이름에서 알 수 있듯이, 한 나라의 외교부처럼 다른 사람과의 의사소통을 더 쉽게 하기 위해 무엇인가를 파사드 안에 캡슐화하는 것입니다.

이 디자인 패턴은 대규모 시스템이 여러 하위 시스템으로 구성되어 있을 때 주로 사용됩니다. 이러한 하위 시스템은 서로 통신해야 하지만 각 하위 시스템은 자체 내부 데이터를 다른 시스템에 너무 많이 노출할 수 없습니다. 그렇지 않으면 하위 시스템을 나눌 필요가 없습니다. 각 하위 시스템은 다른 시스템의 관심 데이터를 캡슐화하고 이 Facade를 통해 액세스할 수 있는 Facade를 설계합니다. 이것이 파사드 디자인 패턴의 목적입니다.

파사드 디자인 패턴의 개략도는 다음과 같습니다.

사진 1. 외관 다이어그램

클라이언트는 Façade에서 제공하는 데이터에만 접근할 수 있으며, 이는 Façade 디자인 패턴의 핵심입니다. Client가 Façade에 접근하는 방법과 Subsystem이 Façade를 제공하는 방법은 Façade 디자인 패턴에 규정되어 있지 않습니다.

Tomcat 외관 모드 예

Tomcat에는 다양한 구성 요소가 있고 각 구성 요소가 서로 데이터를 상호 작용해야 하기 때문에 파사드 디자인 패턴을 많이 사용합니다. 데이터를 분리하기 위해 파사드 패턴을 사용하는 것이 좋은 방법입니다.

다음은 요청에 사용된 외관 디자인 패턴입니다:

그림 2. 요청의 파사드 디자인 패턴 클래스 다이어그램

그림에서 볼 수 있듯이 HttpRequestFacade 클래스는 HttpRequest 인터페이스를 캡슐화하여 데이터를 제공합니다. HttpRequestFacade를 통해 액세스되는 데이터는 일반적으로 HttpRequest에서 액세스 수정을 방지하기 위해 캡슐화된 개체를 비공개 또는 보호된 액세스 수정으로 설정합니다. Façade에 직접 액세스할 수 있습니다.

관찰자 모드

이 디자인 패턴은 일반적으로 이벤트 수신 메커니즘인 게시-구독 패턴이라고도 하는 일반적으로 사용되는 디자인 방법입니다.

관찰자 패턴의 원리

관찰자 모드의 원리도 매우 간단합니다. 즉, 관심 있는 일을 할 때 항상 옆에 누군가가 지켜보고 있다는 것입니다. 그러나 당신을 쳐다보는 사람은 당신에게 등록해야 합니다. 그렇지 않으면 당신은 그 사람에게 알릴 수 없습니다. 관찰자 패턴에는 일반적으로 다음과 같은 역할이 포함됩니다.

• Subject는 추상적인 주제입니다. 모든 관찰자의 참조를 관리하고 주요 이벤트 운영을 정의하는 역할을 담당합니다.
• ConcreteSubject 구체적인 주제: 추상 주제에 대해 정의된 모든 인터페이스를 구현하며 변경 시 모든 관찰자에게 알립니다.
• 관찰자 관찰자: 주제의 변경 사항에 대해 해당 작업 인터페이스를 모니터링합니다.

Tomcat의 관찰자 패턴 예

관찰자 모드는 Tomcat의 여러 곳에서도 사용됩니다. 앞서 언급한 구성 요소 수명 주기를 제어하는 ​​Lifecycle이 이 모드의 구현입니다. 서블릿 인스턴스 생성, 세션 관리, 컨테이너 등에 적용됩니다. 다음은 Lifecycle의 구체적인 구현을 주로 살펴봅니다.

Lifecycle의 관찰자 패턴 구조 다이어그램:

그림 3. 라이프사이클의 관찰자 패턴 구조 다이어그램

위 구조도에서 LifecycleListener는 lifecycleEvent 메서드를 정의하는 추상 관찰자를 나타냅니다. 이 메서드는 테마가 변경될 때 실행되는 메서드입니다. ServerLifecycleListener는 특정 관찰자를 나타냅니다. 이는 이 특정 관찰자의 특정 구현인 LifecycleListener 인터페이스의 메서드를 구현합니다. Lifecycle 인터페이스는 관찰자 관리 방법과 수행해야 하는 기타 방법을 정의하는 추상 주제를 나타냅니다. StandardServer는 추상 주제의 모든 메소드를 구현하는 특정 주제를 나타냅니다. 여기서 Tomcat은 관찰자를 확장하고 관찰자의 기능을 확장하기 위한 보조 클래스 역할을 하는 LifecycleSupport 및 LifecycleEvent라는 두 개의 다른 클래스를 추가했습니다. LifecycleEvent를 사용하면 이벤트 카테고리를 정의할 수 있으며 다양한 이벤트를 다르게 처리할 수 있어 더욱 유연해집니다. LifecycleSupport 클래스는 여러 관찰자의 토픽 관리를 나타냅니다. 이 관리는 나중에 수정하는 경우 특정 토픽을 모두 수정할 필요가 없습니다. 관찰자에 대한 작업이 LifecycleSupport 클래스에 위임됩니다. 이는 Observer 패턴의 향상된 버전이라고 생각할 수 있습니다.

LifecycleSupport의 관찰자 호출 메소드 코드는 다음과 같습니다.

목록 1. LifecycleSupport의 fireLifecycleEvent 메서드

으아악

테마는 관찰자에게 어떻게 알리나요? 아래 코드를 보세요:

목록 2. 컨테이너의 시작 방법

으아악

Tomcat7의 코드 중 이 부분을 살펴보겠습니다. 이전 기사에서는 서비스의 시작 프로세스가 서버에 의해 관리된다고 말했습니다. Server 인터페이스의 클래스가 StandardServer 클래스인 경우, StandServer에서 관리하는 서비스를 주기적으로 시작하는 프로세스인 startInernal() 메소드가 Lifecycle 인터페이스를 구현하므로 관리되는 서비스에 알림이 전달됩니다. , 이에 따라 start() 메서드, startIntenal() 메서드가 실행됩니다.

으아악

이제 모든 서비스가 알림을 수신하고 시작 메소드를 실행합니다. 서비스 사용이 허용되지 않으면 LifecycleException이 발생합니다.

stopIntenal()은 모든 서비스에 stop 메소드를 실행하도록 알립니다. 구체적인 처리 프로세스는 startIntenal() 메소드와 유사합니다.

위 코드 목록의 핵심은 fireLifecycleEvent() 메소드에 있으며, 실행 과정은 다음과 같습니다.

1. LifecycleBase의 fireLifecycleEvent(LifecycleListener 리스너) 메서드를 호출하세요. LifecycleBase는 Lifecycle 인터페이스를 구현하는 추상 클래스입니다
2. LifecycleSupport의 fireLifecycleEvent(문자열 유형, 개체 데이터) 메서드를 계속 호출합니다(등록된 리스너를 위한 보조 이벤트 알림 클래스, 상속할 수 없음, 최종 사용)
3. 이벤트 완료 알림

fireLifecycleEvent(문자열 유형, 개체 데이터)의 방법은 다음과 같습니다.

으아악

따라서 특정 이벤트에 대한 알림은 LifecycleListener 인터페이스의 lifecycleEvent 메서드에 의해 완료됩니다. 각 구현 클래스는 상황에 따라 다양한 이벤트 수신 로직을 구현할 수 있습니다.

명령 모드

앞서 Tomcat의 두 가지 핵심 구성 요소인 커넥터와 컨테이너를 한 쌍으로 비교했습니다. 남자는 수락된 요청을 명령의 형태로 안주인에게 건네줍니다. Connector, Container에 대응하여 Connector도 Command 모드를 통해 Container를 호출합니다.

명령 모드의 원리

명령 모드의 주요 기능은 명령을 캡슐화하고 명령 실행 책임과 명령 실행 책임을 분리하는 것입니다. 이는 기능적 분업이기도 하다. 모듈마다 동일한 명령을 다르게 해석할 수 있습니다.

다음은 일반적으로 다음 역할을 포함하는 명령 모드입니다.

• 클라이언트: 명령을 생성하고 수신자를 결정합니다
• 명령 명령: 명령 인터페이스는 추상 메서드를 정의합니다
• ConcreteCommand: 수신자의 해당 작업을 호출하는 특정 명령
• Invoker 요청자: 요청을 실행하기 위해 명령 개체를 호출하는 역할을 담당합니다
• 수신자: 요청 구현 및 실행을 담당합니다

Tomcat의 명령 모드 예

Tomcat의 명령 모드는 커넥터와 컨테이너 구성 요소 사이에 반영됩니다. 애플리케이션 서버로서 Tomcat은 의심할 여지 없이 이러한 요청을 어떻게 배포하고 실행하는지가 필요합니다.

Tomcat이 명령 모드를 어떻게 구현하는지 살펴보겠습니다. 다음은 Tomcat 명령 모드의 구조도입니다.

그림 4. Tomcat 명령 모드의 구조 다이어그램

Connector는 추상 요청자이고 HttpConnector는 구체적인 요청자입니다. HttpProcessor를 명령으로 사용합니다. Container는 명령의 추상 수신자 역할을 하고, ContainerBase는 구체적인 수신자 역할을 합니다. 클라이언트는 응용 프로그램 서버 서버 구성 요소입니다. 서버는 먼저 명령 요청자 HttpConnector 개체를 만든 다음 명령 HttpProcessor 명령 개체를 만듭니다. 그런 다음 명령 개체를 명령 수신자 ContainerBase 컨테이너에 전달하여 명령을 처리합니다. 명령은 궁극적으로 Tomcat의 컨테이너에 의해 실행됩니다. 명령은 대기열로 들어올 수 있으며 컨테이너는 다양한 방식으로 요청을 처리할 수도 있습니다. 예를 들어 HTTP1.0 프로토콜과 HTTP1.1은 다르게 처리됩니다.

책임 사슬 모델

Tomcat에서 발견하기 가장 쉬운 디자인 패턴 중 하나는 책임 체인입니다. 이 디자인 패턴은 Tomcat의 컨테이너 디자인의 기초이기도 합니다. 이 체인은 항상 체인을 통해 함께 연결됩니다. 요청의 최종 핸들러.

책임 사슬 모델의 원리

책임 체인 모델은 많은 개체가 다음 개체에 대한 참조를 갖고 연결되어 체인을 형성한다는 것입니다. 체인의 개체가 요청을 처리하거나 각 개체가 요청을 처리하고 전달할 수 있을 때까지 요청이 이 체인에서 전달됩니다. 결국 체인의 모든 객체가 처리될 때까지 다음 객체로 넘어갑니다. 이러한 방식으로 클라이언트에 영향을 주지 않고 모든 처리 노드를 체인에 추가할 수 있습니다.

일반적으로 책임 사슬 모델에는 다음 역할이 포함됩니다.

• Handler(추상 핸들러): 요청 처리를 위한 인터페이스를 정의합니다
• ConcreteHandler(특정 핸들러): 요청을 처리하거나 다음 당사자에게 전달하는 특정 클래스

Tomcat의 책임 사슬 패턴 예

이 디자인 패턴은 Tomcat에서 거의 완전히 사용됩니다. Tomcat의 컨테이너 설정은 엔진에서 호스트, 컨텍스트, 래퍼로 요청이 체인을 통해 전달됩니다.

Tomcat 책임 체인 모델의 클래스 구조 다이어그램은 다음과 같습니다.

그림 5. Tomcat 책임 체인 모델의 구조 다이어그램

위 그림은 기본적으로 책임 사슬 모델을 사용하여 4개의 하위 컨테이너의 클래스 구조 다이어그램을 설명합니다. 책임 사슬 모델의 해당 역할은 컨테이너가 추상 프로세서의 역할을 하고, 특정 프로세서가 하위 컨테이너에 의해 수행됩니다. StandardEngine과 같은 것입니다. 표준 책임 체인과 달리 파이프라인 및 밸브 인터페이스가 여기에 소개됩니다. 그들은 무엇을 합니까?

실제로 Pipeline과 Valve는 이 체인의 기능을 확장하여 체인의 하향 전송 중에 외부 개입을 수용할 수 있도록 했습니다. 파이프라인은 각 하위 컨테이너를 연결하는 튜브이며, 내부로 전달되는 요청 및 응답 개체는 튜브에 흐르는 물과 같으며, 밸브는 이 튜브의 작은 구멍으로, 내부의 물에 닿아 추가 작업을 수행할 수 있는 기회를 제공합니다. 것들.

물이 빠져나가서 다음 용기로 흘러가지 못하는 것을 방지하기 위해, 파이프의 각 구간 끝에는 항상 노드가 있어 다음 하위 용기로 흐를 수 있도록 하므로 각 용기에는 StandardXXXValve. 이러한 종류의 연쇄 처리 흐름을 포함하는 한 이는 배울 가치가 있는 모델입니다.

이동:

위 내용은 [Tomcat] Tomcat 관련 디자인 패턴 분석의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!