[Spring] 스프링부트의 동작방식, 레이어드 아키텍처

mingsso·2023년 10월 17일

SpringBoot

목록 보기

4/11

1️⃣ 스프링부트의 동작방식

서블릿(Servlet)

클라이언트의 요청을 처리하고 결과를 반환하는 자바 웹 프로그래밍 기술
일반적으로 서블릿은 "서블릿 컨테이너"에서 관리함

클라이언트가 URL을 입력하면 HTTP Request가 서블릿 컨테이너로 전송됨

요청을 받은 서블릿 컨테이너는 HttpServletRequest, HttpServletResponse 객체를 생성함

web.xml을 기반으로 클라이언트가 요청한 URL이 어느 서블릿에 대한 요청인지 찾음

❓ web.xml
웹 서버의 환경설정 파일로, web.xml 파일에 서블릿을 등록하려면 다음과 같이 <servlet> 태그를 추가함

<servlet>
	<servlet-name>initParam</servlet-name>
 	<servlet-class>com.edu.test.InitParamServlet</servlet-> class>
 	<init-param>
 		<param-name>id</param-name>
 		<param-value>guest</param-value>
 	</init-param>
 	
 	<init-param>
  		<param-name>password</param-name>
  		<param-value>1004</param-value>
  	</init-param>
  	<load-on-startup>1</load-on-startup>
</servlet>

해당 서블릿에서 service 메소드를 호출한 후 클라이언트의 GET, POST 여부에 따라 doGet() 또는 doPost()를 호출함

// 서블릿 클래스의 형식
public class FirstServlet extends HttpServlet {
	@Override
    public void init() { ... }
    
    @Override
    public void doGet(HttpServletRequest req, HttpServletResponse resp) { ... }
    
    @Override
    public void destroy() { ... }
}

doGet() 또는 doPost()는 동적 페이지를 생성한 후 HttpServletResponse 객체에 응답을 보냄

응답이 끝나면 HttpServiceRequest, HttpServletResponse 두 객체를 소멸시킴

서블릿 컨테이너(Servlet Container)

서블릿의 생성, 실행, 파괴를 담당함. 즉, 서블릿을 위한 상자(Container)다!

서블릿 컨테이너는 Client의 Request를 받아주고 Response할 수 있게, 웹 서버와 소켓을 만들어 통신함

즉, WAS는 Web Server + Web Container(Sevlet Container)로 되어있기 때문에,
정적 컨텐츠를 제공하면서도(Web Server), 웹 컨테이너를 이용해 내부 로직을 거쳐 동적 페이지(Web Container)를 보여줄 수 있는 것

✨ 서블릿의 역할

웹 서버와 통신 지원
- 서블릿 컨테이너는 서블릿과 웹 서버가 손쉽게 통신할 수 있게 해주어, 소켓을 만들고 listen, accept 등을 API로 제공하여 복잡한 과정을 생략할 수 있게 해줌

서블릿 생명주기 관리
- 서블릿 컨테이너는 서블릿의 탄생과 죽음을 관리함
  - 1) 서블릿 클래스를 로딩하여 인스턴스화
  - 2) 초기화 메소드를 호출함
  - 3) 요청이 들어오면 적절한 서블릿 메소드를 호출함
  - 4) 서블릿 소멸 시 가비지 컬렉션을 진행함

멀티스레드 지원 및 관리
- 서블릿 컨테이너는 요청이 올 때마다 새로운 자바 스레드를 하나 생성함
- HTTP 서비스 메소드를 실행하고 나면, 스레드는 자동으로 소멸함
- 원래는 스레드를 관리해야 하지만, 서버가 다중 스레드를 생성 및 운영해주니 스레드의 안정성에 대해서 걱정하지 않아도 됨

선언적인 보안 관리
- 서블릿 컨테이너를 사용하면 개발자는 보안에 관련된 내용을 서블릿 또는 자바 클래스에 구현해놓지 않아도 됨

디스패처 서블릿(Dispatcher Servlet)

디스패처 서블릿이 등장하기 전에는, 모든 서블릿을 URL 매핑을 위해 web.xml에 모두 등록해주어야 했음
-> 디스패처 서블릿이 등장함에 따라 web.xml의 역할을 상당히 축소시켜줌

클라이언트의 요청을 디스패처 서블릿이 받음

디스패처 서블릿은 적절한 컨트롤러(=핸들러)를 선택하는 일을 핸들러 매핑에게 요청함

"핸들러 매핑"은 적합한 컨트롤러를 선택함

디스패처 서블릿은 선택된 컨트롤러의 비즈니스 로직 실행 작업을 "핸들러 어댑터"에게 위임함

핸들러 어댑터가 컨트롤러의 비즈니스 로직을 호출하고 결과를 ModelAndView 객체에 담아서 디스패처 서블릿에게 리턴함

디스패처 서블릿이 뷰 리졸버를 이용하여 결과를 보여줄 뷰를 가져옴

뷰 객체에게 디스패처 서블릿이 응답 결과 생성을 요청함

핸들러 매핑(Handler Mapping)

요청 정보를 기준으로 어떤 컨트롤러를 사용할지 선정하는 인터페이스
핸들러 매핑 인터페이스는 여러 구현체를 가지며, 대표적인 구현체 클래스는 다음과 같음

BeanNameUrlHandlerMapping
- 빈 이름을 URL로 사용하는 매핑 전략
- 빈을 정의할 때 슬래시('/')가 들어가면 매핑 대상이 됨
- 예) @Bean("/hello")

ControllerClassNameHandlerMapping
- URL과 일치하는 클래스 이름을 갖는 빈을 컨트롤러로 사용하는 전략
- 이름 중 Controller를 제외하고 앞부분에 작성된 suffix를 소문자로 매핑함

SimpleUrlHandlerMapping
- URL 패턴에 매핑된 컨트롤러를 사용하는 전략

DefaultAnnotationHandlerMapping
- 어노테이션으로 URL과 컨트롤러를 매핑하는 방법

2️⃣ 스프링의 레이어드 아키텍처

레이어드 아키텍처

애플리케이션의 컴포넌트를 유사 관심사를 기준으로, 레이어로 묶어 수평적으로 구성한 구조
일반적으로 3계층 또는 4계층으로 구성됨

프레젠테이션 계층
- 애플리케이션의 최상단 계층으로, 클라이언트의 요청을 해석하고 응답하는 역할
- UI나 API를 제공함
- 프레젠테이션 계층은 별도의 비즈니스 로직을 포함하고 있지 않으므로, 비즈니스 계층으로 요청을 위임하고 받은 결과를 응답하는 역할만 수행함